Sharing Model: OWD, Role Hierarchy & Sharing Rules

The sharing model is the foundation of Salesforce record-level security. It determines who can see and edit which records, and it is one of the most heavily tested areas on the CTA exam. A flawed sharing model cascades into performance issues, security holes, and governance nightmares.

How Record Access Works: The Sharing Stack

Record access in Salesforce is cumulative. You can open access but never restrict it below the baseline set by Organization-Wide Defaults (OWD). Each layer can only add access, never subtract it.

Figure 1. The Salesforce sharing stack has seven additive layers. OWD sets the floor, and each layer above it can only open access wider, never restrict it below the baseline.

The Cardinal Rule

Access is always additive. You cannot use sharing rules or any mechanism above OWD to take away access that OWD grants. If you set OWD to Public Read/Write, no amount of sharing rules can restrict a user from editing records. This is why starting restrictive is almost always correct.

Record Access Calculation Flow

When a user requests a record, Salesforce evaluates access through a specific sequence. Understanding this flow matters for debugging “why can/can’t this user see this record?” questions on the CTA board.

Figure 2. Salesforce evaluates record access in a fixed sequence: OWD first, then ownership, then hierarchy, then the share table, and finally implicit parent-child relationships. Understanding this order is essential for diagnosing access issues on the board.

Detailed walkthrough

Each gate in this flowchart is a hard stop. If access is granted, evaluation ends immediately without checking remaining gates.

The first gate is OWD. If the object is Public Read/Write, the engine short-circuits and grants full access without touching the share table or role hierarchy. This is why Public Read/Write is attractive for high-volume objects: no sharing rows, no join, no calculation. The trade-off is that no record can be selectively restricted below that baseline.

If OWD is Private or Public Read Only, the engine checks record ownership. The owner always has full access. Ownership is a single indexed lookup on the OwnerId field, making it cheap and absolute. No sharing rule or Apex share can reduce the owner’s access.

The hierarchy gate comes next. The “Grant Access Using Hierarchies” checkbox controls it. When enabled (the default), any user above the record owner in the role hierarchy inherits access. When disabled, the hierarchy is bypassed entirely for that object. This toggle is commonly used for HR case data or compensation records. Candidates frequently assume hierarchy access is always on.

If none of the above gates fires, the engine queries the share table. Every declarative and programmatic sharing mechanism writes rows here: ownership-based rules, criteria-based rules, Account/Opportunity/Case team membership, territory assignments, manual shares, and Apex managed shares. The engine joins the share table against the pre-computed Group Membership Table, resolving all groups, roles, and territories the requesting user belongs to. If multiple rows match, the most permissive access level wins. On objects with millions of records and complex sharing rules, this join is the source of performance overhead.

The final gate is implicit sharing. If no explicit sharing row exists, Salesforce checks whether the requesting user owns a child record related to the parent. A Contact owner automatically gets Read access to the parent Account even if Account OWD is Private and no sharing rule covers them. The board question this enables: “If Account OWD is Private, can an Opportunity owner see the parent Account?” Yes, via implicit upward sharing. That may not be the intended behavior.

How the Sharing Engine Works Under the Hood

When OWD is Private or Public Read Only, Salesforce maintains three database-level structures to enforce record visibility:

1. Object Share Table (e.g., AccountShare): stores sharing rows that grant a specific user or group access to a specific record. Each sharing rule, team assignment, manual share, or Apex share creates rows here.
2. Group Membership Table: maps users to all groups they belong to (public groups, roles, roles + subordinates, territories, queues). This is pre-computed so access checks are fast.
3. Object Record Table: the actual data records with their OwnerId field.

When a user queries records, Salesforce joins the record table with the share table and group membership table to determine visibility. If multiple sharing rows grant access, the most permissive access level wins.

Organization-Wide Defaults (OWD)

OWD sets the baseline record access for every object. Every other sharing mechanism builds on top of this.

OWD Options

OWD Setting	Internal Users See	Internal Users Edit	External Users	When to Use
Private	Only own records	Only own records	Only own records	Default for sensitive data; most objects
Public Read Only	All records	Only own records	Varies by external OWD	Read-access is universal, edits are restricted
Public Read/Write	All records	All records	Varies by external OWD	No record-level restriction needed
Public Read/Write/Transfer	All records	All records + transfer	N/A	Leads/Cases where anyone can reassign
Controlled by Parent	Inherits from parent	Inherits from parent	Inherits from parent	Detail objects in master-detail relationships
Public Full Access	All records	All records + all	N/A	Campaigns only

