Security and Access, 13%

Explain the various organization security controls (for example, passwords, IP restrictions, identity confirmation, network settings). Given a user request scenario, apply the appropriate security controls based on the features and capabilities of the Salesforce sharing model (for example, organization-wide defaults, roles and the role hierarchy, manual sharing, sharing rules, and public groups). Given a scenario, determine the appropriate use of a custom profile or permission set using the various profile settings and permissions. Describe how folders can be used to organize and secure communication templates, dashboards, and reports.

Organization Password Security Controls

  • Set via: Setup > Security > Password Policies
  • Can set up: password expiration, historical passwords remembered, minimum password length, password complexity, max invalid login attempts, lockout period etc
  • Lockout effective period typically “Forever”, meaning user is locked out until reset by admin
  • Can specify messages sent to user if they forget password, get locked out, etc

Network Access and Setting Trusted IP Ranges

  • Set via: Setup > Security > Network Access
  • Ideal for a workplace where the internal network’s IP addresses fall within a certain range.
    • IPv4: IP addresses range from 0.0.0.0 through 255.255.255.255
    • IPv6: much larger IP address space
    • Example 100-IP range might be: 255.255.255.255.155 thru 255.255.255.255
    • If outside that IP range, will need to activate their computers

Login IP Ranges

  • Similar to trusted IP ranges, except control is at the Profile level, not the Org level
  • Set via: Setup > Users > Profiles > Select a Profile > Login IP Ranges
  • Users with the specified profile login IPs can only log in from IP addresses within the range. Otherwise, they are unable to access Salesforce.

Trusted IP Ranges vs. Company Login IP Range

Login Hours - What happens at 5:01 PM?

  • Allowed Login Hours are specified at the Profile level, like login IP ranges
  • Users are only able to log in during those times. Example:
    • Start Time: 7:00 AM PDT
    • End Time: 5:00 PM PDT
  • If a user is logged in when the End Time passes, user will be switched to read-only mode on their current page. Then, once they try to navigate to a new page, they will be logged out.

Identity Verification and History

  • Set via: Setup > Identity > Identity Verification
  • Also available via: Setup > Security > Session Settings
  • Can set various policies such as:
    • Require identity verification for change of email address,
  • Can view history of identity verification via: Setup > Identity > Identity Verification History
    • Can set up list views that include the latitude, longitude, postal code of where users have verified their identities

  • Org-Wide Security Settings are found under Settings > Security
  • User-Specific Security Settings are found under Settings > Users

Profiles Introduction

  • Profiles are a massive but fundamental topic in Salesforce
  • When working with Profiles, make sure “Enhanced Profile List Views” are enabled
    • Set via: Users > User Management Settings
  • Standard (Non-Custom) Profiles generally should not have users assigned to them. These have some limitations.
    • Exception is “System Administrator”
  • Setup > Users > Profiles
  • View All Data, Modify All Data: important settings that overrides all other sharing settings.
    • Accessible at Profiles > System Permissions
  • Profile Permissions broadly split into App Permissions and System Permissions
    • App Permissions: Apply to apps like Sales as well as custom Apps built on the platform
    • System Permissions: Settings that apply across all apps, and include record and user management
  • App Permissions > Assigned Apps: control which apps are visible to each profile. Also controls which App opens as the default.

Profile Object Settings

  • Mike Wheeler says he has spent more time in Object Settings than anywhere else in Salesforce - very fundamental and very important.
  • Set up via: Setup > Users > Profiles > Select a Profile > Object Settings
    • Specifies Record Types assigned and default for each object
    • Specifies “CRUD” rights for each object:
      • Read, Create, Update (“Edit”), Delete
      • View All, Modify All
      • Read, Edit access to each Field on the object
      • Two dashes under Object Permissions means the profile has no access to them

Profile Tab Settings - On, Off and Hidden

  • Tab settings are specified for each object and can be:
    • Default Off: tab is available on All Tabs page. Users can customize their display to make the tab visible in any app.
    • Default On: tab is available on All Tabs page and appears in the visible tabs for its associated app.
    • Tab Hidden: tab is not available on the All Tabs page or visible in any apps.

Creating a Custom Profile

  • Profiles are always cloned from existing profiles due to the huge number of settings that need to be configured.
  • Best practice is to start all custom profile names with “Custom: "
    • For example, if the new custom user is cloned from “Standard User,” it should be named “Custom: Standard User”
  • Best practice is to always assign new users to a custom user profile, not a default user profile, like Standard User

Custom vs. Standard Profiles

  • Best practice is to assign users to custom, not standard, profiles
    • Standard profiles cannot have permissions changed and cannot have access granted to custom objects
    • Exception is the System Administrator profile. Best practice is to use the standard System Administrator profile for sys admins
    • If users cannot access certain objects or fields, a likely explanation is they have been assigned to a Standard profile

