Profiles, roles & sharing

Security in Salesforce answers two different questions, and keeping them separate is the secret to understanding the whole model. The first is what can a user do — which objects and fields they can create, read, edit, or delete, and which apps and features they can use. The second is which specific records can a user see. Different tools answer each.

Profiles and permission sets answer the first question. A profile grants baseline object and field permissions plus app and system settings, and every user has exactly one. Permission sets (and permission set groups) grant additional access on top, which is why modern best practice is to keep profiles minimal and layer capabilities with permission sets — it scales far better than cloning profiles for every variation.

Record visibility is answered by a layered model. Org-wide defaults (OWD) set the baseline: Private, Public Read Only, or Public Read/Write per object. You start restrictive and then open access up. The role hierarchy lets people higher up see records owned by those below them. Sharing rules grant access to groups or roles based on record criteria or ownership. Manual sharing and team-based sharing handle one-off cases. The principle is "restrict with OWD, then grant back" — never the reverse.

Access to a record = the most permissive of:
  Org-Wide Default (baseline)
  + Role hierarchy (managers see subordinates' records)
  + Sharing rules (criteria/owner based)
  + Manual & team sharing
  + Ownership (owners always have access)

A practical exercise: set Opportunity OWD to Private, create two roles in a hierarchy, and a sharing rule that shares one team's opportunities with another. Log in as different users to confirm who sees what. This layered model is heavily tested on the Administrator exam and is the source of most real-world access questions. With foundations, data, automation, analytics, and security covered, you are ready for the certification section.