Feynman Technique: Salesforce Security and Sharing Explained at 4 Levels

What You’ll Learn: A complete breakdown of Salesforce security and record-level sharing using the Feynman Technique. We explain it to a 5-year-old, then a tech enthusiast, then a domain expert, then distill it to one essential sentence. By the end, you’ll understand not just how Salesforce security works, but why.

Level 1: For a Five-Year-Old
Level 2: For a Curious Tech Enthusiast
Level 3: For a Domain Expert
Level 4: One-Sentence Distillation
The Feynman Test
Why These Four Levels Matter Together

—

Level 1 For a Five-Year-Old: The Toy Box Analogy

Imagine you have a big toy box. Inside are toys (your data). Some toys are YOUR toys that nobody else can touch. Some toys are for sharing with your friends. And some toys? Well, your grown-up gets to decide who can play with them.

In Salesforce, it works like this:

First Gate: Can You Even Come Into the Playroom?

That’s your login. Your name and password open the door. If you don’t have a password, you can’t get in at all. This is org access—the very first security check.

Second Gate: Which Toys Are You Allowed to Touch?

Some kids get toy trucks. Some get toy dolls. Your mom says “you can play with trucks, but never the breakable tea set.” That’s like roles and profiles. They say “you get to see Accounts, but not Secret Deals.” This is object-level access.

Third Gate: Which Exact Toys Can You Play With?

Even if you get to play with trucks, maybe you can’t play with Tommy’s favorite red truck. It’s his truck. You can only play with trucks that are yours or that he shared with you. That’s sharing rules. They say “you can see this Account, but not that one.” This is record-level sharing.

The Magic Rule: The Toy Box Works From The Outside In

Mom sets a rule: “Nobody touches anything unless I say so” (Private). Then she says “okay, your brother can touch this toy” (Share it). She doesn’t say “everything is open, except this one toy” because that’s too hard to keep track of.

That’s the key insight: start closed, open up.

That’s it: Four gates. Closed by default. You ask for access. Access gets granted. Simple.

Level 2 For a Curious Tech Enthusiast: The Mechanism

Salesforce security is a four-layer permission model that works independently. Here’s how the mechanism actually functions:

The Architecture: Four Independent Layers

User Login (Org Access) ↓ Object Permissions (Can I see “Accounts” at all?) ↓ Field-Level Security (Can I see the “Revenue” field on an Account?) ↓ Record-Level Sharing (Can I see THIS specific Account record?)

Each layer is independent. You can fail at any level and lose access completely. All four must grant access for you to see data. This is called defense in depth.

How Each Layer Works

Layer 1: Org Access

Your user record has a Profile assigned. That Profile determines Login Hours, IP Ranges, Session Settings. If it’s 3 AM and your profile says “login only 9-5,” the system checks the timestamp before even loading the org. You never reach Layer 2.

Layer 2: Object Access

Your Profile (or a Permission Set stacked on top) determines CRUD (Create, Read, Update, Delete) for each object. This is a whitelist model: if it’s not explicitly granted, it’s denied. You can’t see the Opportunity object if your Profile doesn’t have “Read” permission.

Layer 3: Field-Level Security

Even if you can read Opportunities, specific fields can be hidden. An Account’s “Margin” field might be invisible to Sales Reps but visible to Finance. This is second-level filtering on the object you’re already allowed to see.

Layer 4: Record-Level Sharing (The Complexity)

This is where most admins get confused because it’s declarative and rule-based, not baked into the data model.

Org-Wide Defaults (OWD) set the baseline for each object:

Private — You see only records you own or are explicitly shared
Public Read Only — Everyone sees all records, but only owners can edit
Public Read/Write — Everyone sees all records and can edit anything
Controlled by Parent — Visibility inherits from the parent record

Then exceptions layer on top:

How Sharing Actually Works

Role Hierarchy: Managers automatically see all records owned by their subordinates (and everyone below them in the chain). This is upward visibility only. You can’t see your manager’s records unless they’re shared with you.

