Who can see what in Salesforce?

One of the most important Salesforce features is the deep visibility architecture available to allow administrators to control access to company information within the organization and with external users.  This control is a critical component of data security and privacy, minimizing the misuse or theft of data, be it sensitive customer data or privileged internal company information.

Organizations are complex systems with many different layers of data and users. In this blog, we set out to answer how we go about matching the right person to the correct and appropriate information that will allow them to get their job done friction-free. This blog is a useful reference if you are studying for a certification or just trying to brush up on your sharing rules, so give it a bookmaker for future reference. You’ll understand who can see what in Salesforce.

OK, here we go….

First, let’s review the Sharing Architecture and its different layers. 

(Image: Salesforce )

Think of the sharing architecture as an inverted pyramid. The closer to the tip of the pyramid you go, the narrower and more precise the control is. The large base at the top controls broader sets of users in your Org. 

Object Access 

User Profiles Determine which objects users can access and the permissions they have on the object record. Object permissions include Create, Read, Edit, Delete. 

The user profile also determines which tabs are visible and which Apps are available to the user in the App Launcher and System settings that apply across all apps available in the Org. 

Salesforce provides standard profiles built-in with basic permissions pre-configured. 

Standard User, Administrator, and Read Only. These profiles serve as the basis for every other profile that we will create for our users. We can clone these profiles to create our custom profiles. This way, our profiles come pre-configured and, as an added benefit, we keep our profiles from auto-updating with new salesforce updates s they roll out until we have a chance to test them. 

Example: 

The Customer Service reps need access to Cases and Contacts, but we don’t want them to edit or delete Accounts. First, we navigate to Object Settings under the Apps section of the profile. Accounts are selected from the dropdown, and we uncheck the Edit checkmark in the Account Object permissions. We then navigate to Cases and Contacts and Enable Read, Create, and Write.

Just like that, we have granted our Service Reps the ability to edit their Cases and Contacts and prevented them from modifying any account data which is out of the scope of their assigned duties.  

Org Wide Defaults

Org Wide Defaults determine what access and permission users have to records they don’t own. These settings further restrict the level of access on records that the user does not own and can NEVER grant more access than they have through object permissions.   

We will set the Org Wide Default for each object for the entire organization. 

The Access levels available through Org Wide Defaults is:

Public Read Write Transfer: Allows all users to view, edit and change ownership 

Public Read Write: Allows users to view and edit records they don’t own, but they cannot transfer ownership to another user

Public Read Only: Users can see the records of an object but can’t edit or transfer ownership

Private:  Users cannot see records that they do not own in this object

Example: We would like all users to view and edit leads, but we only want the owner of the lead to transfer leads to another user. Also, users should only be able to see their own opportunities. 

In setup under security > sharing settings, we can set the default access for each object in the Org. First, we set Lead to Public Read/Write, allowing all the users to View and Edit the leads even if they are not their own. Then we set Opportunities to Private to restrict access to the Opportunity records solely to the owner. 

Now that we have set up Org-Wide defaults in our Org, we can focus on granting access via Roles.

Records Access via Roles

We can set up roles in a Role Hierarchy to open up access when the Org Wide default is set to anything more restrictive than Public Read Write. Roles within the hierarchy are assigned a specific level of access on the role edit screen. These three levels open up access to records in 3 ways.

No Access: This maintains the Org-Wide default, For example, private or view only. Users in this role will not see opportunities that they don’t own unless the Org-Wide default allows it. 

View Only: Users in this role will be able to see opportunities regardless of ownership. 

View and Edit: Users in this role will be able to see and edit opportunities regardless of ownership

It’s important to remember that Role Hierarchy cannot grant a user more access than they have on their profile permissions. So if a profile is set to Read Only Granting View and Edit access via role hierarchy will not grant that user the ability to edit records. 

Example: Org wide default is set to private so users cannot see each other’s opportunities; however, sales managers need to see the opportunities their Inside Sales teams are working on and make edits as needed.  

Since the sales Manager is placed above the Inside Sales role in the role hierarchy, we can grant them EDIT all opportunities so that they may View and Edit Opportunities owned by their subordinate sales reps and any other role below them in the hierarchy. 

Field Level Security

Some fields may have confidential information, such as commissions or other privileged data. We want to prevent users from seeing the information in these fields even if they have access to the object records. In this scenario, field-level security comes in handy. With this feature, we will limit which profiles have visibility to specific fields in the record. 

Field level security overrides modify all and view all user profile settings. 

