Experience Cloud Architecture

Experience Cloud is Salesforce’s platform for building external-facing digital experiences — customer portals, partner hubs, help centers, microsites, and storefronts. For the CTA exam, you must understand the full architecture stack: runtime frameworks (LWR vs Aura), Experience Builder, CMS, SEO, CDN, and multi-site strategy. This page focuses on architecture and design decisions; for security-specific concerns (licenses, sharing, guest users), see Portal & Community Security.

Architecture Overview

flowchart TD
    subgraph "User Layer"
        Auth["Authenticated Users\n(Customer / Partner)"]
        Guest["Guest Users\n(Unauthenticated)"]
    end

    subgraph "Delivery Layer"
        CDN["CDN\n(Akamai / Cloudflare)"]
        CustomDomain["Custom Domain\n(CNAME / HTTPS)"]
    end

    subgraph "Runtime Layer"
        LWR["LWR Runtime\n(Static Rendering)"]
        Aura["Aura Runtime\n(Dynamic Rendering)"]
    end

    subgraph "Builder Layer"
        EB["Experience Builder\n(Drag & Drop)"]
        Themes["Themes & Branding"]
        Pages["Pages & Navigation"]
        LWC["Custom LWC Components"]
    end

    subgraph "Content Layer"
        CMS["Salesforce CMS"]
        WS["Workspaces"]
        CT["Content Types"]
        CH["Channels\n(Site / Headless / Public)"]
    end

    subgraph "Data Layer"
        CRM["CRM Data\n(Accounts, Cases, Opps)"]
        KB["Knowledge Base"]
        DC["Data Cloud"]
        AF["Agentforce\n(AI Agents)"]
    end

    Auth --> CDN
    Guest --> CDN
    CDN --> CustomDomain
    CustomDomain --> LWR
    CustomDomain --> Aura
    LWR --> EB
    Aura --> EB
    EB --> Themes
    EB --> Pages
    EB --> LWC
    EB --> CMS
    CMS --> WS
    WS --> CT
    WS --> CH
    Pages --> CRM
    Pages --> KB
    LWC --> DC
    LWC --> AF

    style LWR fill:#1565c0,color:#fff
    style Aura fill:#e65100,color:#fff
    style CDN fill:#2e7d32,color:#fff
    style CMS fill:#4a148c,color:#fff
    style AF fill:#00695c,color:#fff

LWR vs Aura: Runtime Framework Comparison

Choosing between LWR (Lightning Web Runtime) and Aura is the first architectural decision. LWR is the modern default for new sites; Aura remains relevant for legacy implementations.

Dimension	LWR	Aura
Component model	LWC only	Aura + LWC
Rendering	Static — built and cached at publish time	Dynamic — rendered on every page load
Page load speed	~50% faster than Aura (sub-second)	Slower — fetches component metadata per request
SEO	Native support: clean URLs, meta tags, sitemap, robots.txt	Limited — requires workarounds for SEO
URL structure	No `/s/` prefix (Winter ‘23+); SEO-friendly slugs	`/s/` prefix required
Publishing	Must republish for changes to appear	Changes display without republishing
Pre-built components	Growing library (~30+)	Mature library (~60+)
Custom CSS	Full CSS customization, CSS custom properties	Limited to SLDS overrides
Head markup	Inject custom `<head>` markup (analytics, fonts)	Not supported natively
Security model	Lightning Web Security (LWS)	Lightning Locker
Theming	Design tokens, CSS variables, granular control	Theme panel with limited overrides
Offline support	Planned (progressive web app model)	Not available
Recommended for	All new implementations (2024+)	Existing sites, Aura component dependencies

LWR Component Gaps

LWR has fewer out-of-the-box components than Aura. Before committing to LWR, verify that all required standard components are available. Missing components (e.g., certain report viewers, chat widgets in older releases) may require custom LWC development. Check the Salesforce release notes for your target release.

Migration Path

There is no automated Aura-to-LWR migration tool. Migration requires rebuilding the site on an LWR template. Plan for: rewriting Aura components as LWC, recreating page layouts, re-theming, and retesting all functionality. Salesforce recommends migrating during major redesign cycles rather than as a standalone project.

Site Type and Template Selection

Experience Cloud offers templates organized by use case. Each template is available in LWR, Aura, or both.

Template Decision Guide