Sharing Rules: Automated sharing based on record criteria. Example: “If Account.Region = ‘EMEA’, share with all users in the EMEA_Region_Group.” These are field-value driven and apply to matching records at creation and thereafter.

Manual Sharing: Ad-hoc record access granted by the owner or an admin. “I’m sharing this specific Account with you.”

Apex Managed Sharing: Programmatic record access via Apex code. You build custom logic: “When an Opportunity reaches ‘Closed/Won,’ automatically share the related Account with Finance.”

Why It’s Designed This Way

The reason for four independent layers is defense in depth. If someone accidentally grants too much access at Layer 2 (object permissions), Layers 3 and 4 (field-level and record-level) still protect sensitive data. It’s redundant by design.

The Critical Gotcha: “Controlled by Parent”

This is where the mechanism breaks down with multi-level hierarchies:

Account (Private, Owner: Sarah) ↓ Controlled by Parent Opportunity (Controlled by Parent, Owner: Sarah) ↓ Controlled by Parent Order (Controlled by Parent, Owner: Michael)

Question: Can Tom (peer of Sarah) see the Order?

Answer: No.

Tom can’t see the Account (Sarah owns it, it’s Private).
Opportunity is Controlled by Parent (Account), so Tom can’t see it.
Order is Controlled by Parent (Opportunity), so Tom can’t see it.

Visibility flows downward, not upward. Michael’s ownership doesn’t matter. If the grandparent is invisible, the entire chain becomes invisible.

This is why external users (portal users, community members) break with “Controlled by Parent” — the parent record (often owned by internal staff) is invisible to them, cascading invisibility to child records they should access.

Permission Sets vs. Profiles: The Modern Pattern

Profiles are foundational—every user must have exactly one. They define:

Org access controls (Login Hours, IP Ranges)
UI configuration (Page Layouts, App Menu, Tabs)
System Permissions (“Modify All Data,” “View All”)

Permission Sets are additive. A user can have multiple. They add:

Additional object/field permissions
Custom permissions
Apex class/Visualforce page access

Permission Set Groups bundle multiple Permission Sets together for assignment. This is the modern pattern—assign a base Profile for UX/org controls, then stack Permission Set Groups for capability permissions.

Level 3 For a Domain Expert: Full Technical Breakdown

Architectural Constraints & Boundary Conditions

The record-level sharing model in Salesforce operates on three core principles:

1. Declarative Rule Execution With Eventual Consistency

Sharing rule evaluation is asynchronous. When a record’s field values change, Salesforce evaluates all Sharing Rules against that record in batch jobs (typically within 4 hours, but not synchronously). This creates a consistency window where sharing state may not reflect the latest field values. Manual Sharing and Role Hierarchy are synchronous; Sharing Rules and Apex Managed Sharing are not.

2. Upward Role Hierarchy Visibility Is Immutable

Role Hierarchy grants Read/Write visibility upward only. This cannot be revoked by OWD or Sharing Rules—Role Hierarchy access is always granted if the user is higher in the hierarchy. This means you cannot restrict a manager from seeing their subordinate’s records using OWD alone; you’d need to deprovision them from the Role Hierarchy or use Apex Managed Sharing to revoke specific record access (which operates as a deny rule overlay).

3. Cascading Visibility in Parent-Child Relationships

When OWD for a child object is set to “Controlled by Parent,” the child record’s visibility is determined at query time by evaluating the parent record’s sharing state. This creates a transitive dependency: if Opportunity OWD is “Controlled by Parent” (Account), and Order OWD is “Controlled by Parent” (Opportunity), a user must have read access to all three records to see the Order. Multi-level cascading (grandparent > parent > child > grandchild) is a known anti-pattern because visibility compounding creates unintuitive access models.

Known Limitations & Failure Modes

OWD Constraint: OWD is object-level, not record-type or record-attribute level. You cannot set different OWD settings for different subsets of the same object. If you need granular control (e.g., “Opportunities under enterprise accounts are Private, but SMB opportunities are Public Read Only”), you must use Sharing Rules, not OWD variation.

