- Security is a smaller part of the Platform App Builder certification (10%) than it is of the Administrator certification (13%)
- The nature of the role hierarchy is that record access “rolls up” to managers
- Permission sets are like a “second profile” that opens up access
- Note: need to enable “Enhanced Profile User Interface” in every new org!
- Access via: Setup > Users > User Management Settings
- Access via: Setup > Users > Profiles
- Best practice to create a new profile is to clone an existing template and modify from there
- Best practice is that System Administrators use the default System Administrator profile
- “Custom App Settings” are available under the profile
- Can make visible any of the various apps, can also change the default app that appears when Salesforce is opened up
- Can view Password Policies, which are set on a per-Profile level
Creating Custom Profiles
- Best practice is that users are only assigned to Custom profiles because there are a lot of limitations with Standard profiles - they cannot be customized
- Exception is the System Administrator profile, which all System Admins should use
- Object-Level CRUD rights are set per-Object, per-Profile
- Field-Level security (read/edit access) to various fields also set per-Object, per-Profile
- Roles is where Salesforce mimics traditional org charts that companies use
- Access via: Setup > Users > Roles
- Note different views are available: tree view, sorted list view, list view (indented)
Creating Roles and Assigning Users to Them
- Role hierarchies open up record access vertically. People on the same role “level” (directors, for example) cannot necessarily see one another’s records.
Profiles vs. Roles
- Profiles: dictate what you can do at an object level (CRUD rights).
- Roles: dictate what records users have access to.
Introducing Permission Sets
- Permission Sets are like secondary Profiles - users can be assigned to multiple Permission Sets.
- Permission sets were created to solve a problem that some older Salesforce orgs were experiencing where the only way to create a slightly different version of a Profile was to create an entirely new profile (Ex: System Admin, Junior System Admin, Junior System Admin with Full Account Access, etc) - resulted in a proliferation of profiles that was confusing.
- An example Permission Set might be called “Manage Chatter Groups” and grant the permission to manage chatter groups.
- Idea with Salesforce security is to start at base with most restrictive security on the Profile, then open up access using permission sets.
Creating Permission Sets
- By default, Permission Sets don’t have any Permissions options selected.
Organization Wide Defaults
- The image linked here shows a high-level view of how Salesforce security and record access works
- Org-Wide Defaults: base level at which you set all access to records. Each object can be set as:
- Public Read/Write,
- Public Read-Only
- Role Hierarchy: opens up access vertically (managers can see IC’s records)
- Sharing Rules: opens up access laterally
- Manual Sharing: flexible
- Remember that Org Wide Defaults are set on the settings page called Sharing Settings
- On each new org, need to enable the ability to log in as another user. Do this via: Setup > Quick Find > “login” > Login Access Policies > Checkbox with setting: Administrators Can Log in as Any User
- Upon updating sharing settings for an object, Salesforce recalculates permissions for the object in a background job. When completed, an email is sent notifying the user that the job is completed.
- Note that View All and Modify All permissions will override more restrictive Organization-Wide Defaults
Sharing Settings and Granting Access Using Hierarchies
- An example sharing setting is to share all
Year = 1939with User
Production: Year EQUALS 1939
- Sharing Settings are specified via: Settings > Security > Sharing Settings (bottom of page)
- Sharing Settings can be set up to share with Public Groups, Roles, and Roles and Subordinates
- As with Org-Wide Defaults, creation of a new Sharing Setting results in recalculation of Sharing access in the background
Manually Sharing Records
- At time of this writing, the Sharing button is only available in Salesforce Classic
- This button shows which users have access, their Access Level, and the Reason for their access:
- Name: All Internal Users
- Access Level: Read Only
- Reason: Custom Object Sharing Rule
Create, Read, Update, Delete Operations – aka CRUD
- CRUD rights are set by object and profile
These notes were taken while studying using Mike Wheeler's Salesforce Courses.