OWD Decision Framework

Figure 3. OWD selection starts with the most restrictive user, not the average user. A single user who must not see certain records forces Private OWD for that object across the entire org.

CTA Exam Pattern

If the scenario mentions ANY user who should not see a record type, the OWD must be Private. The board will probe whether you considered the most restrictive user first. Always design from the most restrictive user outward.

OWD Trade-offs

Approach	Pros	Cons
Start Private, open up	Maximum security; add access as needed; easy to justify	More sharing rules to manage; sharing recalculation on rule changes
Start Public, lock down	Simple; no sharing rules needed; fast queries	Cannot restrict below OWD; security gaps; hard to audit
Per-object analysis	Right-sized security per object	Requires deep understanding of data sensitivity per object

Performance Impact

Private OWD triggers the sharing calculation engine. Every record gets rows in the sharing tables. For objects with millions of records and complex sharing rules, sharing recalculation delays can stretch to hours. Factor this into the architecture when dealing with Large Data Volumes (LDV). See Data Architecture for LDV strategies.

CTA Exam Relevance

The board frequently probes the cross-domain cascade between OWD and LDV. Be prepared to articulate how setting OWD to Private on a 10M-record object affects sharing table size, query performance, and sharing recalculation time, and what mitigation strategies apply (skinny tables, deferred sharing calculation, archival).

Role Hierarchy

The role hierarchy controls automatic upward record visibility. Users higher in the hierarchy can see records owned by users below them (when “Grant Access Using Hierarchies” is enabled).

Role Hierarchy Design Patterns

Figure 4. Management-based hierarchies align data visibility to reporting lines. Each manager automatically sees records owned by everyone below them, which suits orgs where data access and reporting relationships coincide.

Figure 5. Territory-based role hierarchies organize visibility by geography rather than management chain. This works well for field sales but creates deep hierarchies that increase sharing recalculation overhead.

When to Use Each Pattern

Pattern	Best For	Risks
Management-based	Companies where visibility follows reporting lines; simple orgs	Breaks when matrix organizations exist; people who report to multiple managers
Territory-based	Geographic or segment-based businesses; field sales	Deep hierarchies hurt performance; hard to represent cross-territory access
Hybrid	Most enterprise orgs; territory for sales, management for service	Added complexity; harder to explain and maintain; more sharing rules needed
Flat (2-3 levels)	Organizations using sharing rules heavily; portal-heavy orgs	Loses automatic upward visibility; requires explicit sharing rules for managers

Role Hierarchy Design Guidelines

1. Keep it shallow. Aim for 5-7 levels maximum. Every level adds sharing calculation overhead.
2. Align to data access patterns, not the HR org chart. The role hierarchy is NOT an org chart.
3. One role per unique data access pattern. If two groups need identical access, they share a role.
4. Plan for growth. Adding roles is easy; restructuring is painful (sharing recalculation).
5. Disable hierarchy access selectively for sensitive objects (HR cases, compensation) by unchecking “Grant Access Using Hierarchies.”

Role Hierarchy is NOT an Org Chart

This is a common mistake that CTA candidates make, and the board will call it out. The role hierarchy determines data visibility, not reporting relationships. A VP of Marketing and a VP of Engineering might be at the same role hierarchy level even if one reports to the other, because their data access needs are identical.

CTA Exam Relevance

The board frequently asks “walk me through your role hierarchy” and then probes whether it mirrors the org chart or the data access model. If the hierarchy has more than 7 levels, expect a follow-up about sharing calculation performance. Be prepared to defend every level with a data access justification.

Sharing Rules

Sharing rules extend access beyond what OWD and role hierarchy provide. They are the primary tool for granting horizontal or cross-branch access.

Types of Sharing Rules

Type	Based On	Can Share With	Use Case
Ownership-based	Record owner’s role/group	Roles, roles + subordinates, public groups	”All records owned by Sales see also visible to Support”
Criteria-based	Field values on the record	Roles, roles + subordinates, public groups	”All Accounts with Region = ‘West’ shared with West Sales Team”
Guest user sharing rules	Criteria on record fields	Guest user groups	Portal/community guest access (heavily restricted)

Sharing Rules vs Alternatives