Sharing Rule Constraints: Sharing Rules cannot use related object fields in their criteria. A Sharing Rule cannot say “Share Opportunities where Account.Region = ‘EMEA’.” It can only use fields on the Opportunity itself or roll-up values. This forces admins to denormalize data (add a Region__c field to Opportunity) or use Apex Managed Sharing for complex logic.

Rule Limits: Sharing Rules have a 5,000-rule limit per organization, though practical limits are much lower (500-1,000 rules before performance degrades).

No Negation: Sharing Rules don’t support negation. You cannot create a Sharing Rule that says “Share with everyone except Group X.” This is a common source of workaround complexity.

Role Hierarchy Constraint

The Role Hierarchy is single-parent only. A user cannot have two managers. This forces org structures into rigid hierarchies that don’t reflect matrix reporting or dotted-line relationships. Admins often work around this with custom Permission Sets or Apex Managed Sharing.

Apex Managed Sharing Constraints

Apex Managed Sharing requires explicit deletion. If you add an Apex-managed share programmatically, you must explicitly remove it; it won’t cascade delete if the parent record is deleted. This creates orphaned shares that consume the Salesforce sharing limits (users are capped at approximately 3 million total shared records per org).

Apex Managed Sharing is read-only from SOQL. You cannot query who has access to a record; you can only query the share records themselves. This makes auditing sharing state complex.

External User (Portal/Community) Gotchas

Portal Users cannot have Portal User Admins as managers in the Role Hierarchy (portal hierarchies are separate). Role Hierarchy visibility does not flow between internal and portal hierarchies.

“Controlled by Parent” with portal users: Portal users often own the parent record (e.g., Contact-based portal user owns an Account) but cannot see child records because the child’s OWD is “Controlled by Parent,” and the portal user doesn’t have read access to the parent through the org-wide hierarchy. This requires explicit Sharing Rules for each portal-user-facing child object.

Guest Users (Community Cloud) don’t participate in sharing rules or manual sharing. Their visibility is determined entirely by object permissions on the Community settings, not by sharing.

Performance & Scalability Implications

Query Performance: Record-level sharing is evaluated at query time, not at the data-model level. When you query Accounts with a SOQL statement, Salesforce filters the results based on the user’s sharing state after the query executes. This means large datasets with complex Sharing Rules can cause significant query slowdown (10-50x slower than unfiltered queries on large tables).

Sharing Limit: Each user-record pair counts toward the sharing limit. With 1,000 users and 100,000 records with complex Sharing Rules, you can hit the 30 million shared record limit for the org. Once you approach the limit, Salesforce cannot evaluate sharing changes, and the org enters a sharing recalculation queue, which blocks metadata changes.

Advanced Patterns & Workarounds

Pattern 1: Territory Management as Sharing Alternative — For complex geographic or account-based access models, Territory Management (available in Sales Cloud) provides an alternative to Sharing Rules. Territories allow many-to-many user-record relationships and support complex hierarchies. However, Territories are Sales Cloud only and cannot be used for other objects.

Pattern 2: Custom Object-Level Filtering — For objects where you need record-type-based or complex attribute-based access, use Apex to dynamically filter query results in custom controllers or Visualforce pages. This bypasses the sharing mechanism entirely and moves access control logic into application code. Pros: Flexible. Cons: Not auditable, bypasses standard reporting, breaks with APIs/Flows.

Pattern 3: Apex Managed Sharing for Dynamic Access — For time-based or status-dependent access (e.g., “Share with Finance only after Opportunity closes”), use Apex Managed Sharing triggered by Flows or Process Builder.

Pattern 4: Cascading Sharing via Flow/Automation — For parent-child sharing that doesn’t use “Controlled by Parent,” use Flows to manually share child records when parents are shared. This gives you granular control over what cascades and what doesn’t, at the cost of automation complexity.

Audit & Compliance Implications

