Experience Cloud Architecture: What's Actually Happening Under the Hood

What Experience Cloud Actually Is

Experience Cloud is not a separate product from Salesforce — it is a capability within the Salesforce platform that allows you to extend Salesforce data and processes to users who are not internal Salesforce users. Partner portals for channel sales partners, customer self-service portals for support case management, employee experience sites, and public-facing company websites can all be built with Experience Cloud.

The architecture key is that Experience Cloud sites exist within your Salesforce org. They are not separate applications — they are a rendering layer over the same objects, data, and logic that your internal users access. A customer viewing their open cases in a support portal is accessing the same Case records that your service agents see in the internal Salesforce UI, subject to different sharing rules and field-level security.

This is both Experience Cloud's strength and its architectural complexity. The integration depth is immediate — there is no separate customer database to sync, no separate authentication service to build. But the data access model, security configuration, and performance characteristics of serving external users are distinct from serving internal users, and they require separate architectural attention.

Licence Types and What They Grant

Experience Cloud users are licensed separately from internal Salesforce users. The licence type determines what objects the external user can access, how many logins are allowed, and what the cost per user is. Choosing the wrong licence type creates either functional limitations or unnecessary cost.

Partner Community licence: Designed for channel sales partners — resellers, distributors, agents. Grants access to Leads, Opportunities, Accounts, Contacts, Cases, and Campaigns. Partners can view and edit their own opportunities, see account details for their assigned accounts, and manage leads assigned to them. Priced per-user (named user) rather than by login volume.

Customer Community licence: Designed for end customers on self-service portals. More restricted than Partner — access to Accounts, Contacts, Cases, and custom objects. Cannot access Opportunities or Campaigns. Priced either per named user or per-login (pay per use). Per-login pricing is appropriate for large customer bases with sporadic usage — a million customers who each log in twice a year are dramatically cheaper with per-login pricing than per-user pricing.

Customer Community Plus licence: Extends Customer Community with additional capabilities: ability to create records (not just view/edit owned records), access to more standard objects, and ability to run reports on community data. Appropriate for power users in a B2B customer portal who need deeper platform access.

The Guest User Architecture

Every Experience Cloud site has a Guest User — a shared system user that represents all unauthenticated visitors to the site. When someone accesses a public page on an Experience Cloud site without logging in, their session runs as the Guest User, sharing a single user context regardless of how many concurrent visitors are on the site.

This architecture has significant security implications. Any data accessible to the Guest User is accessible to any anonymous internet visitor. Guest user access is controlled through the Guest User Profile and the Guest User sharing rules configured for the site. Misconfigured Guest User access is one of the most common Salesforce security vulnerabilities — it has resulted in public data exposures where internal org data was inadvertently accessible to unauthenticated visitors.

Salesforce has progressively tightened Guest User defaults in recent releases. By default, Guest Users cannot read internal user data, cannot create most record types, and cannot access records owned by internal users unless explicitly shared. In older orgs built before these restrictions were tightened, a Guest User security audit is essential — the default permissions may have been expanded during initial development and left broader than intended.

// Checking Guest User profile access via SOQL (as admin)
SELECT Id, Name, PermissionsViewAllData, PermissionsModifyAllData,
       PermissionsApiEnabled
FROM Profile
WHERE Name LIKE '%Guest%'

// Checking which objects the Guest User profile can access
SELECT SobjectType, PermissionsRead, PermissionsCreate, PermissionsEdit
FROM ObjectPermissions
WHERE ParentId IN (
    SELECT Id FROM PermissionSet WHERE ProfileId IN (
        SELECT Id FROM Profile WHERE Name LIKE '%Guest%'
    )
)
ORDER BY SobjectType

Data Access for External Authenticated Users

When external users log in to an Experience Cloud site, they are Salesforce users — they have a User record, a Profile, and participate in the standard Salesforce sharing model. However, they operate under a separate sharing model layer: the External Sharing Model.

Every object in Salesforce has two sharing model settings: the internal default (controls access for internal users) and the external default (controls access for external users). The external default is always equal to or more restrictive than the internal default. Setting the Account object's internal default to "Public Read" but external default to "Private" means internal users can see all accounts but external users can only see accounts shared with them explicitly.

External users in a Partner portal context typically see records via Role Hierarchy sharing. Experience Cloud creates a separate role hierarchy for external users — a tree of portal roles that mirrors the account hierarchy of your partners. A Partner user at a partner account can see all cases and opportunities owned by other users in the same partner account's portal roles, controlled by the role hierarchy and sharing rules.

For self-service customer portals, the sharing model is typically simpler: customers see only records they own (cases they created, orders they placed) or records explicitly shared to them via sharing rules triggered by their contact or account association.

LWR vs Aura Sites: The Runtime Architecture

Experience Cloud sites run on one of two runtime engines: Lightning Web Runtime (LWR) or the Aura-based Lightning Community framework. The choice has significant implications for performance, development flexibility, and long-term maintainability.

Aura-based sites (legacy): The original Experience Cloud runtime, using the Aura framework for component rendering. These sites use Community Builder for drag-and-drop page composition and support Aura components. While fully functional, this runtime is in maintenance mode — new platform features and optimisations are being built for LWR, not Aura.

LWR sites: The strategic Experience Cloud runtime, introduced in recent releases. LWR sites render faster (smaller JavaScript bundles, native browser rendering), support more powerful customisation (full CSS control, component overrides, theme tokens), and are the basis for all Commerce Cloud convergence (B2B and D2C Commerce on LWR). New Experience Cloud implementations should always use LWR.

LWR sites have two deployment modes: Managed (low-code page builder similar to old Community Builder) and Enhanced (maximum developer control, supports headless architecture). Enhanced LWR is appropriate for complex sites where design customisation and performance are critical; Managed LWR is appropriate for straightforward self-service portals where time-to-market and configurability are priorities.

Performance Architecture for Experience Cloud

Experience Cloud site performance is one of the most common sources of user dissatisfaction in external-facing Salesforce projects. Several architectural factors drive slow sites, and each has specific mitigations.

CDN (Content Delivery Network): Salesforce provides built-in CDN for Experience Cloud sites. Static assets (JavaScript, CSS, images) are served from Salesforce's CDN edge nodes close to the user's location. This is enabled by default for LWR sites and dramatically reduces asset load times for geographically distributed user bases. Ensure CDN is enabled and that custom component assets are included in CDN delivery.

Page caching: LWR sites support page-level caching for public (unauthenticated) pages. A product listing page, a knowledge article, or a news item that is the same for all visitors can be cached at the CDN edge and served without hitting the Salesforce application server. This reduces both page load time and Salesforce server load for high-traffic public pages.

Data query performance: Experience Cloud pages that load record data via SOQL (through Lightning Data Service, Apex wire adaptors, or custom Apex) are subject to the same query performance constraints as internal Salesforce pages — but external users typically don't have the context to understand loading spinners. Ensure frequently-accessed data is properly indexed, queries are selective, and loading states are designed to show partial content quickly.

Component loading: A page with many components that each make independent data requests creates a "waterfall" of loading states — each component loads independently and appears progressively. Design component data loading to share queries where possible (one parent component queries data and passes it to children as properties) rather than having every component query independently.