Experience Cloud projects fail on the sharing model, not the theme

The kickoff for an Experience Cloud project is almost always about how the site will look. Somebody brings brand guidelines, somebody else brings a screenshot of a competitor's portal, and the first fortnight goes on a theme, a header, a typeface and the placement of a search bar. That work is real. It is also the part of the project least likely to decide whether the thing succeeds.

The decisions that decide it are made in the same fortnight, quietly, usually by whoever is configuring rather than whoever is designing. Which licence type the external users get. Whether those users own records or only see them. Whether one customer contact can see a colleague's case. What an unauthenticated visitor can reach. None of those is a branding question, and every one is expensive to reverse once a site is live and populated.

The pattern is consistent enough to predict. Build goes smoothly, because everyone building is an administrator and administrators see everything. Then acceptance testing starts with real external accounts and the questions arrive at once: why can this contact not see the case their colleague logged, why can that one see an account they have nothing to do with, why does the attached file return an error. Each answer traces back to a decision made in week two by someone who was not thinking about sharing.

#Internal instincts are the wrong instincts here

An experienced Salesforce administrator carries a working mental model of sharing: organisation-wide defaults set the floor, the role hierarchy opens access upward, sharing rules widen it sideways, manual and team shares handle the exceptions. That model is correct, it has been earned over years, and applying it to external users produces wrong answers.

External access has its own settings. Organisation-wide defaults for external users are configured separately from the internal ones, so an object can be read-only internally and private externally at the same time, deliberately. Teams that have never had to look at that screen assume one setting governs both, and design on that assumption.

The hierarchy works differently too. External users are tied to a contact, and therefore to an account, and their access is shaped by that account relationship rather than by where they sit in your structure. Some external licence types get roles beneath the account, producing the rollup behaviour you would expect within one customer organisation and nothing at all across customer organisations. Others have no role whatsoever, on purpose, because roles do not scale to hundreds of thousands of users.

That last point catches people. A site designed around role-based access and then built on a licence type without roles does not degrade gracefully. It stops working, and the fix is either a licence change or a redesign of how access is granted.

#The licence decision is made on cost and paid for in capability

Licence type is the first constraint set and the last one anyone revisits. It is usually chosen early, in a commercial conversation, using the only information available at that point: how many external users there might be and what each one costs. Capability is discussed briefly, in general terms, and the number wins.

Then the design meets the constraint. External users need to own the record they submitted, and the licence chosen does not permit ownership. They need to see records belonging to a colleague at the same company, and the mechanism for that differs by licence type. Somebody wants a report in the portal, and reporting is not available at the tier that was bought. Each arrives separately, months apart, as a surprise, and by then the number sits in an approved budget.

The correction is cheap and rarely done. Before the licence conversation, write the verb list. Not personas, not a feature wish list: the actual verbs. An external user will read an article. Log a case. Attach a file. See the cases a colleague at the same organisation logged. Own something. Collaborate in a group. Run a report. Work an opportunity. Reach a custom object your team built.

Ten verbs takes half an hour and does most of the architectural work, because capability requirements sort themselves into tiers as soon as they are concrete. Read-and-log at scale sits at one end. Sites where external users own records, collaborate across their own organisation and work a pipeline sit at the other, and cost considerably more per user for good reason.

Salesforce revises licensing regularly, and the detail that matters, what each type permits and where the limits fall, changes with it. Treat any licensing table you hold as out of date and confirm current entitlements before committing. The durable advice is about sequence: pick the licence from the verb list, not the verb list from the licence.

#Sharing sets, sharing rules, and the model that does not extend

Once the licence is settled, the question is how an external user gets to a record. There are two broad answers and they belong to different worlds.

Where external users have roles, access behaves in a way that feels familiar. Records owned within an account roll up through the portal roles beneath that account, ownership works, and sharing rules can target those roles and the groups built from them. Familiar is not identical, and the boundary is worth stating plainly: the rollup exists inside one customer organisation. It does not cross to another, and nothing about your internal role hierarchy applies to it.

Where external users have no roles, none of that machinery exists, and access is granted by a sharing set: a rule matching a field on the record to the user's contact or account. The shift is from hierarchy to matching. Instead of asking who sits above whom, you ask which field on this record ties it to this user, and if no field ties them the user has no access, however obviously related the record looks to a human reading it.

Two consequences follow, and both cause live defects.

Custom objects need the relationship the sharing set will match on. A custom object built for internal use often carries a lookup to Account or Contact for reporting convenience, or carries neither because the relationship was implied through a parent. External access needs that relationship to exist, populated, on every record. Retrofitting it after go-live is a data exercise rather than a configuration change.

Files, related records and knowledge follow their own paths. Access to a case does not carry access to everything visible from it. Attachments, related lists, articles and any object reached through a lookup each resolve on their own terms. The classic ticket is a user who can open a case and not the file attached to it, and the classic cause is that only the case was designed.