Sharing Auditing: Salesforce provides limited native auditing. View Setup Audit Trail shows Sharing Rule changes, but not who accessed what. Apex Managed Sharing leaves an audit trail only if you query the share objects. Field Audit Trail does not track sharing state changes.

For compliance (HIPAA, SOC 2, GDPR), admins often implement custom audit logging: trigger-based logging of share creations/deletions, or third-party audit apps.

Known Edge Cases & Undocumented Behavior

Sharing Recalculation Delays: When you modify a Sharing Rule, Salesforce queues a recalculation job. This can take 4-24 hours for large orgs. In the interim, users may see stale sharing state. Salesforce does not provide a manual “recalculate now” button.

Deactivated Users and Sharing: When a user is deactivated, their Manual Shares are not automatically deleted. This means sharing records may reference a non-existent user, creating orphaned shares.

Record Owner Change and Sharing: If you change a record’s owner, the new owner gains access. However, Sharing Rules re-evaluate based on the new owner’s attributes. If the old owner was in Group A and the new owner is in Group B, the Sharing Rule for Group A no longer applies to this record (unless there’s another matching rule).

Sharing Portal vs. Sharing With Portal Users: Admins confuse “sharing a record with a portal user” (requires manual sharing or Sharing Rules) with “portal user access to the object” (determined by Community settings). A portal user might have “read” on the Account object but can only see 3 of 10,000 Accounts due to sharing rules.

Level 4 One-Sentence Distillation

Salesforce security controls which users can see which records by checking four independent layers (login, object type, field, and record-level sharing via rules/hierarchy/manual access) at query time, defaulting to “deny” and requiring explicit grant at every layer to view data.

Why This Sentence Holds Up

Against oversimplification: It names all four layers, not just “permissions” or “sharing.”

Against false dichotomy: It identifies the mechanism (“at query time,” “defaulting to deny”) not just the outcome (“controls access”).

Against missing the gotcha: It specifies “independent layers”—meaning you can fail at any one and lose access, forcing redundancy.

Against the “Controlled by Parent” trap: It doesn’t say “record sharing is simple”—it implies evaluation at query time, which is where cascading visibility happens.

Against the permission-vs-sharing confusion: It separates “record-level sharing” (OWD, rules, hierarchy, manual) from object/field layers, clarifying that sharing is the fourth layer, not the whole model.

Against the external user gotcha: The “require explicit grant at every layer” implies that if you’re not explicitly granted at Layer 1 (login) or Layer 2 (object) or Layer 3 (field), you fail, which is why portal users with “Controlled by Parent” invisible parents get no visibility.

The Feynman Test: Can You Explain It Without Jargon?

Let me verify the core sentence without using technical terminology:

“Access checking happens in four steps (login, data type, individual fields, specific records). Everything starts as ‘no’ unless you pass all four checks. When looking at a specific record, the system checks your permission for that exact item at the moment you try to view it.”

Does this hold? Yes. Same structure, no technical terms. If it didn’t, the sentence would rely on jargon to hide incomplete understanding. That’s the Feynman test.

Why These Four Levels Matter Together

Level 1 teaches intuition (gates, defaults, cascading). You understand the philosophy, not the mechanics.

Level 2 teaches mechanism (how the layers interact, why “Controlled by Parent” breaks, Permission Sets vs. Profiles). You understand how it works.

Level 3 teaches boundaries (what breaks, what you can’t do, where it fails). You understand the edges and why they matter.

Level 4 teaches essence (the irreducible core that makes everything else follow). You understand the irreducible kernel.

If you can move fluidly between all four, you understand not just Salesforce security, but the problem security is solving (controlling access at scale without chaos) and the tradeoffs it makes (performance, auditability, flexibility).

That’s when you stop asking “how do I set up this sharing rule?” and start asking “what access model do we actually need, and what’s the best way to implement it?”

About the Feynman Technique: Named after physicist Richard Feynman, this technique works by explaining concepts at progressively deeper levels. If you can explain something simply, then with mechanism, then with full rigor, and finally distill it to one sentence—you truly understand it. This approach reveals gaps in understanding that jargon often hides.