Template	Framework	Use Case	Key Features
Customer Service	LWR / Aura	Support portal, case management	Case creation, knowledge base, account management
Help Center	LWR / Aura	Self-service knowledge discovery	Knowledge search, article navigation, case deflection
Partner Central	LWR / Aura	Channel partner enablement	Deal registration, lead distribution, co-selling workflows
Customer Account Portal	LWR / Aura	Authenticated self-service	Account management, order history, profile updates
Build Your Own (LWR)	LWR	Fully custom experience	Maximum flexibility, custom LWC, API integrations
Build Your Own (Aura)	Aura	Legacy custom builds	Supports both Aura and LWC components
Microsite (LWR)	LWR	Campaign pages, event sites, lead capture	Lightweight, unauthenticated, fast setup
B2C Commerce (LWR)	LWR	E-commerce storefront	Product catalog, cart, checkout, order management
Tabs + Visualforce	Visualforce	Deep Visualforce customization	Full Visualforce page embedding, legacy integrations

Template Selection Flowchart

flowchart TD
    Start["New Experience\nCloud Site"] --> Q1{"Primary\npurpose?"}

    Q1 -->|"Customer support"| Q2{"Need knowledge\nself-service focus?"}
    Q2 -->|Yes| HC["Help Center\n(LWR)"]
    Q2 -->|No| CS["Customer Service\n(LWR)"]

    Q1 -->|"Partner channel"| PC["Partner Central\n(LWR)"]

    Q1 -->|"Account self-service"| CAP["Customer Account\nPortal (LWR)"]

    Q1 -->|"Marketing / events"| MS["Microsite\n(LWR)"]

    Q1 -->|"E-commerce"| B2C["B2C Commerce\n(LWR)"]

    Q1 -->|"Highly custom"| Q3{"Existing Aura\ncomponents?"}
    Q3 -->|Yes| BYOAura["Build Your Own\n(Aura)"]
    Q3 -->|No| BYOLWR["Build Your Own\n(LWR)"]

    style HC fill:#1565c0,color:#fff
    style CS fill:#1565c0,color:#fff
    style PC fill:#e65100,color:#fff
    style BYOLWR fill:#2e7d32,color:#fff
    style MS fill:#4a148c,color:#fff

CMS Architecture

Salesforce CMS is a hybrid content management system — it delivers content natively within Experience Cloud sites and also supports headless delivery via API to external channels.

Core CMS Concepts

Concept	Description	Scope
Workspace	Container for content; controls contributor access, languages, and permissions	Per-org; multiple workspaces per org
Content Type	Schema defining the fields a content item has (e.g., Blog, FAQ, Banner)	Global — shared across all workspaces
Content Item	An individual piece of content (article, image, document)	Belongs to one workspace
Channel	Distribution endpoint connecting a workspace to a site or external system	One workspace can map to multiple channels
Collection	Curated grouping of content items for display	Used in CMS components on pages

CMS Delivery Architecture

flowchart LR
    subgraph "CMS Workspace"
        Authors["Content Authors"]
        CT["Content Types\n(Blog, FAQ, Banner)"]
        Items["Content Items"]
    end

    subgraph "Channels"
        SiteChannel["Experience Cloud\nSite Channel"]
        PublicChannel["Public Channel\n(Marketing, Email)"]
        HeadlessChannel["Headless API\nChannel"]
    end

    subgraph "Delivery Targets"
        LWRSite["LWR Site\n(Native CMS Components)"]
        ExtSite["External Website\n(React, Next.js)"]
        MobilApp["Mobile App"]
        MCEmail["Marketing Cloud\nEmail"]
    end

    Authors --> CT --> Items
    Items --> SiteChannel --> LWRSite
    Items --> PublicChannel --> MCEmail
    Items --> HeadlessChannel --> ExtSite
    Items --> HeadlessChannel --> MobilApp

    style SiteChannel fill:#1565c0,color:#fff
    style HeadlessChannel fill:#e65100,color:#fff
    style PublicChannel fill:#2e7d32,color:#fff

Headless CMS APIs

API	Purpose	Use Case
Connect REST API	Retrieve published content by channel	External sites, mobile apps
Tooling API	Create/manage content types programmatically (JSON)	CI/CD, content type deployment
Metadata API	Deploy content types as metadata (XML)	Scratch orgs, sandboxes, source control
Connect Apex Classes	Access CMS content within Apex	Custom LWC data providers, integrations

CMS vs External CMS

