We took over a Salesforce org mid-project once where the previous team had set Opportunity OWD to Public Read/Write, then built twelve Sharing Rules trying to restrict access back down to individual teams. None of it worked. Sharing Rules only open access — they cannot close it. The org had to be redesigned from scratch with the correct OWD and the right hierarchy, two weeks before go-live.
That pattern — open OWD, fight it with Sharing Rules — is the most common sharing model mistake we see. Understanding the four layers and what each one can and cannot do prevents it.
The four-layer stack
Layer 4: Manual + Apex Managed Sharing ← ad-hoc, disappears on owner change
Layer 3: Sharing Rules ← declarative open-up for groups
Layer 2: Role Hierarchy ← top-down, manager sees subordinate
Layer 1: OWD (Org-Wide Default) ← baseline, most restrictive
One rule governs all four layers: each layer can only open access wider than the layer below it. No layer restricts access granted by a lower layer. If you try to use Layer 3 to undo what Layer 1 already opened, it does nothing.
Design the sharing model from the bottom up. Set OWD to the most restrictive setting that fits the lowest-privilege user. Then open access upward with the minimum number of rules needed. Going the other direction — open at the bottom, restrict from above — does not work in Salesforce.
Layer 1: OWD — set this right before anything else
OWD is the baseline every record falls back to when no other rule applies. For most objects, the choices are:
- Private: users see only records they own, plus records owned by users below them in the hierarchy.
- Public Read Only: everyone can read every record; edit requires ownership or a higher role.
- Public Read/Write: everyone can read and edit every record.
- Public Read/Write/Transfer (Leads and Cases only): everyone can also reassign ownership.
On a sales org implementation, the first question we ask is: should a rep ever see another rep's opportunities unprompted? Usually no. That means OWD Private on Opportunity. Managers see their team automatically through the Role Hierarchy. No Sharing Rules needed for the basic visibility requirement.
The mistake that causes the most rework: setting OWD to Public Read/Write because it feels "simpler," then fielding complaints three months later that reps are editing each other's records. Changing OWD after go-live triggers a full sharing recalculation that can take hours on large orgs and locks the org for users during the recalc.
Layer 2: Role Hierarchy — the piece most orgs underuse
The Role Hierarchy is a tree where users in higher roles automatically see records owned by users in lower roles. No Sharing Rule required. A manager role above five rep roles gives the manager read access to all five reps' records as soon as the OWD is anything other than Public Read/Write.
On a recent telecom implementation (a 200-user Sales Cloud for a Vietnamese ISP), we built the entire visibility model — regional managers seeing their sub-regions, division heads seeing all divisions — using only OWD Private and a five-level Role Hierarchy. No Sharing Rules. The hierarchy handles vertical access cleanly.
Three things the hierarchy cannot do:
- Grant access between peers at the same level (East rep cannot see West rep's deals — needs a Sharing Rule)
- Grant access based on a field value rather than record ownership
- Restrict access that OWD already opened
Layer 3: Sharing Rules — lateral access and field-based exceptions
Sharing Rules handle what the hierarchy cannot: cross-branch access and data-driven access.
Owner-based: "All opportunities owned by the East sales team should be visible to the Bid Management team for proposal support." The East team and Bid Management team do not share a hierarchy path, so the Rule explicitly grants it. This is the most common Sharing Rule we configure — cross-functional visibility where teams need to collaborate on records they do not own.
Criteria-based: "All accounts where Industry equals Healthcare should be visible to the Healthcare compliance team." The access follows the record's field value, not the owner. Regardless of which rep owns the account, any healthcare-tagged account is accessible to the compliance team. We use this pattern frequently for regulatory or specialization requirements.
One gotcha we hit on a project: a client wanted a Sharing Rule that shared "all accounts in the Northeast region with Northeast managers only." The problem was that some Northeast accounts were owned by reps who reported to a national accounts manager, not the Northeast hierarchy branch. An owner-based rule would miss those. A criteria-based rule on Region field caught all of them cleanly.
Layer 4: Manual sharing and Apex Managed Sharing
Manual sharing is the one-off: a user explicitly shares a single record with another user or group via the Share button. No admin configuration, no Sharing Rules. The limitation: manual shares disappear when the record owner changes. On a deal that gets reassigned, the external consultant who was manually shared loses access automatically. We document this behavior in every handover — it surprises clients more than almost any other Salesforce behavior.
Apex Managed Sharing persists through owner changes. We use it when the access requirement is too dynamic for declarative Sharing Rules — for example, sharing a project record with the user whose ID is stored in a custom field on that record. That relationship cannot be expressed in a Sharing Rule, but an Apex trigger or Flow-called Apex can insert a share record tied to the custom field value.
The sharing design we use at the start of every implementation
Before writing any code or clicking any Sharing Rule, we map three questions:
- Who is the most restricted user? That user's access defines the OWD floor. Set OWD to match them.
- Who needs upward access? Managers, directors, executives who need to see their team's records — Role Hierarchy handles this, no Sharing Rules needed.
- Who needs lateral access? Peer teams who need to see each other's records — owner-based Sharing Rules. Field-based requirements — criteria-based Sharing Rules.
Most implementations we review that have messy sharing models made the same mistake: they started with a permissive OWD to avoid "restricting" users, then tried to tighten access with tools that cannot tighten. Flip the model — start tight, open deliberately — and the sharing layer stays maintainable.
