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 walking 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:

Figure 1. Each layer in the stack is purely additive: no layer can revoke access granted below it. This is why the OWD baseline must be set to the most restrictive level the business can tolerate before opening access upward.

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:

1. Does ANY user need to be restricted from SEEING records? —> Private
2. Does ANY user need to be restricted from EDITING records? —> Public Read Only
3. No restrictions needed? —> Public Read/Write (or R/W/Transfer for Leads/Cases)
4. Are there external users? —> Set External OWD separately (usually Private)
5. 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”	300/object (expandable to 500 via Support)
Criteria-based	Field values on record	”Region = West shared with West Team”	50/object (independent limit)
Guest user rules	Criteria on fields	Portal guest access (heavily restricted)	50/object (independent limit)

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

Sources

• Salesforce Help: Sharing Settings
• Salesforce Architects: Platform Sharing Architecture
• Salesforce Architects: Data Access Decision Guide
• Salesforce Help: Enterprise Territory Management
• Salesforce Ben: Sharing and Visibility Architect Guide