Why Sharing Is Hard

Salesforce’s sharing model is powerful and subtle. Records can be visible through ownership, role hierarchy, sharing rules, manual shares, teams, territories, queues, groups, profile-level access, and programmatic Apex shares. Multiple overlapping paths can grant the same record to the same user.

Debugging “why can this user see this record” gets hard fast. The only way out is a disciplined, top-down design.

Layer 1: Organization-Wide Defaults (OWD)

OWD sets the baseline visibility for each object. Options:

  • Private: only the owner (and admins) sees it.
  • Public Read Only: everyone sees it; only the owner can edit.
  • Public Read/Write: everyone sees and edits.
  • Public Read/Write/Transfer (Leads/Cases): everyone can reassign.

Start from Private and open up with explicit rules. Not the other way around. It’s always easier to grant access than to claw it back.

Layer 2: Role Hierarchy

The role hierarchy grants upward access — managers see what their reports own. Enable “Grant Access Using Hierarchies” per object (on by default for most standard objects).

Use the role hierarchy to model management visibility, not peer-level access. It’s not for “everyone in sales should see each other’s accounts” — that’s what sharing rules are for.

Layer 3: Sharing Rules

Sharing rules grant broad, criteria-based access to groups of users:

  • Ownership-based: “Records owned by users in Role A are shared with Role B.”
  • Criteria-based: “Records where Industry = Healthcare are shared with the Healthcare Team group.”

Sharing rules are the workhorse for peer-level and cross-team access.

Limits: 300 sharing rules per object (across types). Large orgs can hit this — consolidate before creating new rules.

Layer 4: Manual Shares

A record owner (or someone with access) can share an individual record with a specific user or group. The access appears in the record’s Sharing detail page.

Manual shares are:

  • Explicit and record-level.
  • Lost if the record’s owner changes (unless using Apex-managed).
  • Not scalable — one at a time.

Use for exceptions, not patterns. Patterns belong in sharing rules.

Layer 5: Teams

Account Teams and Opportunity Teams are named patterns of shared access on specific records.

  • An Account Team member gets configurable access to the Account (and optionally its Cases and Opportunities).
  • An Opportunity Team member gets configurable access to the Opportunity.

Teams are the natural fit for “core account team” scenarios — one account with three reps each having read or write.

Layer 6: Territory Management

ETM grants access based on territory assignment. Overlaps with sharing rules but is structured around sales geography and rep assignment. See the ETM guide for details.

Layer 7: Queues and Groups

  • Queues own records jointly. Anyone in the queue can take ownership.
  • Public Groups are used in sharing rules and team assignments as a target.

Don’t use queues for sharing alone — they’re ownership containers. Use groups for shared access patterns.

Layer 8: Apex-Managed Sharing

Programmatic sharing via Apex. You create share records directly:

OpportunityShare s = new OpportunityShare(
    OpportunityId = oppId,
    UserOrGroupId = userId,
    OpportunityAccessLevel = 'Edit',
    RowCause = 'Manual'
);
insert s;

Use for:

  • Sharing logic too complex for declarative rules.
  • Dynamic shares computed from record attributes.
  • Integration with external access control systems.

Downsides:

  • More code, more bugs, more maintenance.
  • Debugging “why is this shared” involves reading your code.

Don’t use Apex sharing when declarative rules could do the job.

Decision Tree

Start here for each object:

  1. Is this object viewable to everyone? OWD Public Read Only or Read/Write. Done.
  2. Private OWD, but managers see reports’ records? Role hierarchy. Usually automatic.
  3. Need peer access across teams/territories? Sharing rules.
  4. Need shared access to specific records by named team? Account/Opportunity Teams.
  5. Territorial access by assignment? Enterprise Territory Management.
  6. Complex, data-driven sharing logic? Apex-managed sharing.
  7. One-off exception? Manual share.

Walk this tree for each object. Documenting “this is how Opportunity sharing works” is the kind of doc that earns its keep.

Groups Summary

For declarative sharing targets:

  • Public Group: a named bag of users, roles, and other groups.
  • Role: everyone in that role.
  • Role and Subordinates: everyone in the role and everyone in lower roles under it.
  • Territory: everyone in the territory.
  • Queue: everyone in the queue.

Assign sharing rules and manual shares to these targets.

Common Mistakes

Starting with Public Read/Write and trying to restrict. Very hard to retrofit privacy. Always start private.

Relying on hierarchy for peer access. Hierarchy is upward access. Sharing rules are the tool for peer access.

Manual shares for common patterns. If you find yourself manually sharing the same records to the same groups, build a sharing rule.

Apex shares without row causes. RowCause = 'Manual' is the default but restricts transfer survival. For persistent Apex shares, create a custom Apex-managed sharing reason (requires permission) so shares survive owner changes.

Forgetting implicit sharing. Child records (Cases, Opportunities) often inherit visibility from the parent Account. Turning off implicit sharing on Account changes child visibility.

Debugging

When “why can this user see this record” has no obvious answer:

  • View the record’s Sharing detail — shows all shares.
  • For each share, note the Reason column — that’s the path.
  • Cross-reference with sharing rules, team memberships, manual shares, territories, Apex shares.

For persistent investigations, the Sharing Health Check and Sharing Recalculation tools help. Escalate to Salesforce support for orgs with genuinely opaque sharing.

Large-Scale Sharing Patterns

Very large orgs sometimes face sharing performance issues — save times slow, queries timeout. Mitigations:

  • Flatten role hierarchies. Deep hierarchies compute more shares.
  • Group-based sharing over per-user sharing.
  • Disable “Grant Access Using Hierarchies” on custom objects where it’s not needed.
  • Skinny tables for reporting workloads.

Engage Salesforce architecture support for orgs exceeding single-object row counts of 50M+ with complex sharing.

Frequently Asked Questions

Does OWD affect admin access?

Admins typically have “Modify All Data” or “View All Data” permissions that bypass OWD. For sensitive data, scope these permissions carefully.

What’s the difference between “Role and Subordinates” and “Role and Subordinates Internal”?

Internal excludes partner/customer portal users; regular includes them. Almost always use Internal for internal sharing.

Can I share with a Community user?

Yes — with high-volume customer community users you need “sharing set” patterns instead of standard sharing rules. Regular sharing works for standard community user types.

Is there a way to see all a user’s visible records?

Run a report as the user. Use the “Log in as” admin feature (requires permission) to see their UI. No single consolidated “all visible records” view exists.

Share