Salesforce Experience Cloud

Why it matters

Most teams file Experience Cloud under 'website builder' and miss the point. Its real value is that the portal runs on the same data model, permission sets, and sharing rules as your internal org — so an external user sees their own cases, orders, or claims without you copying data into a separate system and re-securing it. That single-source design is also why it is the natural place to put a customer-facing AI agent: the agent inherits the identity and access controls of the page it lives on, so it can only read and act on records that user is already entitled to — instead of being bolted onto an untrusted public site with its own copy of the data and its own ways to leak it.

How it works

• Sites are built in Experience Builder on component-based templates. The modern stack is LWR (Lightning Web Runtime), which renders faster and is the path forward; older Aura templates still exist but carry more page weight — choosing LWR vs Aura up front is an architectural decision, not a theme choice.
• External users get a license-gated identity — typically Customer Community, Customer Community Plus, or Partner Community — tied to Account and Contact records and authenticated via Salesforce Identity, SSO, or social login. The license type caps which objects and features that user can touch.
• Sharing rules, sharing sets, and guest user profiles — not page logic — decide what each visitor can see. Security is enforced at the data layer, so a misconfigured page cannot leak another customer's records. The unauthenticated guest user profile is the most common misconfiguration and should be locked down deliberately.
• On top of that sit branding, navigation, and CMS content, while Flows, Apex, and Agentforce agents provide the interactive and AI behavior — all of it still bounded by the same sharing model.

Where it fits

Experience Cloud is the surface layer of the Data-to-Agent stack: Data Cloud resolves who the customer is, Agentforce decides and acts, and Experience Cloud is where that interaction is exposed to the outside world under your brand. Common deployments are self-service help centers, partner deal-registration portals, B2B commerce account sites, and member or patient portals. The decision that costs the most to get wrong is licensing and identity. External licenses are sold either per named member or per login, and the right model depends on how often each user actually shows up — a seasonal partner portal and a daily-use member portal can carry very different bills under the same headcount. Pick the license type, login model, and sharing design before the first page is built, because unwinding them after launch usually means re-platforming, not reconfiguring. If you are putting an agent in front of customers here, that licensing and sharing model is also the boundary the agent operates inside — which is why we treat it as a build-and-run question, not a launch-day checkbox. If that is the call in front of you, SkySync can pressure-test the model before it hardens (/start).