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. Getting the sharing model wrong cascades into performance issues, security holes, and governance nightmares.

Record access in Salesforce is cumulative — you can open access but never restrict it below the baseline set by Organization-Wide Defaults (OWD). Think of it as a layered system where each layer can only add access.

flowchart TB
    subgraph "Record Access Stack (Cumulative)"
        direction TB
        OWD["1. Organization-Wide Defaults (OWD)\nBaseline — most restrictive needed"]
        RH["2. Role Hierarchy\nUpward visibility"]
        SR["3. Sharing Rules\nCriteria-based & ownership-based"]
        Teams["4. Account/Opp/Case Teams\nCollaborative access"]
        TM["5. Territory Management\nGeography/account-based"]
        Manual["6. Manual Sharing\nUser-granted ad hoc"]
        Apex["7. Apex Managed Sharing\nProgrammatic, custom logic"]
    end

    OWD --> RH --> SR --> Teams --> TM --> Manual --> Apex

    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

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 is critical for debugging “why can/can’t this user see this record?” questions on the CTA board.

flowchart TD
    Request["User requests\nrecord access"] --> OWDCheck{"Is OWD Public\nRead/Write?"}
    OWDCheck -->|Yes| FullAccess["Access Granted\n(No sharing calculation needed)"]
    OWDCheck -->|No| OwnerCheck{"Is user the\nrecord owner?"}
    OwnerCheck -->|Yes| OwnerAccess["Full Access\n(Owner always has access)"]
    OwnerCheck -->|No| HierCheck{"Is user above owner\nin role hierarchy?\n(Grant Access Using\nHierarchies enabled?)"}
    HierCheck -->|Yes| HierAccess["Access Granted\n(Inherited from hierarchy)"]
    HierCheck -->|No| ShareTable{"Check Object Share Table:\nDo any sharing rows grant\naccess to this user or\ntheir groups?"}
    ShareTable -->|"Sharing Rule match"| RuleAccess["Access Granted\n(via Sharing Rule)"]
    ShareTable -->|"Team member match"| TeamAccess["Access Granted\n(via Team membership)"]
    ShareTable -->|"Territory match"| TerrAccess["Access Granted\n(via Territory assignment)"]
    ShareTable -->|"Manual share match"| ManualAccess["Access Granted\n(via Manual Share)"]
    ShareTable -->|"Apex share match"| ApexAccess["Access Granted\n(via Apex Managed Sharing)"]
    ShareTable -->|"No match"| ImplicitCheck{"Does implicit sharing\napply? (Parent-child\nrelationship)"}
    ImplicitCheck -->|Yes| ImplicitAccess["Access Granted\n(Implicit sharing)"]
    ImplicitCheck -->|No| Denied["Access Denied"]

    style FullAccess fill:#2e7d32,color:#fff
    style OwnerAccess fill:#2e7d32,color:#fff
    style HierAccess fill:#2e7d32,color:#fff
    style RuleAccess fill:#2e7d32,color:#fff
    style TeamAccess fill:#2e7d32,color:#fff
    style TerrAccess fill:#2e7d32,color:#fff
    style ManualAccess fill:#2e7d32,color:#fff
    style ApexAccess fill:#2e7d32,color:#fff
    style ImplicitAccess fill:#2e7d32,color:#fff
    style Denied fill:#c62828,color:#fff

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:

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.
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.
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. This is the single most important sharing decision you make.

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 — when 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

flowchart TD
    Start["Does ANY user need to be\nrestricted from seeing records\nof this object?"] -->|Yes| Private["Set OWD = Private"]
    Start -->|No| ReadQ["Does ANY user need to be\nrestricted from EDITING records?"]
    ReadQ -->|Yes| PRO["Set OWD = Public Read Only"]
    ReadQ -->|No| PRWT{"Is this Leads or Cases\nwhere anyone can reassign?"}
    PRWT -->|Yes| Transfer["Set OWD = Public Read/Write/Transfer"]
    PRWT -->|No| PRW["Set OWD = Public Read/Write"]

    Private --> Hierarchy{"Should managers\nautomatically see\nsubordinate records?"}
    Hierarchy -->|Yes| GrantUp["Enable 'Grant Access\nUsing Hierarchies'"]
    Hierarchy -->|No| NoGrant["Disable hierarchy access\n(rare — mainly for HR data)"]

    style Private fill:#c62828,color:#fff
    style PRO fill:#e65100,color:#fff
    style PRW fill:#2e7d32,color:#fff
    style Transfer fill:#1565c0,color:#fff

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, this can cause sharing recalculation delays of hours. Factor this into your architecture when dealing with Large Data Volumes (LDV). See Data Architecture for LDV strategies.

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

