Salesforce Basics: Data Visibility, Sharing & Security in Salesforce

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

OWD & Role Hierarchy

💬 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 covered by a sharing rule can see it. Her teammate at the same level? Sees nothing.

Concept

Organization-Wide Defaults (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 using '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 Large Data Volume (LDV) scale.
• The architect's axiom: Set OWD to the most restrictive setting any user type requires, then open it up deliberately.

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

Data Classification: A set of compliance fields that sit on a field definition indicating who owns the data, how it may be used, and how sensitive it is. You configure them in Object Manager on each field. They do not change access by themselves, but they provide direct answers for compliance audits (e.g., "Where is our personal data?") and allow Shield policies to key off their values.

You set all of this in Setup under Sharing Settings. Each object's row holds the internal default, external default, and the "Grant Access Using Hierarchies" checkbox (grayed out for standard objects, as only custom objects can toggle this 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 predictable union.

Reach for: Set the OWD to the most restricted requirement first. Open up in order: Role hierarchy for management lines, Sharing rules for stable groups, Teams for deal-level collaboration, Manual sharing for exceptions, and Apex managed sharing last (when access depends dynamically on data).

Price: Tightening OWD later forces the platform to recalculate sharing for every record on the object, which can cause significant maintenance windows on large orgs.

Limits: Four settings — Private, Public Read Only, Public Read/Write, Controlled by Parent. External OWD is configured separately. "Grant Access Using Hierarchies" can be disabled for custom objects only.

Mirror — Public Read/Write: Nothing to compute or debug, but provides no way to keep specific data private later.

Later: Every sharing rule, team, and Apex share sits on top of this. It is the hardest architectural decision to reverse.

At volume: Moving a role with thousands of users rewrites share rows for every record their access touches. Plan it like a data 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 below OWD.

A: Ask one fundamental question per object:

• Who is the MOST restricted legitimate user, and what must they see?
• Set OWD for that specific user type.
• Everyone else receives wider access through the role hierarchy, sharing rules, teams, or manual shares.
• Private-by-default is a safe instinct, but every grant added on top creates rows in share tables that must be calculated, stored, and updated on owner/role changes.
• On a 50M-record object, excessive sharing rules carry performance overhead: lock contention during recalculations and slower ownership transfers.
• Therefore, Public Read Only is the correct OWD when no user type needs to be blocked from viewing data, eliminating an entire class of background share rows.
• Architect Note: The ideal answer weighs security requirements directly against sharing calculation overhead.

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 derived sharing for every record whose access depends on those users, rewriting rows in share and group-maintenance tables while placing database locks.

• In large orgs, this operation can take hours and lock sharing tables, leading to UNABLE_TO_LOCK_ROW errors during concurrent data loads.
• Fix 1: Schedule role hierarchy shifts during off-peak hours.
• Fix 2: Use Deferred Sharing Maintenance to batch background recalculations.
• Fix 3: Keep hierarchies flat — a tree 10+ levels deep is a known performance anti-pattern.

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 standard model works well: Private on core transactional objects, an org-chart-aligned role hierarchy, and criteria-based rules for exceptions.

• At 15,000 users, hierarchy-driven sharing multiplies share rows drastically. Flatten roles into functional territories rather than strict reporting lines.
• Review whether non-sensitive objects can be opened up to Public Read Only to eliminate share rows.
• Monitor for ownership skew (e.g., an integration user owning millions of records), which creates major visibility and recalculation bottlenecks.

Q: Walk me through how you design a sharing model from scratch.

🎯 Say this first: Start private, open up deliberately, and manage object permissions in permission sets — not profiles.

A: Follow a four-step framework:

• Step 1: Classify the Data — Determine who can see what based on regulatory requirements and business operational needs.
• Step 2: Establish OWD — Set org-wide defaults to the most restrictive legitimate baseline (typically Private for sensitive data).
• Step 3: Open Access Deliberately — Use the role hierarchy for management escalation, sharing rules for functional teams, teams for deal collaboration, and manual shares for one-off exceptions.
• Step 4: Decouple Object/Field Permissions — Use minimal base profiles paired with stackable Permission Sets and Permission Set Groups per persona.
• Golden Rule: Sharing determines WHICH RECORDS a user sees; Permission Sets determine WHICH OBJECTS AND FIELDS they can interact with.

Q: Why permission sets over profiles?

A: Profiles are monolithic and do not stack, whereas Permission Sets are modular and additive. Pairing a minimal base profile with stackable permission sets allows new personas to be created via permission combinations without proliferating profile maintenance. Muting Permission Sets can also subtract specific rights from a Permission Set Group without needing to rebuild it.

Q: What are the classic role-hierarchy design mistakes?

🎯 Say this first: The biggest mistake is copying the HR org chart.

A: The role hierarchy exists strictly for data visibility, not reporting lines. Mirroring the HR chart creates deep hierarchy trees where every departmental reorganization triggers major sharing recalculation jobs. Design the flattest hierarchy possible, naming roles after data scopes (e.g., North Sales or Partner Ops) rather than individual job titles. Users who require no inherited access (e.g., integration accounts) should sit at the top of the tree or outside it.

Q: Can you switch off hierarchy-based access?

A: Yes, for custom objects by unchecking "Grant Access Using Hierarchies" in OWD settings. Standard objects always inherit access upward. Disabling hierarchy access is useful for peer-sensitive custom objects (like internal HR cases) where managers should not automatically inherit visibility into records owned by subordinates.

Q: How do compliance requirements shape a sharing design?

🎯 Say this first: Encode rules in the platform — classification on fields, restriction rules where the law demands hard barriers.

A: Add Data Classification metadata (Compliance Categorization & Sensitivity Level) to every field storing regulated or personal data so that audits and Shield policies can track it. Apply least privilege using Private OWD, restrict field-level security for unauthorized personas, enforce Restriction Rules for absolute compliance boundaries, and use Event Monitoring to audit real-time data access.