Salesforce Sharing and Visibility Architect Mock Exam: Key Concepts by Domain

FLS Beats Page Layouts: Field-Level Security controls visibility independently of layouts: grant Read on fields for reporting without ever putting them on a layout. Hiding a button or collapsing a section is never a security control.

Sharing Can't Beat CRUD: A sharing rule extends record visibility but never grants more than the profile's object permissions allow; a user with no Read on the object sees nothing no matter what is shared. Object CRUD (like removing Delete on Opportunity) is the supported way to block an action, not UI tricks.

Profiles vs. Permission Sets: Login Hours, login IP ranges, and page layout assignment are profile-only; permission sets additively grant object permissions, FLS, and system permissions like Modify All Data, the bypass-everything permission an MDM integration user needs.

Shield Platform Encryption: Encrypts long text areas at rest (classic "Text (Encrypted)" fields are short-text only with heavy limits), but encrypted fields disappear from criteria-based sharing rule filters and most declarative filtering, a favorite exam trap.

Enforcing Security in Apex: "With sharing" makes Apex respect the running user's record access (and can break automation that must always succeed); standard Visualforce controllers auto-enforce CRUD and FLS, custom controllers must check isAccessible() or use {!$ObjectType.Lead.accessible} expressions.

Secure Code & Credentials: Named Credentials, protected custom settings, and protected custom metadata keep secrets out of subscriber orgs and Apex code. Concatenated user input in dynamic SOQL means SOQL injection; escape="false" on outputText means cross-site scripting.

OWD Sets the Floor: Start with the most restrictive OWD and open up with sharing. Public Read Only surfaces duplicates while keeping edits owner-only; Read/Write/Transfer adds reassignment; the manual Sharing button only appears when the OWD is Private or Public Read Only.

Role Hierarchy & Its Off Switch: Access flows up the hierarchy, never sideways, so everyone above a shared-with user also gains access. Unchecking "Grant Access Using Hierarchies" on a custom object (think an employee NPS object) is the only way to keep managers out.

Sharing Rules, Groups & Teams: Sharing rules target public groups, roles, roles and subordinates, or territories, never a specific user in a lookup field. Account, Opportunity, and Case Teams grant per-record access with per-object access levels; editing a member's access on one Account changes that record only.

Master-Detail Means Controlled by Parent: Detail records inherit the parent's sharing and unlock roll-up summaries: anyone who sees the Invoice sees its Line Items. A junction object requires access to BOTH masters, and a child that needs its own sharing model needs a lookup instead.

Implicit Sharing: Access to an Opportunity or Case grants implicit Read-only access to the parent Account (and its Contacts when Controlled by Parent). It explains most "why can this user suddenly see the Account" scenarios.

Apex Managed Sharing: __Share records accept only Read or Edit (All and None throw DML exceptions). RowCause Manual dies when the owner changes; a custom Apex Sharing Reason survives. Share to a role's system sharing group or a public group, and use the SOAP/REST API when an external system drives access.

External User Access: Sharing Sets need an OWD stricter than Public Read/Write plus a lookup path to the user's Account or Contact. Partner Super User extends visibility to records of same-account users at the same role or below, the go-to for "lead agents see other agents' deals".

Folder & List View Sharing Targets: Report and dashboard folders share to public groups and roles, never profiles. List views share to public groups and roles and subordinates, and the "Manage Public List Views" permission silently overrides every list view restriction.

Viewer vs. Manager vs. Export: Viewer access on a folder is read-and-clone only. Exporting data needs the "Export Reports" profile permission, and building a peers-comparison dashboard under Private sharing takes both "Manage Dashboards" and "View All Data".

File Visibility Follows the Record: A file posted to a record's Chatter feed is visible to whoever can see the record (plus View All Data users). Deleting a public link revokes anonymous access instantly without deleting the file.

Community Visibility Toggles: Customer User Visibility controls whether external users can see and search each other; broadening customer Chatter visibility beyond their own account takes the View All setting for Chatter posts.

Data Skew: Ownership skew: keep a mega-owner (integration user, queue-like user) out of the role hierarchy to avoid cascading recalculation. Parent skew (12,000 contacts under one account) produces UNABLE_TO_LOCK_ROW errors; redistribute children across an account hierarchy.

Big Realignment Toolkit: Deferred Sharing Recalculation, Parallel Sharing Rule recalculation, and Granular Locking are the trio for large role or territory reorganizations; concurrent updates to children of the same parent are the classic source of lock contention.

License Limits Shape the Design: Only Partner Community licenses open Opportunities and Leads to external users; partner account role hierarchies cap at three levels (Executive, Manager, User); Territory Model State (Planning, Active, Archived) lets a new territory model be staged within org limits.

Test the Model, Don't Assume It: "Login As" a sample user in each role and profile is the best-practice validation, and the record Sharing button explains exactly why a user has access. In Apex tests, runAs() enforces record sharing but never CRUD or FLS.