flowchart TD
    subgraph "Pattern 1: Management-Based (Traditional)"
        CEO1["CEO"] --> VP1["VP Sales"]
        CEO1 --> VP2["VP Service"]
        VP1 --> Dir1["Regional Director"]
        Dir1 --> Mgr1["Sales Manager"]
        Mgr1 --> Rep1["Sales Rep"]
        VP2 --> Dir2["Service Director"]
        Dir2 --> Mgr2["Support Manager"]
        Mgr2 --> Agent1["Support Agent"]
    end

flowchart TD
    subgraph "Pattern 2: Territory-Based"
        Global["Global"] --> AMER["Americas"]
        Global --> EMEA["EMEA"]
        Global --> APAC["APAC"]
        AMER --> US["US"]
        AMER --> LATAM["LATAM"]
        US --> West["US West"]
        US --> East["US East"]
        West --> SalesWest["Sales - West"]
        West --> ServiceWest["Service - West"]
    end

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

Keep it shallow — aim for 5-7 levels maximum. Every level adds sharing calculation overhead
Align to data access patterns, not the HR org chart. The role hierarchy is NOT an org chart
One role per unique data access pattern — if two groups need identical access, they share a role
Consider future growth — adding roles is easy, restructuring is painful (sharing recalculation)
Disable hierarchy access selectively — for sensitive objects (HR cases, compensation), uncheck “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.

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

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)

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

Maximum sharing rules per object: 300 total sharing rules per object (up to 50 criteria-based; no separate ownership-based sub-limit)
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 — impacts query performance at scale

Salesforce grants certain record access automatically based on data relationships. Understanding implicit sharing is critical because it happens without any explicit configuration.

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

flowchart TD
    AccOwner["Account Owner\n(Full Access)"] -->|"Implicit: sees all children"| Contact["Contact\n(Owned by User B)"]
    AccOwner -->|"Implicit: sees all children"| Opp["Opportunity\n(Owned by User C)"]
    AccOwner -->|"Implicit: sees all children"| Case["Case\n(Owned by User D)"]

    Contact -->|"Implicit upward: Read on parent"| Account["Account Record"]
    Opp -->|"Implicit upward: Read on parent"| Account
    Case -->|"Implicit upward: Read on parent"| Account

    PortalUser["Portal User"] -->|"Implicit: Read on associated Account"| Account

    style Account fill:#1565c0,color:#fff
    style AccOwner fill:#2e7d32,color:#fff
    style PortalUser fill:#e65100,color:#fff

CTA Exam Relevance

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

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

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

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”

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

Apex Managed Sharing Limitations

Cannot be used on standard objects with OWD set to Public Read/Write (no share table exists)
Share records are deleted when the record owner changes (unless using Apex Sharing Reasons)
Sharing reasons are defined per object and cannot be reused across objects
Testing requires System.runAs() to verify access

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

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

Enterprise Territory Management (ETM2) provides account-based territory assignments that drive both sharing and reporting.

Territory Management Architecture

flowchart TD
    TM["Territory Model"] --> TT["Territory Type\n(e.g., Sales, Service)"]
    TT --> T1["Territory: US West"]
    TT --> T2["Territory: US East"]
    TT --> T3["Territory: EMEA"]

    T1 --> AR1["Assignment Rules\n(Revenue > $1M AND State IN West)"]
    T1 --> U1["Users Assigned\n(Sales Reps)"]
    T1 --> A1["Accounts Assigned\n(via Rules or Manual)"]

    AR1 -->|"Auto-assign"| A1

    style TM fill:#1565c0,color:#fff
    style TT fill:#1976d2,color:#fff

Territory Model Hierarchy (Sales Territories)

Name Change

Enterprise Territory Management (ETM2) was renamed to Sales Territories in Spring ‘25 (release 250). All Salesforce documentation now uses the new name, but the CTA exam may still reference “Enterprise Territory Management” or “ETM2.”

The territory model represents your entire sales organization in a hierarchy independent of the role hierarchy. Unlike roles (one per user), users can be assigned to multiple territories simultaneously.