Salesforce CMS is ideal when content authors are already in Salesforce and content needs CRM data context (e.g., personalized content by account segment). For organizations with established CMS platforms (WordPress, Contentful, Sitecore), use headless integration patterns rather than migrating all content into Salesforce CMS.

SEO and Performance

SEO Capabilities (LWR Sites)

Capability	Details	Configuration
Clean URLs	No `/s/` prefix; human-readable paths (e.g., `/help/billing`)	Automatic for LWR sites (Winter ‘23+)
SEO-friendly slugs	Account/Contact slugs replace record IDs in URLs	Enable in Experience Builder settings
Meta tags	Custom `<title>`, `<meta description>`, Open Graph tags per page	Page Properties in Experience Builder
Sitemap	Auto-generated XML sitemap for search engines	Enable in Administration > Settings
Robots.txt	Configurable to control crawler behavior	Editable in Administration > Settings
Canonical URLs	Prevent duplicate content indexing	Automatic for published pages
Head markup	Inject tracking scripts, custom fonts, structured data	Experience Builder > Settings > Head Markup

CDN and Caching Strategy

Experience Cloud uses Salesforce CDN (powered by Akamai or Cloudflare) for content delivery.

Layer	What’s Cached	TTL	Notes
CDN edge	Static assets (JS, CSS, images, fonts)	Salesforce-managed	Automatic for all sites with CDN enabled
LWR publish cache	Component markup and styles	Until next publish	LWR pre-builds at publish time
Browser cache	Static resources, images	Standard HTTP cache headers	Configurable via head markup
Apex CDN cache	Apex controller responses	Configurable via `@AuraEnabled(cacheable=true)`	Reduces server round-trips
CMS content cache	Published CMS content	Until content update	Served from CDN for guest users

Performance Checklist

For the CTA exam, know these performance levers: (1) enable CDN, (2) use LWR for static rendering, (3) mark Apex methods cacheable, (4) optimize images via CMS, (5) minimize custom component JavaScript, (6) use lazy loading for below-fold content, (7) limit API calls in component lifecycle hooks.

Guest User Architecture

Guest users access Experience Cloud sites without authentication. LWR sites created Winter ‘23+ are authenticated by default — you must explicitly enable public access.

Aspect	Authenticated Site	Unauthenticated (Guest) Site
Login required	Yes	No
User context	Named user with license	Guest User profile
Data access	OWD + sharing + permissions	Guest sharing rules only (criteria-based)
Record creation	Yes (user owns records)	Limited; records owned by default site owner
API access	Yes	Disabled by default
Personalization	Full (user profile, preferences)	None (anonymous)
Use case	Customer portal, partner hub	Knowledge base, marketing site, microsite

Guest User Data Exposure

Every piece of data visible to guest users is accessible to anyone on the internet. The CTA board will probe this aggressively. See Portal & Community Security for guest user sharing rules, profile lockdown, and best practices.

Multi-Site Strategy

An org can have up to 100 Experience Cloud sites. The decision between one site and multiple sites depends on user segmentation, branding, and data isolation needs.

When to Use Multiple Sites

