# Record access design: OWDs, hierarchies and territories

*Platform Data Architect Study Guide · Data Modeling/Database Design · Last updated October 26, 2026 · https://www.certifyforce.com/study-guide/platform-data-architect/data-modeling-database-design/record-access-design-owds-hierarchies-and-territories*

How to open access from restrictive organization-wide defaults with role hierarchies, sharing rules, teams, territories and Apex managed sharing, what implicit sharing does and doesn't grant, and how restriction rules and View All fit a scalable model.

- Certification: Salesforce Platform Data Architect
- Exam section: Data Modeling/Database Design
- Study guide: https://www.certifyforce.com/study-guide/platform-data-architect

**Official exam objective:**

> Given a scenario, recommend approaches and techniques to design a scalable data model that obeys the current security and sharing model.

## What the exam expects

- Set organization-wide defaults to the most restrictive level and open access with the lightest component that fits.
- Predict what parent and child implicit sharing grant on Account, and why account hierarchies and custom objects get none.
- Design a role hierarchy around levels of data access, and decide when Sales Territories (Enterprise Territory Management) beats roles or teams.
- Choose among owner-based rules, criteria-based rules, nested public groups, teams, Apex managed sharing, restriction rules and object-level View All.

Key terms: **organization-wide default (OWD)** (baseline record access per object); **implicit sharing** (built-in Account parent/child access); **Controlled by Parent** (child access follows the master); **restriction rule** (filters records a user can already reach); **Apex managed sharing** (share records written by code, kept across owner changes).

## Key facts

| Fact | Detail | Source |
|---|---|---|
| Role hierarchy depth | Best practice: no more than 10 levels of branches | [Sharing Architecture](https://architect.salesforce.com/docs/architect/fundamentals/guide/platform-sharing-architecture) |
| Public group nesting | No more than five levels | [Sharing Architecture](https://architect.salesforce.com/docs/architect/fundamentals/guide/platform-sharing-architecture) |
| Sharing rules per object | 300 total; 50 criteria-based and guest user | [Sharing Architecture](https://architect.salesforce.com/docs/architect/fundamentals/guide/platform-sharing-architecture) |
| Grant Access Using Hierarchies | Configurable for custom objects only | [Sharing Architecture](https://architect.salesforce.com/docs/architect/fundamentals/guide/platform-sharing-architecture) |
| Implicit sharing | Account children only; not custom objects; can't be turned off | [Sharing Architecture](https://architect.salesforce.com/docs/architect/fundamentals/guide/platform-sharing-architecture) |
| Parent implicit sharing | Read-only; not granted by View All on the child | [Implicit Sharing](https://developer.salesforce.com/docs/atlas.en-us.draes.meta/draes/draes_object_relationships_implicit_sharing.htm) |
| Teams | One team per Account, Opportunity or Case record | [Sharing Architecture](https://architect.salesforce.com/docs/architect/fundamentals/guide/platform-sharing-architecture) |
| Apex managed sharing | Kept across owner changes; sharing reasons on custom objects only | [Apex Sharing](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_bulk_sharing_understanding.htm) |
| Restriction rules per object | 2 active (Enterprise, Developer); 5 (Performance, Unlimited) | [Sharing Architecture](https://architect.salesforce.com/docs/architect/fundamentals/guide/platform-sharing-architecture) |

## Check yourself

- Why is an object-level View All permission preferred over View All Data for an audit team that reads one object?
- When is territory management a better fit than account teams?
- Why should public groups not be nested more than five levels?
- What happens to Apex managed shares when the record owner changes?

## Sources

- [Platform Sharing Architecture](https://architect.salesforce.com/docs/architect/fundamentals/guide/platform-sharing-architecture)
- [Implicit Sharing](https://developer.salesforce.com/docs/atlas.en-us.draes.meta/draes/draes_object_relationships_implicit_sharing.htm)
- [Understanding Sharing (Apex)](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_bulk_sharing_understanding.htm)
- [Sales Territories](https://help.salesforce.com/s/articleView?id=sales.tm2_intro.htm&language=en_US&type=5)
- [Object Relationships Overview](https://help.salesforce.com/s/articleView?id=overview_of_custom_object_relationships.htm&language=en_US&type=5)
- [Considerations for Object Relationships](https://help.salesforce.com/s/articleView?id=relationships_considerations.htm&language=en_US&type=5)

## About the full unit

The "Core concepts", "Exam traps" and "Worked scenario" sections of this unit, its 14 linked practice questions, and unlimited timed mock exams are included with the Platform Data Architect pack (USD $19): https://www.certifyforce.com/practice-exams