flowchart TD
    Model["Territory Model\n(Only 1 active at a time)"]
    Model --> TT1["Territory Type: Named Accounts\n(Priority: 1)"]
    Model --> TT2["Territory Type: Geographic\n(Priority: 2)"]
    Model --> TT3["Territory Type: Industry Vertical\n(Priority: 3)"]

    TT2 --> T1["Americas"]
    T1 --> T2["US West"]
    T1 --> T3["US East"]
    T1 --> T4["LATAM"]

    T2 --> AR["Assignment Rules:\n- State IN (CA, OR, WA, NV)\n- Revenue > $500K"]
    T2 --> Users["Assigned Users:\n- Rep A, Rep B"]
    T2 --> Accounts["Assigned Accounts:\n(via rules + manual)"]

    TT1 --> T5["Strategic Accounts"]
    T5 --> T6["Enterprise Named"]
    T5 --> T7["Mid-Market Named"]

    style Model fill:#1565c0,color:#fff
    style TT1 fill:#1976d2,color:#fff
    style TT2 fill:#1976d2,color:#fff
    style TT3 fill:#1976d2,color:#fff

Key architecture points:

Territory Types are organizational labels (not hierarchical) — they categorize territories by characteristics (geographic, named account, industry) and assign priority
Assignment Rules run at the model level and automatically place accounts into territories based on field criteria
An account can belong to multiple territories simultaneously (unlike record ownership, which is singular)
Only one territory model can be active at a time (2 models in Enterprise Edition, 4 in Unlimited/Performance)
Territory-based forecasting runs independently of role-hierarchy-based forecasting

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
Forecasting	Standard forecasting	Territory-based forecasting
Complexity	Lower	Higher — additional model to maintain
Sharing calculation	Standard	Additional sharing calculations
Best for	Simple org structures	Complex sales organizations with overlapping territories

When to Recommend Territory Management

Recommend ETM2 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.

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

Step-by-Step Design Process

flowchart TD
    Step1["1. Inventory all objects\nand their sensitivity"] --> Step2["2. Identify the MOST\nrestrictive user per object"]
    Step2 --> Step3["3. Set OWD per object\nbased on most restrictive user"]
    Step3 --> Step4["4. Design role hierarchy\nbased on data access patterns"]
    Step4 --> Step5["5. Identify access gaps\nnot covered by OWD + hierarchy"]
    Step5 --> Step6["6. Fill gaps with sharing rules\n(criteria-based preferred)"]
    Step6 --> Step7["7. Evaluate remaining gaps\nfor teams, territories, or Apex"]
    Step7 --> Step8["8. Validate against\nperformance requirements"]
    Step8 --> Step9["9. Document and justify\nevery sharing mechanism used"]

    style Step1 fill:#1565c0,color:#fff
    style Step3 fill:#c62828,color:#fff
    style Step9 fill:#2e7d32,color:#fff

Setting OWD too open — starting with Public Read/Write and trying to restrict. You cannot restrict below OWD
Confusing role hierarchy with org chart — the hierarchy is about data access, not reporting
Overusing manual sharing — it does not survive record ownership changes and cannot be automated
Ignoring implicit sharing — forgetting that child record owners get Read access to parent Accounts
Too many sharing rules — indicates the OWD or role hierarchy design is wrong
Ignoring external users — external OWD is separate and defaults to the internal OWD or more restrictive
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 of this domain.

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 — 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?”

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

Sharing Model: OWD, Role Hierarchy & Sharing Rules

How Record Access Works: The Sharing Stack

Record Access Calculation Flow

Organization-Wide Defaults (OWD)

OWD Options

OWD Decision Framework

OWD Trade-offs

Role Hierarchy

Role Hierarchy Design Patterns

When to Use Each Pattern

Role Hierarchy Design Guidelines

Sharing Rules

Types of Sharing Rules

Sharing Rules vs Alternatives

Sharing Rule Limits and Performance

Implicit Sharing

Implicit Sharing Rules

Apex Managed Sharing

How Apex Managed Sharing Works

When to Use Apex Managed Sharing

Apex Managed Sharing Code Pattern

Account Teams and Opportunity Teams

Teams Comparison

When to Use Teams vs Sharing Rules

Territory Management

Territory Management Architecture

Territory Model Hierarchy (Sales Territories)

Territory Management vs Role Hierarchy for Sharing

Sharing Model Design Process

Step-by-Step Design Process

Common CTA Sharing Model Mistakes

CTA Exam Relevance

Related Topics

Sources