Salesforce OWD, Role Hierarchy, and Sharing Rules

The mental model: lock down first, open later

In Salesforce, record security is easier when you think in layers. First, the user needs permission to use the object. Then you decide which records that user can view or edit. Organization-wide defaults set the baseline for records the user does not own. If that baseline is restrictive, other tools open access selectively: role hierarchy, sharing rules, manual sharing, teams, territory management, or other mechanisms depending on the case.

The key idea is that OWD, role hierarchy, and sharing rules do not replace object permissions or field-level security. If a user does not have Read on Opportunity, a sharing rule does not solve the issue. If the user has Read on Opportunity but cannot see opportunities owned by other users because OWD is private, then you are looking at a record access problem. This difference appears constantly in exam questions.

Practical rule: object permission answers "can they use this object"; field-level security answers "can they see this field"; sharing answers "can they see this specific record".

Organization-wide defaults

Organization-wide defaults, or OWD, define the default access users have to records they do not own. In other words, OWD answers how open or closed each object is before exceptions are applied. For many objects, typical models are Private, Public Read Only, and Public Read/Write. Some objects have special options such as Controlled by Parent.

A good administrator does not choose OWD based on the average user; they choose it based on the most restricted user who still needs to work with the object. If the most restricted person should never see other users' records, Private often makes sense. If everyone can see records but only owners should edit them, Public Read Only is a candidate. If everyone can see and edit all records for the object, Public Read/Write is possible, but it should be justified carefully.

In certification questions, OWD usually appears when the wording mentions baseline access, default internal access, records users do not own, private records, or access model. Remember that OWD can close the baseline, but it cannot grant more object permission than the user already has. It also is not for one-off exceptions; the opening layers are for that.

Role hierarchy

The role hierarchy opens vertical access. Users above other users in the hierarchy can access records owned by users below them, within the sharing model. This supports supervision scenarios: managers who need to see their reps' opportunities, directors who need visibility into their managers' data, or regional leads who need reporting access across a team.

Role hierarchy is not the same as an org chart. It should model data access needs, not necessarily exact titles or reporting lines. Sometimes several positions are consolidated into one role because they need the same access. Sometimes a person in the org chart does not need access to every record owned by another person. The exam rewards recognizing that difference.

For custom objects, Salesforce allows control of the Grant Access Using Hierarchies option in certain cases. Standard objects have more established hierarchy behavior. If a question says managers must see their subordinates' records, role hierarchy is often a strong candidate. If the users who need access are not in the same vertical line, you probably need another tool.

Sharing rules are automatic exceptions to the OWD baseline. They open access to users grouped by role, role and subordinates, territory, or public group. A rule answers three questions: which records are shared, who receives access, and what level of access they receive. Records can be selected by owner or by criteria based on field values.

Sharing rules only open access; they do not restrict access below OWD. If OWD is already Public Read/Write, a sharing rule adds little because everyone already has broad access. If OWD is Private or Public Read Only, a sharing rule can grant Read Only or Read/Write to a specific group that needs to collaborate with records it does not own.

Look for sharing rules when the question says that a set of users outside the hierarchy needs automatic and repeatable access. For example, legal needs to see contracts from certain regions, support needs read access to premium customer accounts, or marketing needs access to campaigns with a certain status. If the criterion is stable, automatic, and applies to many records, sharing rule is cleaner than manual sharing.

Manual sharing, teams, and territories

Not every record access problem is solved with role hierarchy or sharing rules. Manual sharing is for individual exceptions when a record owner or authorized user shares one specific record. It is useful if the case is rare, not if it repeats every day. If the exam says one-off, ad hoc, or single record, manual sharing can be a reasonable option.

Account Teams, Opportunity Teams, and Case Teams help when several people collaborate around specific records. Instead of opening a broad rule, you can represent record collaborators and control access through their team role. Territory management helps when access depends on sales territories and more complex selling structures, not only a simple management hierarchy.

Public groups are supporting pieces. They are not a sharing solution by themselves, but they simplify who receives access. You can create a group with users, roles, roles and subordinates, or other groups, and then use it in sharing rules or related settings. In exam questions, public group is often part of the answer when you need to share with a combination of users that does not fit cleanly into one role branch.

Common traps when studying sharing

The first trap is trying to solve record visibility with permission sets. A permission set can grant Read, Create, Edit, or Delete on an object, but it does not automatically decide which records owned by other users are visible. If the question says the user can see their own opportunities but not the team's opportunities, the issue is probably not object permission; it is record access.

The second trap is using role hierarchy for horizontal access. If two teams at the same level need to share records with each other, moving roles around can distort the model. A sharing rule to a public group may be better. The third trap is using manual sharing for recurring needs. If every premium case must be visible to a support group, automate with a rule or specific tool instead of depending on someone sharing records one by one.

The fourth trap is forgetting that large OWD or hierarchy changes can trigger sharing recalculation and affect performance in large orgs. On the Administrator exam you usually do not need deep architecture detail, but you should understand that changing the baseline model is not a casual decision. If the need is a limited exception, avoid answers that change OWD for the whole organization.

How to recognize the correct answer

Start by asking whether the problem is functional access or visibility. If the user cannot create, edit, or delete their own records, check object permissions, profile, or permission set. If they can work with their own records but not other users' records, check OWD, role hierarchy, and sharing. Then identify the pattern: vertical, horizontal, individual, or territory-based.

Vertical usually points to role hierarchy: a manager sees subordinate records. Horizontal or cross-group access usually points to sharing rules. Individual or temporary access often points to manual sharing. Collaboration around accounts, opportunities, or cases can point to teams. Sales segmentation by geography, industry, or account can point to territories. If the question asks for the most restrictive baseline, OWD comes before exceptions.

Quick decision checklist:

Does the user have object and field permission?
Is the problem with owned records or other users' records?
Is the access need vertical, horizontal, one-off, or territory-based?
Is OWD already open, or do you need an exception?
Does the solution open access without granting more than needed?

Official resources and practice

To study this topic, draw scenarios. Write the object, its OWD, who owns the record, who needs to see it, and what relationship exists between them. If you can explain why a permission set does not solve sharing, and why a sharing rule does not grant object permissions, you have the foundation for most record security questions.

BlueForce is not affiliated with Salesforce. This guide is original editorial content based on study experience, public objectives, and official resources.