Sharing Model: Quick Reference
Fast-track reference for the sharing model — the single most tested area in the CTA security domain. Know this cold before you walk into a mock board.
The Cardinal Rule
Access Is Additive Only
You can NEVER restrict access below what OWD grants. If OWD is Public Read/Write, no sharing rule, role hierarchy, or any mechanism can take away edit access. This is why you almost always start Private and open up.
Record Access Stack
Access layers stack cumulatively — each layer can only ADD access:
flowchart TB
OWD["1. OWD -- Baseline (most restrictive)"] --> RH["2. Role Hierarchy -- Upward visibility"]
RH --> SR["3. Sharing Rules -- Pattern-based horizontal access"]
SR --> Teams["4. Teams -- Per-record collaborative access"]
Teams --> TM["5. Territory Mgmt -- Geography/segment-based"]
TM --> Manual["6. Manual Sharing -- Ad hoc, user-granted"]
Manual --> Apex["7. Apex Managed Sharing -- Programmatic"]
style OWD fill:#c62828,color:#fff
style RH fill:#e65100,color:#fff
style SR fill:#ef6c00,color:#fff
style Teams fill:#f9a825
style TM fill:#2e7d32,color:#fff
style Manual fill:#1565c0,color:#fff
style Apex fill:#4a148c,color:#fff
OWD Cheat Sheet
| OWD Setting | See | Edit | When to Use |
|---|---|---|---|
| Private | Own only | Own only | Default for most objects; ANY user restricted from seeing = Private |
| Public Read Only | All | Own only | All can read, edits restricted |
| Public Read/Write | All | All | No record-level restriction needed |
| Public R/W/Transfer | All | All + reassign | Leads, Cases where anyone can reassign |
| Public Full Access | All | All + transfer + delete + report | Campaign only — all users can view/edit/transfer/delete/report on all records |
| Controlled by Parent | Inherits | Inherits | Detail objects in master-detail |
External OWD: Set separately for external users. Must be same or MORE restrictive than internal OWD. Defaults to Private for guest users and cannot be changed.
OWD Decision Tree (Use for Every Object)
For each object in the scenario, ask:
- Does ANY user need to be restricted from SEEING records? —> Private
- Does ANY user need to be restricted from EDITING records? —> Public Read Only
- No restrictions needed? —> Public Read/Write (or R/W/Transfer for Leads/Cases)
- Are there external users? —> Set External OWD separately (usually Private)
- Should managers see subordinate records? —> Enable/disable “Grant Access Using Hierarchies”
Board Technique
Walk through this decision tree object-by-object in your presentation. The board wants to see a systematic process. Say: “For Account, the most restrictive user is the partner — they should not see other partners’ accounts. Therefore OWD is Private.”
Sharing Rules Quick Comparison
| Type | Based On | Best For | Limit |
|---|---|---|---|
| Ownership-based | Record owner’s role/group | ”Records owned by Sales shared with Support” | No separate sub-limit (total of all rules ≤ 300) |
| Criteria-based | Field values on record | ”Region = West shared with West Team” | Up to 50/object |
| Guest user rules | Criteria on fields | Portal guest access (heavily restricted) | Limited |
Sharing Rule Limits
More than ~50 sharing rules per object signals a design problem. Redesign the role hierarchy or OWD rather than adding more rules. Recalculation time grows linearly with rule count and record volume.
Role Hierarchy Rules of Thumb
| Guideline | Why |
|---|---|
| Keep 5-7 levels max | Every level adds sharing calculation overhead |
| NOT an org chart | Design for data access patterns, not HR reporting |
| One role per access pattern | If two groups need identical access, same role |
| Align to sharing needs | Role placement determines automatic upward visibility |
| Disable hierarchy selectively | For sensitive objects (HR cases, compensation data) |
Sharing Mechanism Selection
| Mechanism | Complexity | Performance | When to Use |
|---|---|---|---|
| Role Hierarchy | Low | Low | Access follows management chain |
| Ownership Sharing Rules | Low | Medium | Access follows record ownership patterns |
| Criteria Sharing Rules | Low | Medium | Access follows field value patterns |
| Account/Opp/Case Teams | Medium | Low | Per-record collaborative access |
| Territory Management | High | Medium-High | Multi-territory, geographic/segment splits |
| Apex Managed Sharing | High | Varies | Complex business logic drives access |
Implicit Sharing (The Hidden Gotcha)
Implicit sharing happens automatically — you cannot turn it off:
| Scenario | What Happens |
|---|---|
| Account owner | Automatically sees all child Contacts, Opportunities, Cases |
| Child record owner | Gets Read access to the parent Account |
| Portal user | Gets Read access to their associated Account |
Implicit Sharing Trap
If Account OWD is Private but Opportunity OWD is Public Read, Opportunity owners can still see the parent Account via implicit sharing. This may expose Account data you intended to hide. The board will test whether you considered this.
LDV Impact on Sharing
| Record Volume | Share Table Impact | Action |
|---|---|---|
| < 1M records | Manageable | Standard sharing design |
| 1M-10M records | Monitor recalculation time | Keep rules under 20 per object |
| > 10M records | Share tables become bottleneck | Flatten hierarchy, consider ETM, archive old records |
Private OWD creates rows in the share table for every record. At scale, this impacts query performance and sharing recalculation can take hours.
Scenario 1: Multi-Division Enterprise
Situation: Global manufacturer with 3 divisions (Industrial, Consumer, Services). Each division has its own sales team. Division managers need to see their team’s data. VP Sales needs to see everything. 5,000 internal users, 500 partner users.
What you’d present:
- Account/Opportunity OWD = Private (partner users must not see other partners’ or other divisions’ data)
- External OWD = Private (partners see only their own records)
- Role hierarchy: 4 levels — VP Sales > Division Director > Regional Manager > Sales Rep (data access, not org chart)
- 3 criteria-based sharing rules: share Accounts where Division = X with the corresponding Division public group
- Partner users in separate role hierarchy branch, no sharing rules to internal data
Why not Public Read Only: Partner users would see all Account names across divisions — confidential.
Scenario 2: Healthcare with Regulatory Constraints
Situation: Healthcare provider, 2,000 users. Patient records (Cases) must be visible only to the assigned care team. Billing department needs to see all patient financial records but not clinical notes. HIPAA compliance required.
What you’d present:
- Case OWD = Private, disable “Grant Access Using Hierarchies” (clinical data should not auto-flow up)
- Case Teams for care team access (per-record, dynamic membership)
- Criteria-based sharing rule: Cases where Record Type = Billing shared with Billing public group
- FLS: Hide clinical note fields from Billing permission set (FLS, not page layout)
- Shield Encryption on PHI fields (probabilistic — no search needed on clinical notes)
Why not sharing rules for care teams: Care team membership varies per patient — not a predictable pattern. Teams give per-record flexibility.
Scenario 3: Territory Overlap
Situation: Software company with named account model. Large accounts may be served by both Enterprise and Mid-Market sales teams simultaneously. 800 sales reps across overlapping territories.
What you’d present:
- Account OWD = Private
- Enterprise Territory Management (ETM2) — accounts assigned to multiple territories simultaneously
- Territory-based sharing: users in a territory automatically see accounts assigned to that territory
- Role hierarchy kept flat (3 levels) since ETM handles access
- Territory assignment rules based on Account fields (Segment, Annual Revenue, Region)
Why not just sharing rules: Overlapping territories cannot be modeled with role hierarchy alone. An account belonging to both “Enterprise - West” and “Mid-Market - Tech” needs ETM’s multi-territory assignment.
Deep Dive References
- Sharing Model: Full Deep Dive
- Security Decision Guides
- Security Trade-offs: Sharing Complexity vs Performance
- Portal & Community Security