Security

Security Introduction

  • 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

Introducing Profiles

  • 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

Introducing Roles

  • 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
    • Private
  • 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 Productions with Year = 1939 with User John Doe
    • Criteria: 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