Table of Contents
In this post, we will discuss in depth all scenarios of who sees what in salesforce based on various settings we have. If you have ever been confused about Data Security in salesforce this post is just the one you are looking for. Let’s jump right in.
Org Access: Creating and activating users, and allowing them to log in from set IP ranges and hours.
Object Access: At the Profile level, define the objects they need access to.
Record Access: For example, Access to records based on specific criteria.
Field Access: Restricting access to certain information for particular groups and visible to specific users.
Controlling Organization Access
By default, salesforce does not restrict users from logging in, based on demographic ranges or timings. We can though set up IP ranges to secure the accesses through the below.
- IP Ranges [Company level] Users outside the range are sent activation codes to verify identity.
- IP Ranges [Profile level] Users outside this range are denied access.
- Login Hours [Profile level] Users trying to log in outside of these hours are denied access.
Controlling Object Access
Profiles determine the objects users can access and the permissions they have on an object record. They determine which apps are visible and available in the App Launcher. We can also set the default App for the profile. They also determine object access and what permissions people have to each object: Create, Read, Edit, and Delete.
- Standard user: CRED access on accessible records
- Read Only User: Read access on accessible records
- Solution Manager: Standard User + manage published solutions
- Marketing User: Standard User + import leads
- Contract Manager: Standard User + manage contracts
- System Administrator: View All, Modify All
We can’t edit the above-mentioned standard profiles but we can clone and edit them to create custom profiles.
Org Wide Defaults are located in Setup, under Security > Sharing Settings.
When we want all employees to view and edit each other’s records we set the OWD to Public Read/Write. This setting doesn’t enable non-owners of the record to be able to transfer the record to a new owner. To enable record ownership transfer by non-owners, we have an access Public Read/Write/Transfer access available on some Objects.
When we want all users to view but not edit each other’s records, we make the access Public Read Only.
When we want all users to update each other’s records, we make the access Public Read/Write.
When we want users to keep their records private, i.e. users see only their own records we set it to Private. These records are only visible to their owners and users above them in the role hierarchy. Users can’t see each other’s records unless specifically shared.
When assessing how Org Wide Defaults work in conjunction with profile permissions, remember that profile permissions determine the baseline level of access a user has to all records. Org-wide defaults can then further restrict these permissions on records a user does not own.
| Profile | OWD | Access |
| CRED | Private | Users can create new records, view only their own records, and edit and delete. |
| CR | Private | Users can create new records and read their own records only. No edit or delete permissions. |
| CRED | Public Read | Users can create new records, and view all records including those owned by others. Edit and delete button on records not owned by self, will though result in an Insufficient Privileges message as OWD is Public Read. They still can edit and delete their own records. |
| Public Read | If we remove all Object permissions (profile permissions) from above, then the user can’t see any record of that object. They can’t find them through search or through reports even. |
| CRED | Public Read/Write | Users can create new records, view all records, and has permission to edit and delete all records on that object as well. |
| CR | Public Read/Write | Users can create new records. However, the edit and delete buttons aren’t available for any records. Remember OWD can never grant users more access than they have through their object permissions. |
Controlling Record Access
Roles help extend access to records when OWD Sharing settings have been set to anything more restrictive than Public Read/Write. Role hierarchy lets us open up access in 1 of 3 ways. For each Role, we can choose 1 of the following:
No Access: In essence, this maintains the OWD of Private. People in this role won’t be able to see opportunities they don’t own.
View Only: People in this role can view opportunities, regardless of ownership.
View and Edit: People in this role can view and edit opportunities, regardless of ownership.
Remember, the role hierarchy cannot grant a user more access than they have through their profile permissions.
| Profile | OWD | Role Hierarchy settings available | Comments |
| CRED | Private | No Access View View + Edit | We can grant any of the three options to the object records below him in the hierarchy. |
| CR | Private | No Access View View + Edit | If the profile was just created and edit permissions, the role hierarchy still offers us the same options. However, even if we choose view+edit, the user won’t be able to edit/delete the object records below him in the hierarchy. The reason being the profile doesn’t grant that permission. |
| CRED | Public Read Only | View View + Edit | If the OWD is Public Read Only, role settings provide only two: view and view+edit. No access is not present as Role Hierarchy can only open up access and not restrict them. |
CR | Public Read Only | View View + Edit | The user has read-only access to records. View + Edit is available but doesn’t apply. OWD and Role settings can’t grant him Edit access as not granted by the profile. |
| CRED | Public Read/Write | Not necessary | Has all access already via Profile and OWD Settings |
| CR | Public Read/Write | Not necessary | Has access to all records, but only Read permissions, since OWD and Role Settings don’t grant more permissions than the Profile. |
Roles allow us to open record access vertically. That is, US Sales Manager can access only their team records and APAC Sales Manager can access only their team records. Though both managers are at the same level they don’t have access to each other’s team records below them in the hierarchy. For achieving this horizontal access we have Sharing Rules.
Controlling Field Access
Field Level Security allows you to control the visibility of data at the field level. It allows us to grant or restrict visibility to individual fields based on the user’s profile.
We have two options: Visible and Read-Only. Checking the Read-Only tick box allows you to limit access to this specific field, even if a user has edit permission on the object. Field-level security overrides both the “Modify All Data” and “View All Data” user permissions.
| Profile | OWD | Role Hierarchy | Field Level Security available | Comments |
| CRED | Private | View + Edit | Hidden Read Only Visible {+ Profile permissions} | Users can have an object field as hidden, read-only, or visible, and options as available. In conjunction with his profile permissions, he can edit the field. |
| CR | Private | View + Edit | Hidden Read Only Visible {+ Profile permissions} | Users can have an object field as hidden, read-only, or visible, and options as available. If we mark a field as Visible; Since edit access isn’t there in the profile, then in effect it is Read only for this profile. |
Neither the Role Hierarchy nor the Field level of security can grant a user more access than they have through their baseline permissions.
Record Access via Sharing Rules
We implement sharing rules to open record access up to users when the org-wide defaults are more restrictive than Public Read/Write. It helps us to extend record access horizontally (as opposed to vertically using Roles).
Sharing rules, lets us extend access to users in roles, public groups, or territories* regardless of their place in the role hierarchy. Sharing Rules is located below Org Wide Defaults in Setup, under Security > Sharing Settings.
We have two types of Rules for record sharing: Record owner-based or Criteria based. We have two types of access: Read Only, and Read/Write.
The Blend
A user’s baseline permissions on each object are determined by the profile. If we are using permission sets, they also set the baseline permissions with the profile.
Baseline Object Permissions (Profile, Permission Sets)
The access to records a user does not own is first set by the OWDs. If the OWDs are anything less than the Public Read/Write, you can open access back up to certain roles using Roles Hierarchy. It can be further opened up using Sharing Rules. And the record owner can also share individual records with other users by using the Share button on the record.
Record Types
Record Types help gather and organize data in different ways and at different times, around the same object. For example, one case object might have two different use cases in one single organization. There can be one internal and another external and might need to gather slightly different information and thereby require different picklist choices. They might also need to go through different business processes. Record Types are used for such scenarios.
Record Types control: Business Processes, Page layouts, and Picklist Values.
Business Processes are represented by special picklist fields that capture the lifecycle of a standard object like Case, Lead, Opportunities, or custom objects.
Page Layouts let us select and organize groups of fields related to an object. We can create various page layouts as desired.
Picklist values are the list of choices defined when we create a picklist field. We define a master list with all possible choices and use record types to display a subset depending on the situation.
For example a case, we can create a case support process. using the status field. We add our choices to the fields and then got to Support Processes to define a unique process for each type of case. We create a process for each business process we require and add the picklist choices for the Status field.
We create different record types and make them available to the required profiles who will need to use that. Next, we can select the page layout for that particular record type.
Now whenever we want to add new picklist choices to a particular field, we have the option to make them available to users based on the Record Types.
Any records created before creating a record type won’t have an associated record type. We can achieve that by assigning them the same programmatically or else using Data Loader tools using proper Record Type IDs.
Permission Sets
Profiles typically provide access to the general functions that a type of user performs. Permission sets, however, help extend these for the scenarios when some users require access to some additional objects and settings but we don’t want to extend that to every one of that profiles.
A Permission set is a collection of permissions and settings that give users access to objects and functions. It holds many of the settings found in the profiles like Object and field permissions, tab settings, app settings, and user permissions.
We can create a Permission set and add that to the users who need any additional permissions. The permission set license must match the user license of the users who will get this permission set. We can find the settings to grant desired access like read, edit, delete, transfer, etc. We can assign the permission set to requisite users and thereby grant special access. We can have only 1 Profile for each user but we can have up to 1000 Permission Sets for a user.
If this post was any help, or if you want to add some edits, please let u know in the comments down below.