Security and Access
The access stack
Salesforce access is decided in layers: object permissions (from profiles, permission sets, and permission set groups), then field-level security, then record access. Record access is the union of org-wide defaults, the role hierarchy (only when Grant Access Using Hierarchies is enabled on that object), sharing rules, manual sharing, teams, and Apex managed sharing. Sharing is additive - a sharing rule can widen access but can never make a record more private than the OWD. Restriction rules and scoping rules are the exceptions: they filter which of the records a user already has access to is actually visible.
Traps candidates fall for
- Permission sets only add; the single subtractive mechanism is a muting permission set inside a permission set group.
- FLS hides fields, not records. View All Data bypasses sharing but never FLS; Modify All Data bypasses sharing for edit and delete.
- The role hierarchy follows the record owner's role: a manager sees subordinate-owned records, not the reverse, and never across separate branches.
- Manual sharing and sharing rules require OWD of Private or Public Read Only; Public Read/Write already grants edit and cannot be narrowed.
- Changing a role or an OWD queues a sharing recalculation, so access is not instant.
Worked example
Case OWD = Private with hierarchy sharing disabled. Reps in the same branch must edit each other's cases. Instead of opening the OWD, create an owner-based sharing rule that shares cases owned by a public group's roles with that same group at Read/Write. Rule of thumb: 'same team' → sharing rule on a group or role; 'these named people, this record' → manual sharing or a case team; 'everyone, always' → reconsider the OWD instead.