The single most important distinction

OWD sets the baseline; everything to its right can only raise access above that floor (sharing never removes access OWD already grants — except with restriction rules, see Advanced Topics).

1. Organization-Wide Defaults (OWD)

• The baseline record access level per object — answers "if a user doesn't own the record and has no special sharing, can they see it?"
• Everything else in the sharing model (roles, rules, manual/Apex sharing) can only raise access above this floor.

2. Role Hierarchy

• Grants users in higher roles access to records owned by users below them in the hierarchy.
• Purely a record-access concept — does not grant object or field permissions.
• Does not need to mirror the actual org chart — it's a data-access structure.

3. Sharing Rules

Record vs Permission access — the exam's favorite split

Permission Set Groups & Muting Permission Sets

• Permission Set Group — bundles multiple permission sets into one assignable unit (easier management at scale, by job function).
• Muting Permission Set — lets admins reduce specific permissions inside a group without rebuilding it.

Apex class access is part of the permission model

An authenticated or guest user can call an @AuraEnabled Apex method only if their Profile or an assigned Permission Set grants access to that Apex class. If a component can't call Apex, check profile access, permission set access, class visibility, and the method annotation — not just sharing.

Sharing keywords — record-level only

• In API 67.0+, Apex runs in user mode by default, and record sharing is enforced by default unless you declare without sharing.

stripInaccessible()

Sanitizes records you already have — strips fields the current user cannot access, for graceful cleanup instead of a hard failure.

PD1 shortcut

• Need record sharing respected? → with sharing
• Need explicit bypass of sharing? → without sharing
• Need object/field permissions enforced in a query? → WITH USER_MODE
• Need elevated access, explicitly? → WITH SYSTEM_MODE
• Need to sanitize records already in hand? → stripInaccessible()
• Need the safest standard UI record access? → Lightning Data Service (handles sharing, CRUD, and FLS automatically)

Apex Managed Sharing High-yield

• Any custom object with OWD below Public Read/Write auto-generates a share table: ObjectName__Share (standard objects: AccountShare, OpportunityShare, etc.)
• Key fields: ParentId (record shared), UserOrGroupId (recipient), AccessLevel (Read / Edit — never settable to All, that's system-reserved for the owner), RowCause (why it was shared).
• RowCause values: Manual, Rule, Owner, or a custom Apex Sharing Reason (defined under Setup → Sharing Reasons).

Custom_Object__Share cos = new Custom_Object__Share();
cos.ParentId = recordId;
cos.UserOrGroupId = userOrGroupId;
cos.AccessLevel = 'Edit';
cos.RowCause = Schema.Custom_Object__Share.RowCause.My_Apex_Reason__c;
insert cos;

CRUD/FLS: Describe methods vs modern enforcement

The old manual pattern is still valid syntax and still testable — it's verbose, not deprecated.

if (!Schema.sObjectType.Account.isAccessible())  { /* block read   */ }
if (!Schema.sObjectType.Account.isCreateable())  { /* block insert */ }
if (!Schema.sObjectType.Account.isUpdateable())  { /* block update */ }
if (!Schema.sObjectType.Account.isDeletable())   { /* block delete */ }
if (!Schema.sObjectType.Account.fields.Name.isAccessible())  { /* field read  */ }
if (!Schema.sObjectType.Account.fields.Name.isUpdateable()) { /* field write */ }

Delegated Administration

• Lets non-admin users manage specific User records (reset passwords, freeze/unfreeze, create/edit users in specified roles) and specific custom objects (fields, layouts, record types, validation rules).
• Standard objects cannot be delegated. Delegates can never grant "Modify All Data," "View All Data," or the System Administrator profile.

Field History Tracking vs Scoping Rules vs Restriction Rules Frequently confused

Final trap round-up

• Profile vs Role — Profile = object/field/system permissions + login constraints. Role = record visibility via hierarchy only. Frequently conflated.
• Master-Detail child of a standard parent forces OWD to "Controlled by Parent" — cannot be changed; sharing follows the parent entirely.
• without sharing bypasses record-level sharing only. It does NOT bypass CRUD/FLS — object and field permissions still apply regardless of the sharing keyword. This is one of the most common PD1 traps.
• A muting permission set can only remove permissions granted by permission sets within the same group — never permissions coming from the profile itself.

Scenario → best answer

Ultra-short memory sheet

Final answer pattern

• Problem about seeing records? → sharing / roles / OWD
• Problem about doing things? → profile / permission set
• Problem about Apex record visibility? → with sharing
• Problem about Apex field/object access? → WITH USER_MODE or stripInaccessible()
• Problem about UI record access? → Lightning Data Service