3.1 Org-Wide Defaults, Roles, Sharing Rules, and Teams

Start With The Record Access Baseline

Org-wide defaults, often shortened to OWD, answer the first record access question: what can a user do with records they do not own and that have not been shared to them another way? In Setup, use Sharing Settings to review object-level defaults such as Private, Public Read Only, Public Read/Write, Controlled by Parent, and external sharing defaults where available. OWD does not grant object CRUD. A user still needs object permission from a profile or permission set before record sharing can matter.

Think of record access as a gate sequence. First, can the user log in and use the app? Second, does the user have object permission such as Read, Create, Edit, or Delete? Third, does the user have record access through ownership, OWD, role hierarchy, sharing rule, team, territory, queue, manual share, implicit parent-child access, or a broad permission such as View All or Modify All on the object? If any required gate fails, the user sees a symptom.

OWD Choice And Scenario Judgment

Private is appropriate when users should see only their own records unless another sharing mechanism opens access. Sales opportunities, sensitive cases, custom application records, and compensation-related objects often start private. Public Read Only works when broad visibility is allowed but uncontrolled editing is not. Public Read/Write is a broad model and should be chosen only when business policy accepts open record editing for that object.

Controlled by Parent means access to a child record follows access to the parent. It is common in master-detail relationships and some standard relationship behaviors. If a custom child object is Controlled by Parent under Account, asking who can see the child starts with who can see the parent account. Exam scenarios often hide this clue in the data model description.

External defaults matter when Experience Cloud, partners, or external users are involved. External users frequently need a stricter baseline than internal users. If a scenario separates internal sales employees from partner users, do not assume the same OWD applies to both audiences.

Role Hierarchy Opens Upward

The role hierarchy grants access upward from record owners to users above them in the hierarchy when the object allows hierarchy-based access. A sales rep who owns an opportunity may be visible to the regional manager above that rep, even if Opportunity OWD is Private. The role hierarchy is about data visibility, not login ability, field access, or app navigation.

Do not confuse roles with profiles. A profile or permission set grants what the user can do to an object. A role helps decide which records the user can access. A user can have the System Administrator profile and no role, or a highly placed role and a restricted custom profile. The effective result depends on both tracks.

A good role design supports reporting and management visibility. It does not need to mirror every dotted-line reporting relationship. Too many roles create maintenance overhead and can slow sharing recalculations. Too few roles force excessive sharing rules. The administrator's job is to model the record visibility policy with enough precision and stability.

Sharing Rules, Teams, And Manual Shares

Sharing rules open record access for many records that meet defined criteria or ownership patterns. Owner-based rules share records owned by one role, role-and-subordinates group, queue, or public group with another group. Criteria-based rules share records when fields match defined values. For example, high-priority cases in a region can be shared with an escalation queue or support manager group.

Teams are record-specific collaboration tools. Account teams, opportunity teams, and case teams are useful when a named group of people works one record or customer relationship. They are more flexible than a global sharing rule when collaboration varies record by record. Manual sharing is even more direct, but it is best for exceptions, not primary architecture.

Public groups package users, roles, roles and subordinates, queues, or other groups for sharing. They are reusable and help avoid hard-coding access one user at a time. When a sharing rule says share with Sales Operations, the clean implementation is usually a public group maintained by policy, not dozens of individual shares.

Access Decision Workflow

Use this workflow when selecting a sharing mechanism:

1. Confirm the user needs access to records, not merely a tab, app, or field.
2. Confirm object permission exists for the needed action.
3. Set OWD to the most restrictive baseline that matches business policy.
4. Use the role hierarchy for manager visibility that follows ownership structure.
5. Use sharing rules for repeatable groups or criteria.
6. Use teams for record-specific collaboration on accounts, opportunities, and cases.
7. Use manual sharing only for approved exceptions.
8. Use View All or Modify All on the object only when broad administrative access is intended.

Scenario: Opportunity OWD is Private. Sales reps should see only their own opportunities, regional managers should see their reps' opportunities, and a Deal Desk group should see all opportunities over a threshold. The baseline is Private, the manager path is the role hierarchy, and the threshold access is a criteria-based sharing rule to a public group. Public Read/Write would be too broad.

Scenario: One strategic account needs an implementation specialist added for six months. An account team is cleaner than a new org-wide sharing rule. If every strategic account needs implementation visibility, then a criteria-based sharing rule or territory design may be better.

Troubleshooting Sequence

When a user cannot see a record, do not start by changing OWD. First identify the exact user, object, record, action, and expected result. Check object Read permission. Check whether the user owns the record. Check the OWD. Check role hierarchy position. Check public group membership, sharing rules, teams, territories, queues, manual shares, and broad object permissions. Then test with a controlled user or Login-As workflow if policy allows.

When a user can see but cannot edit, the issue may be record access level, object Edit permission, field-level security, record type, validation rule, approval lock, page layout, flow, or ownership. Record visibility and editability are not the same. This distinction is a frequent exam trap because the symptom says access but the fix may be object permission or field access.