Scenario	Single Site	Multiple Sites
One audience, one brand	Yes	Overkill
Multiple brands, shared data	Possible with audience targeting	Better — separate branding per site
Customers + Partners	Possible but complex	Recommended — different license types, workflows
Multiple languages, one brand	Yes — use language selector	Not needed unless regulatory isolation required
Campaign / event microsites	No — use Microsite template	Yes — Microsite template per campaign
Regulatory data isolation	Not possible	Yes — separate guest user profiles, sharing
Different authentication needs	Complex	Clean — SSO per site via [[02-security/identity-sso

Microsite Strategy

Microsites (LWR) are lightweight, unauthenticated sites designed for campaigns, events, and lead capture. They share the same org data but have independent branding and pages.

Feature	Full Experience Site	Microsite (LWR)
Authentication	Authenticated or guest	Unauthenticated only
License required	Yes (per user type)	No (guest access)
CRM data access	Full (based on sharing)	Lead capture via forms
CMS content	Full CMS integration	CMS content via channels
Complexity	Medium-High	Low
Typical lifespan	Permanent	Temporary (campaign duration)

Agentforce and Data Cloud Integration

Experience Cloud sites are a primary deployment surface for Agentforce AI agents and Data Cloud-powered personalization.

Integration	Capability	Architecture
Agentforce Service Agent	AI-powered conversational bot embedded in Experience Cloud sites; handles Tier-1/Tier-2 inquiries, deflects cases, escalates to humans	Configured via Agentforce Builder; deployed as Embedded Service component on LWR/Aura pages
Experience Builder Agent	AI assistant within Experience Builder that generates and refines page content for authors (announced capability — verify current availability)	Available in LWR sites; assists content creation, not end-user facing
Data Cloud personalization	Unified customer profiles drive personalized content, recommendations, and segmentation on site pages	Data Cloud segments surface via CMS audience targeting and custom LWC
Agentforce Contact Center	Unified voice + digital channel AI agent for omnichannel service	Routes between Experience Cloud chat, voice, and messaging channels

CTA Relevance

For the CTA exam, understand that Agentforce agents on Experience Cloud sites use the same data access model as the site’s guest or authenticated user. Agent responses are constrained by the user’s sharing rules and permissions — agents cannot bypass the security model. This is a key architectural point when designing AI-assisted self-service.

CTA Scenario Patterns

Scenario 1: Partner Portal with Deal Registration

Situation: A manufacturer needs 500 channel partners to register deals, access marketing materials, and view co-branded collateral.

Decision	Recommendation	Rationale
Template	Partner Central (LWR)	Purpose-built for deal registration and partner enablement
License	Partner Community	Supports reporting, role hierarchy, opportunity access
Sharing	External OWD = Private; sharing rules by partner tier	Partners must not see each other’s deals
CMS	Workspace per region; marketing collateral via CMS collections	Regional content with centralized governance
Authentication	SAML SSO to partner’s IdP via [[02-security/identity-sso	Identity & SSO]]
Agentforce	Service Agent for partner FAQ and deal status inquiries	Deflects Tier-1 support from channel team

Scenario 2: Customer Self-Service with Knowledge Base

Situation: A SaaS company wants customers to search knowledge articles, create cases, and track case status — reducing support call volume by 40%.

Decision	Recommendation	Rationale
Template	Help Center (LWR)	Optimized for knowledge search and case deflection
License	Customer Community (high-volume)	Low cost per user; HVCP sharing sets for case access
Guest access	Public knowledge articles for SEO; login required for case creation	Drives organic traffic; protects PII behind auth
CDN	Enabled with Salesforce CDN	Sub-second page loads for guest knowledge browsing
SEO	Clean URLs, meta tags, sitemap enabled	Knowledge articles indexed by search engines
Sharing	Sharing Sets: `Case.AccountId = Contact.AccountId`	Customers see only their account’s cases
Agentforce	Service Agent as first contact; escalation to human agents	AI handles common questions before case creation

Scenario 3: Multi-Brand Microsite Campaign

Situation: A retail company runs quarterly product launch campaigns across 3 brands, each needing a branded landing page with lead capture.

Decision	Recommendation	Rationale
Template	Microsite (LWR) per brand/campaign	Lightweight, independent branding, no login required
License	None (unauthenticated)	Guest access only — no per-user cost
CMS	Shared workspace with brand-specific channels	Content reuse across campaigns; brand isolation via channels
Data capture	Flow-based forms writing to Lead object	No guest user record ownership concerns
Lifecycle	Deploy per campaign; deactivate after campaign ends	Microsites are disposable by design

Key Gotchas

LWR Republish Requirement

Unlike Aura, LWR sites require republishing for any change to appear — including Salesforce’s own component updates. Build a publishing workflow and communicate publish schedules to content teams. Forgetting to republish is the most common LWR operational issue.

Site Limits

Each org supports up to 100 Experience Cloud sites. Each site consumes API limits, storage, and sharing calculations. Monitor site usage against org limits, especially with multiple microsites. Guest user API access (if enabled) shares the org’s API allocation.

Aura-to-LWR Migration

There is no automated migration path from Aura to LWR. All pages, components, themes, and custom code must be rebuilt. Budget 2-4x the effort of the original build. Do not underestimate migration complexity in a CTA scenario.

Portal & Community Security — external user licenses, sharing sets, guest user security, HVCP architecture
Identity & SSO — authentication for Experience Cloud sites (SAML, OAuth, social login, JIT provisioning)
Sharing Model — internal and external OWD, sharing rules that underpin portal data access
Field & Object Security — profiles and permission sets for external users
Decision Guides — portal architecture and license selection decision trees