Mechanism	When to Prefer	When to Avoid
Sharing rules	Predictable, pattern-based access; small-to-medium number of rules	Complex logic requiring field calculations; >50 rules per object
Teams	Collaborative access for specific records (Account/Opp/Case)	Broad access patterns; objects that don’t support teams
Manual sharing	Ad hoc, user-initiated sharing for individual records	Automated or systematic access; large-scale sharing
Apex sharing	Complex business logic; dynamic access based on calculations	Simple patterns that sharing rules can handle; maintenance burden

Sharing Rule Limits and Performance

Sharing Rule Limits

• Up to 300 ownership-based sharing rules per object (expandable to 500 via Salesforce Support), up to 50 criteria-based sharing rules per object, and up to 50 guest user sharing rules per object — these are independent limits, not a shared pool
• Sharing recalculation runs asynchronously when rules are added/modified/deleted
• Large recalculations can take hours; plan changes during maintenance windows
• Each sharing rule creates rows in the share tables, which impacts query performance at scale

Implicit Sharing

Salesforce grants certain record access automatically based on data relationships. Implicit sharing happens without any explicit configuration, making it easy to overlook.

Implicit Sharing Rules

Scenario	Access Granted	Direction
Parent-child (Account-Contact/Opp/Case)	Account owner gets access to related Contacts, Opportunities, Cases	Parent to child (downward)
Child-parent	Contact/Opp/Case owner gets Read access to the parent Account	Child to parent (upward)
Portal user to Account	Portal users get Read access to their associated Account	Upward
Portal user’s Account owner	Account owner gets access to portal user’s data	Downward
Associated record sharing	Access to a record can grant access to related records	Lateral

Figure 6. Implicit sharing operates automatically without any sharing rule configuration. Account owners gain access to all related child records, while child record owners get Read access upward to the parent Account. This is a commonly overlooked security pathway.

CTA Exam Relevance

Implicit sharing is frequently tested because candidates forget about it. When Account OWD is set to Private but Opportunity OWD is Public Read, opportunity owners can still see the parent Account via implicit sharing. That may not be intended.

Apex Managed Sharing

When declarative sharing mechanisms (OWD, hierarchy, sharing rules, teams) fall short, Apex managed sharing provides programmatic control.

How Apex Managed Sharing Works

1. Records are shared by inserting rows into the object’s share table (e.g., AccountShare, CustomObject__Share)
2. The RowCause field must use an Apex Sharing Reason (defined on the object)
3. Shares with an Apex Sharing Reason survive ownership changes (unlike manual shares)
4. Only shares created with the same Apex Sharing Reason can be modified by that Apex code

When to Use Apex Managed Sharing

Scenario	Example
Complex business logic determines access	”Share Accounts with the user who last interacted, based on Activity history”
Dynamic team composition	”Share Cases with all users who have a specific skill certification”
Cross-object sharing logic	”Share Opportunities with users who own related Project records”
External system drives access	”Sharing based on territory assignments maintained in an external HR system”

Apex Managed Sharing Code Pattern

// Create a share record with an Apex Sharing Reason (custom objects only)
MyObject__Share shareRecord = new MyObject__Share();
shareRecord.ParentId = recordId;        // Record to share
shareRecord.UserOrGroupId = userId;     // User or Group receiving access
shareRecord.AccessLevel = 'Edit';       // Read, Edit, or All
shareRecord.RowCause = Schema.MyObject__Share.RowCause.Territory_Alignment__c; // Apex Sharing Reason
insert shareRecord;

Apex Managed Sharing Limitations

• Apex Sharing Reasons are available on custom objects only. Standard objects use RowCause = 'Manual' for programmatic sharing, which means those shares are deleted on ownership change.
• Cannot be used on objects with OWD set to Public Read/Write (no share table exists)
• Share records with RowCause = Manual are deleted when the record owner changes; shares with Apex Sharing Reasons survive ownership changes
• Sharing reasons are defined per custom object and cannot be reused across objects
• Testing requires System.runAs() to verify access
• Up to 10 Apex Sharing Reasons per custom object

CTA Exam Relevance

The board probes Apex Managed Sharing when scenarios include dynamic, calculation-based access requirements that declarative sharing cannot express. Be ready to explain the RowCause = 'Manual' pitfall for standard objects (shares deleted on ownership change) and justify when the maintenance cost of Apex sharing is worth it versus restructuring the sharing model.

