💬 In plain words: A user needs two separate grants before an agent is useful to them. One lets them use the agent at all. The other lets the agent reach data. They fail in completely different ways. 📌 Example: A Meridian rep is granted every object the agent touches, but not Agent Access. The agent simply does not appear for them. Nothing is wrong with the data model. 🎬 Real-Life Example: The Agent Nobody Could Find The Old/Bad Way: An admin built an agent, activated it, tested it in preview, and told the team it was live. Nobody could see it — including the admin, outside preview. Why this fails: Agent Access is a separate grant inside a permission set. Building an agent does not grant you the right to use it. Preview bypasses this, which is exactly why the gap goes unnoticed. The New/Good Way: 1. In the permission set, find the Agent Access section. 2. Add the specific agent to the enabled list. 3. As...
⚡ 1-Minute Summary
• Sharing only ever ADDS access. Restriction rules are the one tool that subtracts.
• Set the org-wide default to the most closed honest answer. Then open up on purpose.
• Sharing decides WHICH ROWS. CRUD and FLS decide which objects and fields. Never mix them up.
Module map
MODULE 3 root: 'Who can see which ROWS?'
├─ OWD (baseline) + Hierarchy (vertical)
├─ Sharing Rules (lateral) + Manual/Apex share (per-record)
├─ Restriction Rules (the ONLY subtraction)
├─ View/Modify All (OBJECT perm — OVERRIDES sharing)
└─ with/without/inherited sharing (Apex enforcement)
💬 In plain words: Org-Wide Defaults (OWD) is the default lock on every record — start with the tightest setting the business allows. The role hierarchy then opens records UPWARD: managers see what their team sees. Everything else (sharing rules, manual shares) only ADDS access; nothing below OWD can remove it.
📌 Example: Case OWD = Private. Asha owns case 00123 — only Asha, managers above her in the role tree. And anyone a sharing rule covers can see it. Her teammate at the same level? Nothing.
Concept
Organization-Wide Defaults, or OWD, set the baseline record access on each object: Private, Public Read Only, Public Read/Write, or Controlled by Parent.
• Everything else in the sharing model can only ADD access on top of that baseline.
• Nothing subtracts from it. The Role Hierarchy grants access vertically.
• A user above the owner in the hierarchy gets the owner's access. That is mandatory on standard objects.
• On custom objects you can switch it off, through 'Grant Access Using Hierarchies'.
• Underneath, access is stored as rows in share tables — AccountShare, MyObj__Share — and in group-membership tables. That is why sharing design has direct performance consequences at LDV scale.
• The architect's axiom: set OWD to the most restrictive setting any user type requires, then open it up.
Record access = the MOST access any rule grants (a UNION)
├─ OWD → baseline (most restrictive)
├─ Role Hierarchy → vertical (managers see reports' data)
├─ Sharing Rules → lateral (group→group, criteria)
├─ Manual / Apex share→ per-record
├─ Teams → account/opp/case teams
└─ View All / Modify All → OBJECT perm, OVERRIDES all sharing
🧠OWD golden rule: Set OWD to the MOST restricted user's need, then OPEN UP. Sharing only ever ADDS access (except Restriction Rules).
One term to define, because the book asks you to use it and nobody explains it. Data classification is a set of compliance fields that sit ON a field definition: who owns the data, how it may be used, and how sensitive it is. You set them in Object Manager on each field. They do not change access by themselves. What they give you is an answer to the auditor: “where is our personal data?” becomes a query instead of a workshop. And Shield policies and reports can key off the values.
You set all of this in one screen: Setup, then Sharing Settings. Each object has a row there. That row holds the internal default, the external default, and the “Grant Access Using Hierarchies” tick box. The tick box is grayed out for standard objects, which is how you can tell at a glance that only custom objects can switch it off.
🧠360 Card — OWD & Role Hierarchy
Rule: set OWD for the most restricted legitimate user. Then open up. Sharing only ever adds.
Gain: one baseline per object. Every later tool only widens it, so access stays a union you can reason about.
Reach for: set the org-wide default to the most restricted honest answer first. Then open up in this order. Role hierarchy for management lines. Sharing rules for stable groups. Teams for one deal. Manual sharing for one-off cases. And Apex managed sharing last, only when the access is worked out from data and no rule can say it.
Price: tighten OWD later and the platform recalculates sharing for every affected record. On a big org that is an outage-sized job.
Limits: four settings — Private, Public Read Only, Public Read/Write, Controlled by Parent. External OWD is set separately. "Grant Access Using Hierarchies" can be switched off for custom objects only. Standard objects always inherit upward.
Mirror — Public Read/Write: nothing to compute and nothing to debug. And no way to keep anything private later.
Later: every sharing rule, team and Apex share in the org sits on top of this. It is the hardest decision in the book to reverse.
At volume: moving a role with thousands of users rewrites share rows for every record their access touches. Plan it like a migration, with deferred sharing.
Core Q&A
Q: Walk me through how you decide OWD for a new object. And why 'Private everything' is not automatically the right answer.
🎯 Say this first: Start from the most restrictive setting the business allows. Then open up with sharing tools. You can always add access. You can never subtract it.
A: Ask one question per object.
• Who is the MOST restricted legitimate user, and what must they see?
• Set OWD for that user type.
• Everyone else gets more access through the hierarchy, sharing rules, teams or manual shares.
• Private-by-default is the safe instinct. But every grant you add on top is a row in a share table. It has to be calculated, stored, and recalculated whenever an owner or a role changes.
• On a 50M-record object with complex sharing, that is a real operational cost: lock contention during recalculation, and slow ownership transfers.
• So Public Read Only is the correct OWD when no user type has to be blocked from reading. It wipes out an entire class of sharing rows.
• The interview-grade answer weighs the security requirement against the sharing-computation cost.
Follow-ups (scenario-based)
Q1: What actually happens in the database when you move a role with 3,000 users under a different branch of the hierarchy?
A1: Salesforce recalculates group membership, and then all the sharing derived from it, for every record whose access depends on those users. It rewrites rows in the share and group-maintenance tables, and it takes locks while it does.
• On a large org this can run for hours and block other sharing operations. It is a classic cause of UNABLE_TO_LOCK_ROW during parallel data loads.
• Three fixes. Schedule hierarchy changes off-hours.
• Use Deferred Sharing Maintenance to batch the recalculation. And keep hierarchies shallow — a hierarchy 10 or more levels deep is a performance smell.
Q2: For a 1,500-user org, how do you structure OWD and hierarchy — and what changes at 15,000 users?
A2: At 1,500 users a conventional model works.
• Private on the transactional objects. A hierarchy that mirrors the reporting structure.
• Criteria-based rules for the exceptions. The honest architect answer is what breaks at 10x.
• Hierarchy-driven sharing multiplies share rows, so at 15,000 users I would flatten roles into functional territories rather than the org chart.
• I would review whether some objects can relax to Public Read Only. And I would watch for ownership skew from integration users.
• An integration user owning millions of records is a data-skew time bomb — see Module 10.6.
• Showing that today's correct design is tomorrow's bottleneck is exactly the Sharing and Visibility Architect signal.
Q: Walk me through how you design a sharing model from scratch.
🎯 Say this first: Start private, open up on purpose, and keep permissions in permission sets — not profiles.
A: Four steps. One: classify the data.
• Who may see what, by law and by business need.
• Two: set org-wide defaults to the most restrictive honest answer. That is usually Private for anything sensitive.
• Three: open access deliberately — role hierarchy for management lines, sharing rules for stable groups, teams for per-deal collaboration, manual sharing for the exceptions.
• Four: treat object and field access as a separate axis.
• A minimal profile, plus permission sets and permission set groups per persona.
• Say the split out loud: sharing decides which records, permissions decide which objects and fields.
• Mixing those two up is the most common design smell there is.
Q: Why permission sets over profiles?
A: Profiles do not stack. Permission sets do. One minimal base profile plus stackable sets means a new persona is a new combination, not a new profile to maintain. Groups bundle the sets per role. And a muting permission set can subtract one right from a group without rebuilding it (1.2).
Q: What are the classic role-hierarchy design mistakes?
🎯 Say this first: The biggest one is copying the HR org chart.
A: The role hierarchy exists for data access, not for reporting lines.
• Copy the org chart and you get a deep, wide tree where every reorganization becomes a sharing recalculation event.
• Design the flattest hierarchy that answers one question: who must see whose records.
• Fewer levels. Roles named after data scopes, like North Sales or Partner Ops, not job titles.
• People who need no inherited access — integration users, most back-office staff — sit at the top of the tree or outside it.
Q: Can you switch off hierarchy-based access?
A: For custom objects, yes. Untick "Grant Access Using Hierarchies" on the org-wide default. Standard objects always inherit up the hierarchy, so the toggle is not offered. That switch exists for peer-sensitive data such as HR cases, where a manager should not automatically see everything below them.
Q: How do compliance requirements shape a sharing design?
🎯 Say this first: Encode the rules in the platform — classification on the fields, subtraction where the law demands it.
A: Put data classification metadata on every field that carries personal or regulated data: compliance categorization and sensitivity level.
• Audits and Shield policies can then key off it.
• Access follows least privilege from there.
• Private OWD. Field-level security hiding regulated fields from any persona with no legal basis to see them.
• A restriction rule where a hard wall is required.
• Event Monitoring watching who actually reads what.
• The goal is simple. When the auditor asks who can see national ID numbers, the answer is a query, not a meeting.