In one sentence: a sharing set grants Experience Cloud users on high-volume licences access to records by matching a lookup on the record against the Account or Contact on their own user record, and it exists because those users have no role, which means the role hierarchy and sharing rules cannot reach them at all.
Why high-volume users are different
Licences such as Customer Community, High Volume Customer Portal and Authenticated Website are designed for populations measured in hundreds of thousands. Putting that many users into a role hierarchy would be unworkable, so Salesforce simply left them out of it.
The consequences are specific. These users cannot be assigned a role. Sharing rules that grant to roles or role-and-subordinates never apply to them. They do not appear in the hierarchy, so nobody gains access to their records by being above them. Owner-based sharing rules with them as the source go nowhere. Everything you normally reason about in the sharing model is unavailable.
Customer Community Plus and Partner licences do have roles, and ordinary sharing rules work for them. Check the licence before designing anything.
How a sharing set grants access
A sharing set names one or more profiles, then for each object it defines a path from the user to the record. The user record of a community user points at a Contact, and that Contact points at an Account. The sharing set says which field on the target object must match one of those two.
The classic configurations:
- Case where
Case.ContactIdequals the user’s Contact. Each user sees only their own cases. - Case where
Case.AccountIdequals the user’s Account. Every user at a customer sees every case for that customer. - A custom object with a lookup to Account, matched to the user’s Account, which is how most portal data models end up working.
Access is Read Only or Read/Write, set per object in the sharing set. There is no criteria filter beyond the matching field, so if you need “cases for my account, but not the confidential ones”, the sharing set is not the place to express it.
Object coverage is limited. Account, Contact, Case, Contract, Order, User and custom objects are the usual candidates. Check the current list rather than assuming.
Share groups, for the other direction
Records owned by high-volume users are the mirror image of the problem. No role means nobody sits above the owner, so no internal user inherits access, including the support manager who needs to work the case.
Share groups solve that. Each sharing set has a share group, and you add internal users, roles, or public groups to it. Members get access to records owned by the high-volume users covered by that sharing set. Forgetting this step is the single most common Experience Cloud support ticket: the customer can log a case, and the agents cannot see it.
What sharing sets do not do
- They do not grant object or field permissions. The profile still has to allow Read on Case, and field-level security still applies. A sharing set only answers “which records”.
- They do not cascade in the way the role hierarchy does. There is no inheritance, only the matching rule you defined.
- They do not help with reports beyond the records granted. The user sees what the set gave them.
- They cannot be filtered by record type or status. That requirement usually turns into a redesign of the data model or an Apex managed share.
Designing around the constraint
Because the only lever is a lookup match, the data model has to carry the access logic. If community users should see a subset of a shared object, put the Account lookup on a child record and grant on the child, rather than trying to express the subset in the sharing set.
When a requirement cannot be matched by a lookup, the fallback is Apex managed sharing on a custom object, and you then own the shares and the recalculation forever.
Frequently asked
Why can my community user see nothing at all? Check the licence first. If it is a high-volume licence, sharing rules were never going to apply, and you need a sharing set.
Why can internal staff not see records the customer created? The share group has not been configured, or the internal user is not in it. That is the fix, not a sharing rule.
Do sharing sets apply to guest users? No. Guest access has its own model, with guest sharing rules and the secure guest user record access behaviour. Do not mix the two designs.
Can I use both a sharing set and a sharing rule? On a Customer Community Plus or Partner licence, yes, and sharing rules do apply. On high-volume licences the sharing set is effectively your only tool.