Account Teams and Opportunity Teams

Teams provide collaborative, record-specific access for Account and Opportunity objects.

Teams Comparison

Feature	Account Teams	Opportunity Teams	Case Teams
Configurable roles	Yes (custom team roles)	Yes (custom team roles)	Yes (predefined + custom)
Default teams	Yes (auto-add to new records)	Yes (auto-add from Account Team)	Yes (assignment rules)
Sharing access	Read Only, Read/Write	Read Only, Read/Write	Read/Write
Related object access	Contacts, Opportunities, Cases	N/A	N/A
Can be mass-updated	Yes (Data Loader)	Yes (Data Loader)	Yes

When to Use Teams vs Sharing Rules

• Teams: When access varies per record and is determined by individual relationships (e.g., “this specific Account has a dedicated support engineer”)
• Sharing rules: When access follows a pattern across many records (e.g., “all Accounts in the West region are visible to the West Sales team”)

Territory Management and the Sharing Model

Sales Territories (formerly Enterprise Territory Management) provides a parallel access model to the role hierarchy. It directly affects sharing calculations because territory assignments create additional share table entries.

For full architecture details, including the object model, hierarchy design, assignment rules, and scaling limits, see Territory Management Architecture.

Key interaction with the sharing model:

Consideration	Role Hierarchy	Territory Management
Account assignment	Based on owner	Based on territory rules (multi-territory possible)
User in multiple groups	One role only	Multiple territories
Sharing calculation	Standard	Additional sharing calculations with more share table entries
Best for	Simple org structures	Complex sales organizations with overlapping territories

When to Recommend Territory Management

Recommend Sales Territories when: (1) accounts need to be assigned to multiple territories simultaneously, (2) territory-based forecasting is required, (3) the sales organization has overlapping territories that the role hierarchy cannot represent, or (4) account assignment rules are geographic/industry/revenue-based rather than ownership-based.

Sharing Model Design Process

When designing a sharing model for a CTA scenario, follow this systematic approach:

Step-by-Step Design Process

Figure 7. A complete sharing model design follows a fixed sequence: set the floor first (OWD), then build upward with hierarchy and rules. Skipping steps, especially performance validation and documentation, is a common cause of CTA board failures.

Common CTA Sharing Model Mistakes

1. Setting OWD too open. Starting with Public Read/Write and trying to restrict. You cannot restrict below OWD.
2. Confusing role hierarchy with org chart. The hierarchy is about data access, not reporting.
3. Overusing manual sharing. It does not survive record ownership changes and cannot be automated.
4. Ignoring implicit sharing. Forgetting that child record owners get Read access to parent Accounts.
5. Too many sharing rules. This usually indicates the OWD or role hierarchy design is wrong.
6. Ignoring external users. External OWD is separate and defaults to the internal OWD or more restrictive.
7. Not considering LDV impact. Private OWD on high-volume objects creates massive share tables.

CTA Exam Relevance

Security (Domain 2) is the second highest failure domain on the CTA exam. The sharing model is the cornerstone.

What the board looks for:

• Systematic approach to OWD selection (not guessing)
• Role hierarchy designed for data access, not org chart
• Clear articulation of why each sharing mechanism was chosen
• Understanding of implicit sharing and its security implications
• Performance awareness, specifically sharing calculation impact on LDV
• Portal/external user sharing considerations

Common board questions:

• “Why did you choose Private OWD for this object?”
• “How would your sharing model change if they add 50,000 partner users?”
• “What happens to sharing when a record owner changes?”
• “How does your role hierarchy handle matrix management?”

Related Topics

• Field & Object Security: permissions complement the sharing model
• Portal Security: external user sharing has special rules
• Programmatic Security: Apex sharing enforcement
• Decision Guides: flowcharts for OWD and sharing strategy selection
• Security Trade-offs: sharing model complexity vs performance
• Data Architecture: LDV impact on sharing calculations

Sources

• Salesforce Help: Sharing Settings
• Salesforce Help: Role Hierarchy
• Salesforce Help: Sharing Rules
• Salesforce Help: Enterprise Territory Management
• Salesforce Architects: Record Access Architecture
• Salesforce Architects: Sharing and Visibility Designer Guide
• Salesforce Architects: Platform Sharing Architecture
• Salesforce Developers: Record-Level Access: Under the Hood
• Salesforce Help: Sales Territories Implementation Guide