Lesson 3 of 5 15 min read
Users, security and sharing
Control who can log in, which objects and fields they can use, and which records they can see, using profiles, permission sets, roles and sharing rules.
In this lesson you will
- Explain the layers of Salesforce data security
- Use profiles and permission sets to grant object and field access
- Open up record access with org-wide defaults, the role hierarchy and sharing rules
Think in layers
Salesforce security works like a series of gates. A user sees a field on a record only if every layer allows it:
Each inside the previous: Org access contains Object access contains Field access contains Record access
| Layer | Question it answers | Controlled by |
|---|---|---|
| Org | Can this person log in, from where and when? | Users, passwords, login hours, IP ranges, multi-factor authentication |
| Object | Can they read, create, edit or delete this kind of record? | Profiles and permission sets |
| Field | Can they see or edit this field? | Field-level security in profiles and permission sets |
| Record | Which individual records can they see? | Org-wide defaults, role hierarchy, sharing rules, manual sharing |
Profiles and permission sets
Every user has exactly one profile, which sets their baseline permissions. Permission sets add more permissions on top, and a user can have many. Salesforce recommends keeping profiles minimal and granting access with permission sets (and permission set groups), because one profile per job title quickly becomes unmanageable.
Permission sets can only add access. If a user should not edit a field, make sure no profile or permission set they hold grants it.
Record access: start locked, then open up
Org-wide defaults (OWD) set the most restrictive access to records for each object:
| Org-wide default | Meaning |
|---|---|
| Private | Only the owner (and users above them in the role hierarchy) can see the record |
| Public Read Only | Everyone can see the record; only the owner can edit it |
| Public Read/Write | Everyone can see and edit the record |
| Controlled by Parent | Access follows the master record (master-detail children) |
Then you open up access where needed:
- Role hierarchy: managers can see their team's records. A sales manager sees records owned by the reps below them.
- Sharing rules: share records with a group or role based on ownership or criteria, for example "share all Education accounts with the Training team".
- Manual sharing: an owner shares one record with a colleague.
CEO (contains Sales Manager (contains Sales Rep (North), Sales Rep (South)), Training Manager (contains Course Coordinator))
Checking access
To check what someone can see, open their user record and review the profile and permission sets, or use View Summary on a permission set. When troubleshooting record visibility, the Sharing button on a record shows who has access and why.
Hands-on exercise
Set the org-wide default for your Enrollment object's parent, Course, to Private. Create a second user (a Developer Edition org includes a few user licences) with a minimal profile, and create a permission set that grants read access to Course and its Fee field. Log in as that user, or use "Log in as" from Setup, and check which records and fields they can see before and after you assign the permission set.
Knowledge check
3 questions • 70% to pass • Practice only, no certificate
Key concepts
- Access is checked in layers - org, object, field and record.
- Each user has one profile; permission sets add access and a user can have many.
- Org-wide defaults set the most restrictive record access; role hierarchy and sharing rules open it up.
- Start restrictive, because sharing can only widen access.