
Knowing these basic Salesforce security settings can make all the difference for your users
Are your Salesforce users complaining about security settings, and that they can’t see some critical pieces of information? This can be incredibly frustrating for users and cause unneeded stress along with wasted time. Usually, it comes down to a problem with Profiles, Permission Sets, and Roles.
Setting the data that each user has access to is one of the key steps to ensure security and efficiency in your Salesforce org. After everything has been implemented and your data model is in place, the next area of focus should be understanding your users’ activities and level of access needed.
There are four different ways of setting users’ access and visibility on a record:
- Organization-wide sharing defaults
- Profiles
- Permission Sets
- Roles
Organization-wide sharing defaults set the baseline access for your records. Where our clients see the most trouble in diagnosing access vs visibility is with the other three – Profiles, Permission Sets, and Roles. So that’s where we’ll focus the rest of this post.
As a general guideline, here is what we recommend to diagnosing most access and visibility problems:
P → P; R → R. Profiles relate to Permissions (access) as Roles relate to Records (visibility).
Profiles and Permissions
Profiles define how users access objects and data, and what they can do within the application. When you create users, you assign a profile to each one. Profiles are typically defined by a job function.
- User interface: Tabs, page layouts, record types, applications
- Access to data: Field level security
- Login hours and login IP ranges
- Permissions: App, System, Standard/Custom object CRUD
Profiles are likely the issue if:
- A user cannot access an object
- A user cannot access a field
- A user cannot access a record type
- A user cannot access an app
User permissions specify what tasks users can perform and what features users can access. For example, users with the “View Setup and Configuration” permission can view Setup pages, and users with the “API Enabled” permission can access any Salesforce API.
Think of permission sets as additional access settings to individual users. They are very similar but more flexible than profiles, and you can assign them to specific users. For example, use a permission set if you want a couple of general sales users to have special access to API. You can use permission sets to keep general restrictions/visibility intact while allowing for special situations. Keep in mind that permission sets allow you to add but not subtract field and object permissions.
We recommend a security model that relies on several key profiles, and permission sets to add specific object/field-level access as needed, rather than set up a profile for every job title regardless of the functional differences. This is the easiest to maintain and scale as changes are needed.
Roles (based on the Role Hierarchy) and Records
Roles control the record visibility that a user has. Roles are likely the issue if:
- A user cannot see particular records
- A user cannot see the records of his subordinates
- A user cannot see the records of his coworkers in different departments (horizontal)
- A user cannot see proper report data (as reports are driven by record data)
Salesforce offers a user role hierarchy that you can use with sharing settings to determine the levels of access that users have to your Salesforce org’s data. Roles within the hierarchy affect access on key components such as records and reports.
Users at any role level can view, edit, and report on all data that’s owned by or shared with users below them in their role hierarchy unless your org’s sharing model for an object specifies otherwise. Specifically, within the Sharing Settings, you can disable the Grant Access Using Hierarchies option for a custom object. When disabled, only the record owner and users who are granted access by the organization-wide defaults receive access to the object’s records.
Basically this means if you are above a user in the role hierarchy you will be able to view all their records unless there’s a custom object specifically set not to be visible. The role hierarchy cannot be changed for standard objects.
Such are the basics of troubleshooting access vs visibility in Salesforce. For more nuanced access and visibility capabilities, check out Permission Sets, Sharing Settings (org-wide defaults), and Sharing Rules – and follow the Trailhead!