Implicit Sharing for External Users

Module 5 of 6 in the chapter Overrides and Implicit Sharing: What You Get for Free, chapter 10 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: What does a customer or partner on your site get to see without any sharing you built, and how do you control it?

Modules 2 to 4 were about the two kinds of implicit sharing that affect everyone. Salesforce adds “a few more that only affect external users”: the people who come in through an Experience Cloud site or a portal (Implicit Sharing (opens in a new tab), Salesforce Help, checked 2026-11-07). Two of them are in the first four kinds from module 2: site implicit and case contact implicit. External users in depth, their licenses, roles and sharing sets, are Part 3. This module is only what they get for free.

Site users: their account, and the people on it

Here’s the reason this one exists. An external user always belongs to a company: “Because external users can only be created by being associated with an account record, the users gain some record access based on the account they’re linked to” (Implicit Sharing, Salesforce Help).

So what do they get? “An account’s portal or site user has access to the parent account and to all of the account’s contacts that are enabled as partner or customer users” (same page). Salesforce’s other guide adds how it’s done: the account and its contacts are “shared with the lowest role under the customer or partner account,” and its example is a Customer Community Plus user who gets “Read access” to their company’s account and to its other contacts (Implicit Sharing (opens in a new tab), Designing Record Access for Enterprise Scale, Salesforce Developers, Winter ‘27 edition, checked 2026-11-07).

What you need to watch for: a site user under an account can see the other site users at that account. Usually that’s what the business wants. Colleagues at the same customer see each other’s names on the site. But ask the question. If two people at the same customer company must not know about each other on your site, the account they’re under is a design decision.

And the contacts who aren’t site users? By default, a Customer Community Plus user sees only the site-enabled contacts. To show them every contact on their account, Salesforce has a setting: Allow users to see contacts that have not been enabled for partner or customer accounts, in the Digital Experience settings (Salesforce Site Users Not Able to See Contacts That Are Not Enabled for Experience Cloud Sites (opens in a new tab), Knowledge Article 000382955, published July 14, 2025, checked 2026-11-07). One switch, every account, every such user. Turn it on only if every customer should see every contact you hold on their company.

Click to enlarge

The case contact: a really important one

This is the one I always teach with a question. A customer creates a case on your site. After they submit it, they want to see its status. How do they see their case?

The room usually has two answers, and both are wrong. They’re good wrong answers, because each one shows why this kind of implicit sharing has to exist.

“Aren’t they the case owner? They created it.” For a moment, yes. But ask what a case assignment process is for. It takes the case and assigns it to a queue, and then to somebody to work it. That’s its whole job. So the customer’s ownership is removed very quickly, usually before they’ve even looked at the case again. Under a Private model, once they’re not the owner, owning it gave them nothing that lasts. Whatever keeps their access, it can’t be ownership.

“A sharing set.” It gives them access, but it isn’t scoped to the individual. A sharing set would show them all the cases on their account, not that one case. Chapter 15 covers sharing sets.

So the real question is: how does the site user who created the case keep seeing it, when it can’t be ownership and a sharing set shows too much?

Salesforce has a built-in answer, and it’s the case contact: “If a portal or site user is a contact on a case, then the user has Read and Write access on the case” (Implicit Sharing, Salesforce Help). The case has a Contact field. If the contact on it is a site user, that user keeps access to the case, whoever owns it.

Click to enlarge

Test knowledge. Know how a site user keeps seeing a case after assignment rules give it to a queue and then to someone to work it: they’re the case’s contact, so case contact implicit sharing gives them Read and Write. Know the two wrong answers: ownership (the assignment process removes it almost at once) and a sharing set (it shares every case on the account, not that one). And know that the behavior can be turned off in Sharing Settings. A likely area, not a known question.

How far it reaches, and how to turn it off

Two more facts from Salesforce, and both are design decisions (Restrict Experience Cloud Site User Access to Cases (opens in a new tab), Salesforce Help, checked 2026-11-07):

• It reaches up the external role hierarchy. For users with Customer Community Plus licenses, the standard behavior “grants the assigned contact and everyone in their role hierarchy access to a case.” So the case contact’s managers at the customer see it too. Chapter 14 covers roles for external users.
• You can turn it off. In Sharing Settings, under Other Settings, deselect Grant site users access to related cases. Then you control access to cases “by creating a manual share or by using Apex managed sharing.”

Why would you? Salesforce’s example: a company with offices around the world that keeps cases private within each office. With the behavior on, site users who move from one office to another bring their assigned cases with them. Turn it off, and they can’t.

That example says something about how the access works. It follows the Contact field on the case. Change the contact, and the access goes with the contact, not with the case’s owner or the customer’s office. Module 4’s rule again: the access lasts exactly as long as its reason.

Read and Write means they can edit

Notice the level. It’s not Read Only; it’s “Read and Write.” A customer who’s the case contact can edit their case, as far as their profile and field-level security allow. So the office has to be built for it (chapters 3 and 4): which case fields the site profile can see, which it can edit, and what the page on the site shows. Don’t rely on the site’s page alone to keep a field read-only.

What an architect decides here

• Which account each external user sits under, knowing they’ll see the account and the other site users on it.
• Whether customers should see the contacts who aren’t site users, the one setting that opens them all.
• Whether case contact access stays on, or is turned off and replaced by manual shares or Apex managed sharing.
• How far up the customer’s own role hierarchy case access should reach.
• Which case fields site users can edit, since the case contact gets Read and Write.
• Where a sharing set is the right answer instead, and where it shows too much (chapter 15).

Beyond the exam: what AI changes. A service agent on your site answers questions about a customer’s cases, and it can only use what the customer’s user can see: their account, the site users on it, and every case where they’re the contact. That’s usually exactly right. But if you turn off Grant site users access to related cases, or change which account a customer sits under, test the agent again with a real site user, because what it can say changes with them. Chapter 20 covers agents.

Explore

• Implicit Sharing (opens in a new tab), Salesforce Help (checked 2026-11-07)
• Implicit Sharing (opens in a new tab), Designing Record Access for Enterprise Scale, Salesforce Developers, Winter ‘27 edition (checked 2026-11-07)
• Restrict Experience Cloud Site User Access to Cases (opens in a new tab), Salesforce Help (checked 2026-11-07)
• Salesforce Site Users Not Able to See Contacts That Are Not Enabled for Experience Cloud Sites (opens in a new tab), Knowledge Article 000382955, Salesforce Help (checked 2026-11-07)