Roles and the Role Hierarchy

  • Roles open up record access vertically:
    • Users higher on the role hierarchy can access the records of the users below
  • The company name used when setting up the Trailhead account is used as the top level of the role hierarchy. It can be changed from the “Company Information” page
  • Setting up a role hierarchy is usually not as simple as replicating an org chart. The role hierarchy needs to be set up so that record visibility is set up correctly for the organization

Editing the Role Hierarchy

  • Best practice is to only edit the role hierarchy in a Sandbox or other test environment
  • Best practice is also to capture the current state of the role hierarchy before making any changes. Copy and paste the expanded role hierarchy into a Word doc, for example, then make changes methodically
    • Changing the role labels is possible, but best practice is that it stays close to the actual “Role Name” used by the API
      • Should not change the name if code has been written that uses the role name

Setting Organization Wide Defaults

  • Visual explanation of record-level security available:
  • Org-Wide Defaults are the default level of access for records you do not own
  • Set org wide defaults via: Setup > Security > Sharing Settings
    • Can make changes on a per-object level in the “Default Internal Access” column. Various types:
      • Public Read/Write/Transfer
      • Public Read/Write
      • Controlled by Parent
      • Public Full Access
      • Private
    • For example:
      • Leads by default have Public Read/Write/Transfer
      • Opportunities by default have Private
  • After changing an access level, Salesforce will need to recalculate permissions in a “background job”
  • Org-Wide Default sharing settings dictate whether record access is limited to just profiles that own those records
    • Grant Access Using Hierarchies checkbox controls whether people above the owner in the role hierarchy have the ability to see the owners' record
      • Standard objects cannot have this hierarchy access turned off

Profiles vs. Roles

  • Profiles vs Roles is an important distinction for admins to understand
  • Users can see/edit all records on an object if their profile has View All and Modify All permissions on that object
    • Setting is typically limited to system administrators because it is very powerful
  • Roles: “Opens up access vertically through the role hierarchy”
  • Profiles: “Set system settings and app settings, including object-level CRUD settings”
    • Includes View All and Modify All settings

Sample Exam Question #1

Enhanced Profile List Views

  • Enhanced Profile List Views need to be enabled in Settings > User Management > User Management Settings
    • Enables setting up list views of the profiles available in the org
  • Navigate to Users > Profiles > Create New View to set up new list views of profiles
    • Can view profiles by CRUD rights on each object, for example
      • Ex: Can remove Account: Delete permissions right in the list view
    • Can make changes across profiles by selecting all multiple of the available profiles with the checkboxes at left
      • Very useful to set up list views on a per-object basis, to view permissions across multiple profiles and objects

Permission Sets

  • Permission Sets function like Profiles, except:
    • Users can have one Profile
    • Users can have multiple Permission Sets
  • Permission Sets are a means of opening up permissions beyond their profile:
    • For example, a permission set might be called Delete Accounts and grant the ability to Delete Accounts, which other users might not have
    • New permission sets have no ability to no access to any objects - they must have permissions specifically added
  • Permission Sets: collection of settings and permissions that give users access to various tools and functions
    • Many of these same settings are available in profiles
    • Permission Sets were rolled out in order to allow organizations to provide exceptions to normal profiles
      • Saves those orgs from having to create a large number of additional profiles

Profiles vs Permission Sets

  • Profiles and Permissions are both split into App permissions and System permissions.
    • Profiles have similar App permissions available
    • Profiles have more, and Permissions have fewer, System permissions available

Sharing Rules

  • Access Sharing Rules via Settings > Security > Sharing Settings
  • Sharing Rules open up access laterally
    • Can share records of a selected object type with Public Groups, Roles, or Roles and Subordinates
    • Can share only records that match up to certain field criteria

Manual Sharing

  • At time of these notes, Manual Sharing is on the road map for roll out in Lightning
    • For now, need to switch over to classic, click into a record, then click Sharing
      • Displays a list of the users with access to that record, as well as what mechanism provided that access
  • Can share with Public Groups, Roles, Roles and Subordinates as well as specific Users

Field Level Security

  • Field Level security is accessible via: Object Manager > Select an Object > Fields & Relationships > Select a Field > Set Field-Level Security
    • Can make Invisible and/or Read-Only
  • Note that if you can’t view a particular field on a record, you won’t be able to view it on a report, either

Public Groups

  • Accessible via Setup > Users > Public Groups
    • Public Groups are groups of users
      • Groups can include any combination of Users, Groups, Roles, and Roles and Subordinates, as well

Folder Security

  • Folders can be used to organize and secure Communication Templates, Dashboards, and Reports
    • One example is available at Setup > Email > Classic Email Templates - templates are stored in folders
  • List Views are not stored in the same type of folders