Data Privacy Protections in Salesforce

Overview

Companies today are required to adhere to data privacy regulations based on the countries and regions they operate in throughout the world. Companies that operate in multiple data privacy jurisdictions have an added challenge when it comes to implementing privacy solutions. The various data privacy regulations do not always align on how the specified data should be protected which can lead to challenges in how IT implements these requirements. Platforms which provide out-of-the-box capabilities to meet these requirements and specifically allow for multiple security protections in parallel allow IT teams meet these requirements which is a win for those protected by these regulations and the businesses that manage the data.

Salesforce Platform

Salesforce is a widely-used customer relationship management (CRM) platform that is used by businesses of all sizes to manage and automate their sales, marketing, and customer service processes. One of the key features of Salesforce is its robust security model, which helps businesses protect their sensitive data and ensure that only authorized users have access to it. In this post, we’ll look at how you can leverage Salesforce Sharing and Visibility to limit access of records to a subset of users to meet data privacy business requirements.

Sharing

Sharing in Salesforce is the process by which access to records is controlled and determined. In Salesforce, access to records is based on a user’s role, which determines the level of access that user has to records. The sharing model in Salesforce is based on the idea of record ownership. When a user creates a record, they become the owner of that record and have full access to it. They can then share the record with other users, giving them specific levels of access.

The two main types of sharing in Salesforce are organization-wide sharing and role hierarchy sharing. Organization-wide sharing is the default sharing setting in Salesforce and determines the level of access all users have to records. Users are grouped into roles, and each role is associated with a specific level of access to records. Role hierarchy sharing builds on this by providing additional access to records based on a user’s role in the organization. This allows users to see data from subordinates and their teams.

Sharing Hierarchy

Visibility

Visibility in Salesforce refers to the ability to see certain records or objects. The visibility of records and objects is determined by a user’s profile and the sharing settings that have been configured for them. Salesforce offers several types of visibility controls, including record-level access, field-level access, and object-level access. Record-level access allows users to see only the records they own or have been shared with them. Field-level access allows users to see only certain fields on a record, depending on their profile settings. Object-level access allows users to see only certain objects, depending on their profile settings.

Protecting Records

Regulations which require need-to-know access for a limited set of users can be accomplished using Salesforce Sharing to limit which users have access to the records. The following approach can be used to implement this type of protection:

1. Identify the objects / fields that need protection
   • Classify the fields using Salesforce Data Classification Meta Data framework
   • Ensure that you have the data fields on each object required to identify the records that should be protected
2. Identify the users that should have access to to the protected data
   • Ensure that these users are either in a Public Group, Role, Queue, or Territory
   • Optional: Create a process to allow users to request access through an approval flow
3. Change the org-wide default sharing settings for each protected object to Private (Internal and External access)
4. Create a sharing rule that shares all records except those that that should be protected
5. Create a sharing rule that shares all protected records based on the criteria identified in #1 to the users identified in #2

Once the sharing calculations have completed only the users from the protected group should be able to see records created that meet the criteria for protection. Keep in mind that anyone that previously had access to the record as the owner or through one of the Sharing Hierarchy methods will still be able to see the record until that that issue has been corrected.

To test the protections, you can create reports that return records based on a criteria that should be protected. This will allow you to test as various users to ensure that only those users that should see the protected data are seeing those records. This makes it easy to find records that need to be corrected if they were open due to other types of Sharing Hierarchy reasons.

Protecting Fields

If the regulation only requires certain fields to be hidden you can leverage Salesforce Dynamic Forms as a way to hide those fields from users that should not have access. Salesforce Dynamic Forms allows you to define criteria using values on the record to identify those fields and which attributes on the user determine who should see those fields. There are limitations as to which objects you can migrate to a dynamic page layout so refer to the Dynamic Forms Limitations for those considerations.

Hiding fields on a form does not prevent users with API access from seeing hte protected data so if you have the need to protect the data both through the UI and API you should consider using profiles to drive field-level access.

Pitfalls

Whether you are managing data privacy using the record level or field level approaches there are some Salesforce features that could override your intended sharing audiences which you should be aware of:

• Implicit Record Sharing
  • Implicit Sharing provides record owners access to parent and child records for select objects (e.g. Account, Contacts, Opportunities, Cases)
  • The account owner’s role determines the level of access to child records
  • Recommendation: Check existing record ownership for the objects you are protecting to see if these support implicit sharing. If so, reassign the records to approved users to prevent oversharing. Check the Account owner’s role access settings for Opportunity/Contact/Case to see if access is being granted through the role settings.
• Role Hierarchy Sharing
  • If you have “Grant Access Using Hierarchies” option checked in your Sharing Settings on a particular object users in the role hierarchy above the owner of the record will have access to the record
  • Recommendation: Determine whether you are using role hierarchy and whether it’s necessary to create a role outside of the existing hierarchy to place the users working with these protected records. If you cannot change the role hierarchy and still want to disable hierarchy access you can use a dummy user as owner of the records and then create public group to map the roles users with “Grant Access Using Hierarchies” unchecked which overrides the object level hierarchy access.
• Territory Manager Access
  • Users with the ability to manage territories have the ability to see all Account records which could be counter your data privacy policy.
  • Recommendation: Minimize the number of users with the access to manage territories and make sure territories are created with sharing access disabled to Accounts, Contacts, Opportunities, and Accounts
• Account Team Sharing
  • When assigning account team members you can specify record access for standard objects (Contact, Opportunity, Case) which will override your default Sharing rules
  • Recommendation: Create a flow to add Account Team members that does not expose these sharing settings when adding an account team member

Summary

In summary, Salesforce security model gives a great deal of control over how users can access the data, by using sharing and visibility settings. Businesses can use these features to ensure that sensitive data is only accessible to authorized users and that users can only see the data they need to do their job effectively.