Why companies put portals on Experience Cloud
Most portal projects start with a symptom: a support team re-keying answers customers could find themselves, a channel manager reconciling partner deals from spreadsheets, or brokers emailing scanned forms to a shared inbox. The data those external parties need — cases, orders, policies, opportunities, invoices — already lives in Salesforce. Experience Cloud's core value is that it puts an authenticated front door directly on that data, instead of forcing you to sync it into a separate web stack and keep two security models honest forever.
The most common build is a customer self-service portal: log a case and track it, search knowledge, check entitlements, review order status and documents. Done well, it deflects contact-center volume and gives customers a channel that works at 2 a.m. Done badly, it becomes a login page nobody returns to — which is why the access model and the scope of the first release matter more than the visual theme.
The second family is partner relationship management. Partner portals give resellers, dealers and distributors deal registration, lead distribution, shared pipeline visibility and onboarding content, with Salesforce roles and sharing keeping each partner inside its own book of business. We see the same pattern in automotive dealer networks, telco reseller channels and SaaS partner programs.
In insurance and financial services, the same machinery becomes a broker or agent portal: policy servicing, claims intake, document exchange and commission visibility in a channel that is auditable end to end. Nonprofits use it for member, volunteer and grantee portals; manufacturers for supplier and warranty portals. The platform is the same — what changes is the sharing design.
You are probably ready for Experience Cloud when:
- External parties regularly ask your team for information that already sits in Salesforce.
- Partner, dealer or broker processes run on email attachments and spreadsheets.
- A regulated process — claims, onboarding, complaints — needs an auditable self-service channel.
- External users must act on records, not just view them, under real access control.
- Support volume is dominated by status questions a portal could answer.
It is equally worth naming when Experience Cloud is the wrong tool. If external users never need to read or write Salesforce data, a portal license per user is an expensive way to host a website. And if the experience itself is your product — consumer-grade UX, your own release cadence, deep SEO control — a headless architecture with Salesforce behind APIs is often the better trade. We cover that below and in more depth in our headless CRM guide.
How Clouderia delivers Experience Cloud
Clouderia is a boutique Salesforce engineering consultancy: on the platform since 2010, 46 certified experts, senior engineers working from Provo, Utah and Prague. Portals sit at the intersection of everything we do — CRM data models, integrations, custom Lightning development and security — and we deliver them in five phases.
- Access model first. Before any page is built we define personas, a record-level data-access matrix and the license tier each persona actually needs. Licensing and sharing mistakes are cheapest to fix here.
- Architecture. Template choice (LWR vs Aura), identity design — SSO, self-registration, login flows — sharing architecture, environment strategy and the integration map behind the portal.
- Build. Experience Builder configuration where it is enough; custom Lightning Web Components where it is not; Apex services and integrations behind them. We keep the custom surface as small as the requirements allow.
- Hardening. Persona-based test users for every access path, a guest-user audit, and a structured Salesforce security review before external users touch production. In regulated deployments we also support penetration-test remediation.
- Launch and run. CI/CD for portal metadata and code, monitoring, documentation your admins can maintain, and handover — or ongoing support through our Salesforce services team.
We have shipped portals for financial services, insurance, telco, nonprofit, automotive and SaaS organizations. Where a portal needs to surface payment and bank-transaction data, our TransactionHub product handles reconciliation behind the scenes; CollectiPro does the same for receivables and recovery status. We never invent scope to sell licenses: if a configured template covers 90% of your requirements, we will tell you so.
Architecture, licensing and security notes
Templates: LWR vs Aura
Experience Cloud sites run on one of two runtimes. Aura templates are the older generation: rich in prebuilt components, including some CRM components that still have no modern equivalent. LWR (Lightning Web Runtime) templates are the current generation: significantly faster, built around Lightning Web Components, and where Salesforce's investment is going. For new builds we default to LWR and treat any dependency on an Aura-only component as an explicit architecture decision — either accept Aura's weight, rebuild the component, or redesign the requirement. Migrating a site between runtimes later is a rebuild, not a toggle, so this choice deserves more scrutiny than it usually gets.
The licensing model, qualitatively
External users do not use internal Salesforce licenses. Experience Cloud licenses come in tiers that differ mainly in three dimensions: which objects a user can access (partner-oriented tiers add leads, opportunities and campaigns for channel selling), whether the user participates in role hierarchies and advanced sharing, and how the license is metered. Each tier is typically sold two ways — per named member, or per login from a pooled allowance. Member-based pricing suits users who log in constantly, such as active partners; login-based pricing suits large populations who log in occasionally, such as policyholders checking a claim twice a year.
The practical consequences: choosing a partner-grade tier for users who only need cases and knowledge is the most common form of over-licensing, and choosing a customer-grade tier for users who later need opportunity access forces a disruptive migration. This is why we map personas to license tiers during discovery, not during contract negotiation. Prices and exact entitlements change; check current Salesforce documentation and your account executive for the terms in force.
Security and sharing: where portals go wrong
A portal deliberately opens your org to the internet, which makes the sharing model a security boundary rather than a convenience. The platform gives you separate external organization-wide defaults — the baseline for what portal users can see — and these should almost always be Private, with access opened deliberately through sharing sets, sharing rules, account relationships and, where necessary, Apex managed sharing. The recurring failure modes we find in portal audits:
- External org-wide defaults left at Public Read for objects that hold customer data.
- Guest user profiles with object permissions far beyond the public pages that need them.
- Custom Apex running without sharing in portal context, silently bypassing the entire access model.
- Custom components that query with system-level access and skip field-level security, exposing fields the page never renders but the API response contains.
- List views, lookups, search and related lists leaking record names across accounts — enumeration rather than exfiltration, but a finding in every serious pen test.
- Files and attachments shared to records without checking who the record is shared with.
None of these are platform defects; all of them are configuration and code decisions. We wrote up the full checklist — guest users, sharing sets, Apex context, FLS enforcement in LWC — in our Experience Cloud security guide, and we test every portal build against it with dedicated persona users before launch. For existing portals, this is the core of our security review service.
The headless alternative
Experience Builder is fast to ship and inherits the platform's security context, but it constrains you: its rendering model, its release cycle, its performance envelope. When the portal is effectively a digital product — a bank's client zone, an insurer's claims journey embedded in the main website, a marketplace — many teams keep Salesforce as the system of record and build the front end themselves in React, Next.js or a similar stack, talking to Salesforce through REST or GraphQL APIs with OAuth token flows. You gain full control over design, performance, SEO and deployment; you take on hosting, authentication, caching and — critically — re-implementing the access checks the platform would otherwise give you for free. Experience Cloud can still play a role in this model as the identity and API-authorization layer even when it renders no pages. The decision framework, API options and caching patterns are covered in Headless CRM: Salesforce as an API-first engine.
Integration and performance notes
Portals rarely show only Salesforce data. Invoices live in ERP, statements in a billing engine, documents in a DMS. There are three honest patterns: synchronize the data into Salesforce ahead of time (simple pages, storage cost, staleness window); virtualize it with Salesforce Connect and external objects (no storage, but callout latency on page load and per-callout limits); or call out at runtime from Apex behind Named Credentials (full control, and full responsibility for timeouts and error states the user will see). Choose per data type, not per project. Keep heavy computation out of the page path entirely — the same reasoning we lay out in when to write Apex applies double when the person waiting on a governor limit is your customer. For public pages, lean on the platform cache and CDN options for static assets, and measure LWR page performance with real portal users, not admin logins, because sharing calculations change the query plans.
Frequently asked questions
Is Experience Cloud the same as Community Cloud?
Yes. Salesforce renamed Community Cloud to Experience Cloud in 2021; the product underneath is the same platform for building authenticated portals and public sites on Salesforce data. You will still meet the old vocabulary everywhere — community users, partner community licenses, community URLs — in documentation, license names and existing orgs, so treat the two names as interchangeable.
What licenses do external portal users need?
External users need dedicated Experience Cloud licenses, separate from internal Salesforce licenses. They come in tiers that differ mainly in object access, roles and sharing capabilities — customer tiers for self-service, partner tiers for deal management — and each tier is sold in member-based and login-based models. The right mix depends on user counts and login frequency; check current Salesforce documentation for exact terms.
How do we control which records portal users can see?
Through the platform sharing model, not the site itself. External organization-wide defaults set the baseline, which should almost always be Private; sharing sets, sharing rules, account relationships and Apex managed sharing then open access deliberately. Custom components must additionally enforce object- and field-level security. Because misconfigured sharing is the most common cause of portal data exposure, we design and test the access model per persona before launch.
Should a new site use an LWR or Aura template?
LWR (Lightning Web Runtime) is the current-generation option: faster, built around Lightning Web Components, and the direction Salesforce is investing in. Aura templates still ship more prebuilt components, some of which have no LWR equivalent yet. For new builds we default to LWR and only choose Aura when a required out-of-the-box component would otherwise have to be rebuilt at disproportionate cost.
When is a headless front end better than Experience Builder?
When the experience itself is your product — you need full control over design, performance and release cycles, or the portal must live inside an existing web property. Salesforce then stays the system of record and exposes data through APIs while your own front end renders it. You trade Experience Builder's speed and built-in security context for freedom, and take on hosting, authentication flows and caching yourself.
What drives the cost of an Experience Cloud project?
Four things dominate: license tier and user volumes, depth of customization (template configuration versus custom component development), the number and complexity of integrations behind the portal, and security or compliance work such as audits and penetration-test remediation. A configured self-service portal is a materially smaller effort than a custom partner platform with quoting and document workflows, which is why we scope in phases.
Is Experience Cloud suitable for regulated industries?
Yes, with discipline. Banks, insurers and healthcare organizations run client and broker portals on it because it inherits the Salesforce platform's security model, encryption options and audit capabilities. The residual risk is rarely the platform — it is misconfigured sharing, over-permissive guest access and custom code that skips field-level security. In regulated deployments we pair the build with a formal security review and persona-based access testing.