Configuration and Setup · Topic 3 of 4
Security Controls and the Sharing Model
Salesforce security: identity verification, Setup Audit Trail, login hours and session settings, plus org-wide defaults, roles, sharing rules and teams.
- 4 min
- Includes a diagram
- Security layers: org access, object permissions, record access, field-level security.
- Setup Audit Trail tracks configuration changes; login hours and IP ranges live on profiles.
- OWD sets the baseline; role hierarchy, sharing rules, teams and manual sharing open access.
What it is
Salesforce security works in layers. Organization security controls decide who can log in and how sessions behave. The sharing model decides which records each user can see and edit, once they are allowed into the org and have permission to the object.
How it works
Organization security controls
| Control | Purpose |
|---|---|
| Identity verification and MFA | Confirms users' identity at login; MFA is required for UI logins |
| Setup Audit Trail | Records configuration changes made in Setup: who changed what and when. The page shows the 20 most recent changes; the download covers the last 180 days |
| Login hours and login IP ranges | Set on profiles to restrict when and from where users can log in |
| Network access (trusted IP ranges) | Org-wide trusted ranges where users aren't asked to verify identity |
| Session settings | Timeout value, locking sessions to the IP address, and other session security |
| Health Check | Compares your security settings with a baseline |
| Agent access | A permission set's Agent Access settings list the agents that users with that permission set can use |
The sharing model
| Layer | What it does |
|---|---|
| Org-wide defaults (OWD) | The baseline access to other users' records per object: Private, Public Read Only, Public Read/Write, or Controlled by Parent. Some objects have other levels, such as Public Read/Write/Transfer for leads and cases and Public Full Access for campaigns |
| Role hierarchy | Users higher in the hierarchy can access records owned by users below them (when Grant Access Using Hierarchies applies) |
| Sharing rules | Open access to groups of users, based on record owner (owner-based) or field values (criteria-based) |
| Teams | Account, opportunity and case teams share individual records with team members |
| Manual sharing | Owners share a single record with specific users or groups |
| Public groups | Groups of users, roles, roles and subordinates, and other groups, used as targets in sharing rules and folders |
The rule of thumb: set the OWD to the most restrictive level any user needs, then open access with the role hierarchy, sharing rules, teams and manual sharing. Sharing can open access but can't restrict it below the OWD.
Report and dashboard folders are shared separately, with Viewer, Editor or Manager access.
A worked example: account records should be private, but every sales manager must see accounts owned by their team, and all support agents need read access to accounts in the "Customer" type. Set the account OWD to Private, build the role hierarchy so managers sit above their reps, and add a criteria-based sharing rule giving the support group Read Only to accounts with Type = Customer.
If a question says some users must see fewer records than everyone else, the OWD must be restrictive. Sharing rules can only add access.
How the exam asks about this
- "Who changed a validation rule last week?" Setup Audit Trail.
- "Reps must see only their own opportunities, managers see their team's." Private OWD plus the role hierarchy.
- "Give a group read access to records that meet a field condition." A criteria-based sharing rule.
What to remember for the exam
- Security layers: org access, object permissions, record access, field-level security.
- Setup Audit Trail tracks configuration changes; login hours and IP ranges live on profiles.
- OWD sets the baseline; role hierarchy, sharing rules, teams and manual sharing open access.
- Owner-based and criteria-based sharing rules; public groups as targets.
- Sharing never restricts access below the OWD.
Giving a user "View All" or "Modify All" on an object bypasses the sharing model for that object. Use them sparingly.
Common mistakes
Trying to restrict access with a sharing rule. Sharing rules only grant access.
Confusing object permissions with record access. A user needs both.
Forgetting that report folders are shared separately. Reports also respect record access.
Check yourself
What is the first step in designing record access?
Set the org-wide default for each object to the most restrictive level any user needs.
Which feature records who changed configuration in Setup?
Setup Audit Trail.
What is the difference between owner-based and criteria-based sharing rules?
Owner-based rules share records owned by certain users; criteria-based rules share records that meet field conditions.
Topic 3 of 4 in Configuration and Setup
Test yourself on Configuration and Setup
The full Salesforce Platform Administrator question bank has 650 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Salesforce. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.