ChatGPT
Claude
PerplexitySalesforce Community Cloud Implementation Guide
Two facts belong ahead of any plan for this project.
The product is called Experience Cloud. Community Cloud is the retired name, and the remapping is complete enough that a search for the old term returns a first page composed almost entirely of pages titled Experience Cloud, Salesforce’s own documentation among them. Anyone still searching the old name will find current material; anyone still writing it is describing a product by a name its vendor stopped using.
And the platform underneath moved. Salesforce enforced the Upgrade to Enhanced LWR Sites release update in Spring ’26, which makes the enhanced sites platform the baseline rather than an option. Guidance written before that release describes a build decision that no longer exists in the same form. The product itself is covered in Experience Cloud explained.
What follows is the part that decides whether the project succeeds, which is not the template you pick.
The licence choice fixes the sharing model before anything is built
This is the decision that most implementation guides skip entirely and that every difficult Experience Cloud project traces back to. External users do not get access to records the way internal users do, and which mechanism is available to you is determined by the licence you bought.
Licence | Role hierarchy | How record access is granted | Fits |
|---|---|---|---|
Customer Community | No | Sharing sets and share groups | High volume self-service, many users, own records only |
Customer Community Plus | Yes | Roles, sharing rules, super user access | Customers who need to see colleagues’ records |
Partner Community | Yes | Roles, sharing rules, super user access, channel selling | Resellers and distributors working opportunities and leads |
External Apps and External Identity | Varies | Limited, identity-centric | Authentication and light app access rather than CRM records |
Channel Account | Not applicable per user | Account-based | Partner sites priced by account rather than by user |
Source: Salesforce, Experience Cloud user licences.
The line that matters runs between the first row and the next two. Customer Community users sit outside the role hierarchy, so a member sees their own records and whatever a sharing set grants. If the requirement includes a customer administrator who must see cases raised by everyone at their company, or a partner manager who must see their team’s pipeline, that requirement needs Customer Community Plus or Partner Community, and Salesforce’s super user access exists specifically for those licences.
Discovering this after the build has started is a licence renegotiation, a data model change and a rebuild of the sharing configuration at once. Ask the visibility question in week one: who needs to see whose records, and on what basis?
Member-based and login-based pricing suit opposite usage patterns
Once the licence type is settled, there is a second commercial decision that quietly determines the cost of the site for years.
Member-based licensing charges per named user regardless of how often they appear. Login-based licensing charges per login, drawn from a pool. The right choice is a function of usage frequency rather than user count.
A support portal where thousands of customers log in twice a year is a login-based case. A partner site where two hundred resellers work daily is a member-based case. Getting this backwards is not a functional defect, so nobody notices it in UAT; it surfaces a year later as a bill nobody can explain.
Model the expected logins per user per year before signing. If nobody can produce that number, the honest answer is that the requirement is not yet understood well enough to buy licences against.
Enhanced LWR is the platform, and existing sites carry a decision
With the Spring ’26 enforcement complete, new sites are built on the enhanced platform by default. That closes what used to be a genuine debate and opens a different one for organisations with an existing estate.
For a new build, there is no meaningful case for starting on Aura. For an existing Aura site, the question is whether to migrate, and the honest framing is that there is no conversion tool. Migration means rebuilding pages and rewriting or replacing components, with the site’s URL structure and membership carried across rather than the pages themselves.
Which makes the deciding factor not effort but capability access: features arriving on the enhanced platform do not arrive on Aura sites, so the cost of staying is a widening gap rather than a fixed one. Organisations planning agent-assisted or AI-driven experiences on a customer site should treat that gap as the argument, since the current wave of Experience Cloud capability is being built for LWR.
Guest user access is the security surface that gets projects audited
Every Experience Cloud site with a public page has an unauthenticated guest user, and that user is a real security principal with real record access. It is the part of the build that internal-facing Salesforce experience does not prepare teams for, because internal orgs have no equivalent.
Three habits keep it safe.
Grant nothing to the guest user that is not needed for a public page to render. Object access, field access and sharing all default to closed, and every exception should have a named page justifying it.
Test as the guest user, not as an admin previewing the page. Preview runs with your permissions. The only meaningful test is an unauthenticated browser session against the live URL, checking both what renders and what an inspected network request returns.
Review guest access on a schedule, not on request. Access granted for a launch campaign outlives the campaign, and nobody removes it, because removing permissions has no requester.
The parallel discipline applies to authenticated external users. A field is visible on a record layout, so someone assumes it is safe; the field-level security says otherwise or, more commonly, does not.
Experience Cloud decisions rank by how far they reverse
Rather than a phase list, the useful frame is reversibility. The decisions below are ordered by how expensive each becomes once the site is live with real users on it.
Decision | When it must be made | Cost of changing it later |
|---|---|---|
Licence type and sharing model | Before purchase | Renegotiation plus rebuild of sharing configuration |
Member-based or login-based | Before purchase | A commercial renegotiation, usually at renewal |
Account and contact data model | Design | Every sharing rule and record association affected |
Site domain and URL structure | Before launch | Broken links, bookmarks, search rankings and SSO configuration |
Authentication method and SSO | Design | Every existing member re-onboarded |
Template and platform | Design | A rebuild of pages and components |
Branding and theme | Anytime | Low, and this is what most guides spend their time on |
Content and navigation | Anytime | Low |
Read the top and bottom together. The two rows that most implementation guides open with, template selection and branding, are the two cheapest things on the list to change. The four rows above them are decided in procurement and design conversations that frequently happen without a Salesforce architect present.
Experience Cloud testing covers personas, not features
An org can be tested feature by feature because everyone in it holds a variant of the same access. A site cannot, because the entire point of it is that different people see different things.
- Each licence type, separately. A Customer Community member and a Customer Community Plus member behave differently by design, and testing only one proves nothing about the other.
- The unauthenticated guest. In a clean browser session against the real URL, checking rendering and underlying requests.
- The cross-account attempt. A member of account A deliberately attempting to reach a record belonging to account B, by direct URL rather than through navigation.
- The super user. Where super user access is granted, confirming the widened visibility is exactly as wide as intended and no wider.
- Self-registration and the invited user. Both onboarding paths end to end, including the email, the password set and the first login.
- The mobile session. Since a large share of external traffic arrives on a phone, and external users have no IT department to work around a broken layout.
- Login volume against the licence model. Particularly on login-based licensing, where a launch campaign can consume a quarter’s pool in a fortnight.
Item three is the one that finds real defects. Navigation hides most access problems by simply not offering a link, and a direct URL does not.
Experience Cloud implementations go wrong in seven ways
Pattern | What it produces | Correction |
|---|---|---|
Licence chosen on price alone | A sharing model that cannot meet the requirement | Establish who sees whose records first |
Sharing designed after the data model | Sharing rules fighting the account structure | Design account and contact structure around visibility |
Guest user permissions granted broadly | An avoidable exposure with a public URL | Grant per page, review on a schedule |
Preview treated as testing | Defects visible only to real external users | Test in an unauthenticated session |
Branding prioritised in week one | Time spent on the cheapest decision to reverse | Front-load licence, data and authentication |
Login-based licensing without a usage model | An unexplained renewal | Model logins per user per year before purchase |
Building new on Aura | A site starting behind the platform | New builds on the enhanced platform |
The first row is the expensive one, and it is usually not the project team’s mistake. Licences get bought during a commercial conversation that predates the design, which is why the visibility question needs asking before the paperwork rather than after it.
The Experience Cloud implementation, condensed
Item | Detail |
|---|---|
Current product name | Experience Cloud |
Platform baseline | Enhanced LWR, release update enforced Spring ’26 |
External licence types | Customer Community, Customer Community Plus, Partner Community, External Apps, External Identity, Channel Account |
The dividing line | Customer Community has no role hierarchy; Plus and Partner do |
High-volume access mechanism | Sharing sets and share groups |
Expanded access mechanism | Roles, sharing rules and super user access |
Pricing models | Member-based or login-based, chosen on login frequency |
Least reversible decisions | Licence, data model, domain, authentication |
Most reversible decisions | Branding, content, navigation |
The test that finds defects | Cross-account access attempted by direct URL |
A sharing model belongs on paper before licences are bought
Almost everything expensive on this page is decided early, by people discussing licences and requirements rather than configuration. The reason those decisions get made badly is rarely ignorance; it is that the analysis supporting them, the visibility matrix, the persona definitions, the login volume model, takes longer to produce than the commercial conversation allows.
That analysis is exactly what GetGenerative.ai agents generate, with a Forward Deployed Engineer making the calls, so the licence conversation happens with the sharing model already on paper. For a scoped Experience Cloud build, see our AI-first Salesforce implementation services.
Questions teams ask about Experience Cloud implementation
Is Community Cloud the same as Experience Cloud?
Yes. Experience Cloud is the current name and Community Cloud is the retired one. Documentation, licence names and Salesforce’s own guidance all use Experience Cloud, though several licence types retain Community in their names, which is a frequent source of confusion.
Which Experience Cloud licence do we need?
It depends entirely on who must see whose records. If members only ever need their own records, Customer Community is usually sufficient and scales to very large member counts. If any member needs visibility across colleagues or an account team, Customer Community Plus or Partner Community is required because those licences participate in the role hierarchy.
What is the difference between member-based and login-based licences?
Member-based charges per named user regardless of activity; login-based draws from a pool of logins. Frequent users suit member-based, infrequent users suit login-based, and the decision should follow a modelled estimate of logins per user per year rather than headcount.
Do we have to move our Aura site to LWR?
New sites are built on the enhanced LWR platform following the Spring ’26 release update enforcement. Existing Aura sites continue to run, and the case for migrating is capability access rather than compliance, since new Experience Cloud features are arriving on the enhanced platform. There is no automated conversion, so migration means rebuilding pages and components.
How do we secure the guest user?
Grant nothing beyond what a specific public page needs to render, document each exception against the page requiring it, test in an unauthenticated browser session rather than in preview, and review the permissions on a schedule since nobody ever requests their removal.
How long does an Experience Cloud implementation take?
A straightforward self-service site with standard components can be live quickly. What extends a timeline is the sharing model, custom components and integration with systems outside Salesforce, so the duration follows the visibility and data requirements rather than the number of pages.
Can external users see each other’s records?
Only if the licence and configuration allow it. Customer Community members see their own records plus whatever sharing sets grant. Customer Community Plus and Partner Community members can be granted wider access through roles, sharing rules and super user access, and that widening should be tested by attempting cross-account access directly rather than assumed from configuration.