#The guest user is the widest door in the org

Every public Experience Cloud site has a guest user, and it is the highest-risk surface most organisations have, for one structural reason: it is unauthenticated. Whatever the guest user can reach is reachable by anyone who finds the URL, with no login and no name attached to the request.

Salesforce has tightened the defaults here substantially over the years, and the tightening is the right instinct: guest access should be narrow, explicit and deliberately granted rather than inherited. The risk in practice is not the platform default. It is the widening that happens during build.

The mechanism is ordinary. Something on the public page does not render, and the quickest way to find out why is to grant the guest profile access to the object and see whether the error clears. It clears, the ticket closes, and the grant stays, because nobody logs a task to narrow it later. Repeat that a dozen times over a build and the guest profile has a footprint nobody designed and nobody has read.

Three habits keep it honest. Grant guest access to a named list of objects and fields somebody has read out loud, rather than to whatever made the error go away. Review any code the guest user can invoke as carefully as you would review a public API, because that is what it is. And treat any page returning customer-specific information from an identifier a visitor typed as an enumeration risk, since a typed identifier is a claim rather than proof, a point we make at more length in the security model behind an agent.

Salesforce's overview of cloud data security is worth reading against your guest configuration rather than instead of it. The platform gives you the controls. It cannot tell you which objects should never have been in front of an anonymous visitor.

#The external access design checklist

This is the artefact worth taking away. Every row is answerable in a sentence during design, and a row nobody can answer is the finding, not a gap in the list.

Twelve rows. Most projects can answer eight at design sign-off, and the four left unanswered are usually rows 5, 7, 8 and 10, which is a fair summary of where Experience Cloud implementations go wrong.

#Test as an external user, not as an admin

This is the most skipped step, and it is skipped for a reason that sounds sensible at the time: the site works, everyone can see it, and setting up realistic external test users is fiddly work that produces no visible progress.

An administrator viewing an Experience Cloud page sees the page an administrator can see, which is not evidence about anything. Sharing, field-level security, profile permissions and guest scope all resolve differently for the account the request arrives on, so an admin walkthrough validates layout and nothing else.

Four tests, run early and repeatedly, catch nearly everything.

Log in as a real external user. Salesforce lets you enter the site as a specific external user from their contact record, and that should be the default way the team reviews anything. What renders for that user is the only account of what the site does.

Test one user per licence type and per persona. A site serving a high-volume customer population and a smaller partner population is running two access models, and testing one says nothing about the other.

Test signed out. Open the public pages in a private browser window and read what comes back with an adversarial eye. This is how a broad guest profile gets found by you rather than by somebody else.

Test the negative cases. Confirm a contact at one organisation cannot reach another organisation's records, and that a URL to a record outside their scope returns an error rather than content. Positive tests prove the site works. Negative tests prove the boundary exists, and the boundary is the deliverable.

#External users arrive on worse devices than your staff

Internal performance work assumes a corporate laptop on office wifi. External users bring whatever they have, wherever they are: an older phone, a shared connection, a browser with a dozen tabs open, and no help desk to ring when something spins.

They are also far less patient, and reasonably so. An employee waiting on a slow page waits, because the work is their job. A customer waiting to check a case leaves and telephones instead, which costs more than the portal saves and produces the failure mode where a self-service investment increases contact volume. That connects to the demand data question in a case model you can still report on in three years: if the portal is quietly pushing people to the phone, the case data is the only place that shows it.

Three practical constraints. Put fewer components on the pages that matter most, because every component is work the page does before anything appears, and the home page and the case list are where the traffic goes. Size images for the device rather than for the design mock. And measure on a mid-range phone on a throttled connection, as a gate rather than a curiosity, because a desktop measurement taken next to the server says nothing about the person on a train.

The same discipline applies to the permission model behind the page. Access resolved through layers of accumulated grants is slower as well as harder to reason about, which is one more argument for keeping external profiles narrow and readable. The general case is in permission set debt.

#What to settle before anyone picks a theme

Six answers, and the build follows from them. What external users will do, written as verbs. Which licence type those verbs require, confirmed against current Salesforce entitlements rather than remembered. What the external organisation-wide defaults are, object by object, stated separately from the internal ones. How each object grants access, and whether the relationship that grant depends on exists and is populated. What the guest user can reach, as a list a person has read. And who is logged in during every review of the site, which should be an external user from the first sprint.

Salesforce documents the product surface of customer portals and what a customer portal is expected to do, and the platform will build whatever site you configure. The theme is the part everyone can see and the cheapest part to change: a rebrand is a sprint. The sharing model is the part nobody can see and the part that decides whether the site can be trusted with customers, and changing it after go-live means migrating live users, recalculating sharing on populated objects, and explaining why a record visible yesterday is not visible today.

Spend the first fortnight on the invisible half. The theme will still be there afterwards, and it will still take a sprint.