Example: We would like to limit access to our Sales Reps commissions listed in the Opportunity Record. From the Object manager, we click the Opportunity object. We click Fields and Relationships and select the commission Field. From here, we click the field level security button at the top of the page. Now we can make changes to the field’s visibility and Editability for each user profile. 

For this example, we’d like to protect the Commission on our client’s opportunity record.  We can uncheck the “Visible” checkmark next to the Sales Rep User profile to create this field restriction. 

Even though that user profile has View and Edit permissions on this object, Sales Reps will not be able to see the Commission field on their records.  Our sensitive data is now protected from potential misuse. 

Record access via sharing rules 

Sharing rules open up access to records when the Org-Wide defaults are more restrictive than public read/write. In other words, Sharing rules extend access to users in roles, public groups, or territories regardless of their place in the role hierarchy.

There are three types of sharing rules:  Record Owner based, Criteria based, and Public Groups based.

Record Owner based:  

Records can be shared with a broader audience of roles and subordinates than the role hierarchy grants.

Example:  Sales Managers need to see the Opportunities owned by sales teams in a different region or territory. We create an Opportunity sharing rule based on Record Owner. On the Records to be Shared field, we add the US Sales Manager and his subordinates. On the users to share with, we add the Sales Manager in the other territory.  We select the option to grant Read-Only or Read-Write access and hit save. The manager in the APAC Territory can now see the Opportunities owned by the US sales team.

Criteria based:

Criteria based sharing allows the sharing of records based on the value inside a field in the object.  

Example: 

We want our HR Benefits Coordinator to have access to all Cases with “Company Benefits” in the Type field.  This Criteria Based Sharing Rule gives the benefits coordinator access to the benefits inquiries that come into the HR department without giving the user full access to every Case that comes into the HR department. 

Public Groups:

Public groups are sets of users that all have something in common but are not necessarily in the same role or group. Think of Public Groups as users with common interests but from diverse role backgrounds. 

Example: 

Our company has a philanthropic group that volunteers at various charities around the city. Volunteers come from all levels and Roles within the Org. By creating a Public Group, all of these users can share information such as tasks, events, and contacts relating to the charities. 

Record Types 

With Record types, we can control which business processes, page layouts, and picklist values our reps can access. 

We can use Record Types in salesforce to segment what information is visible to our users and their available sales paths. For this example, we can create different record types for sales to Small and Medium Businesses and sales to Enterprise-level businesses since they are handled by different sales reps and have a distinct set of fields and sales processes. 

To do so, we must first have our sales processes and opportunity stages pre-defined for each business unit. Page layouts can be shared from other record types that you already have in place or cloned and customized for this specific use case. 

In the Object Manager, select the object for which you would like to create a record type and click on the Record Type settings.  Name the record type and assign a sales process designed for this record type and assign it to the proper Profiles.

Assign the Page Layouts you created for this business unit. You can also create a new page layout after the fact and assign them to this record type.  

And that’s it. You have successfully created a Record Type that will control how your users interact with your org and its data and empower them to complete their jobs. 

Permission sets

With permission sets, we can expand users’ access and permission beyond what is listed in their profile. You can think of a Permission set as a supplement to the profile that you can apply as an additional layer to specific users who need specialized access to specific Records and Apps required to complete their job duties.

The permission set use-case shines when you have a subset of users within a profile that needs a little more access to certain records than the rest of their team. Users can also be assigned more than one permission set, so dialing in a specific user’s access based on their job responsibilities is simple and easy to manage vs. creating new profiles for every situation.

Example: 

A select few managers in our Org are responsible for hiring new team members. We can grant them access to the Recruiting App through a Permission Set instead of creating a new profile for these managers. We can also create a separate permission set can also include access to sensitive fields on the applicant record, such as Salary requirements and the added ability to view objects not included in the Standard Manager Profile. By having these 2 Permission sets, we can adjust the granularity of the access we give to various users tasked with hiring and recruiting. 

As managers change responsibilities, we can easily add or remove these permission sets from the user record without impacting their main user profile.

Congratulations! You’ve made it this far. You now know the extreme power and flexibility Salesforce gives its administrators to control the data and App access within the Org while providing the users direct access to what they need to get the job done.  Every business has unique data security requirements, and taking a one size fits all approach is not an option. Whether you are studying for your admin test or deep into your Salesforce career, this blog post should help demystify Who Sees What in Salesforce. Bookmark this page for future reference! 

If you have questions about building a robust sharing model for your Org, or have questions about who can see what in Salesforce, drop us a line.