Locking down record access in Salesforce With the powerful Salesforce sharing features, you can support collaboration within your organization while keeping sensitive information secure. And while you must always balance collaboration with security, there are situations in which you might need to make absolutely sure that record access is limited to a very small number of people, regardless of their position within the corporate hierarchy.

In this post, you’ll learn about the sharing features and strategies you can use to do just that.

When Even the CEO Shouldn’t See Certain Records

There might be many reasons why your organization needs to restrict access to especially confidential data. Two situations that we have seen particularly often are:

Mergers and acquisitions – These events can shake up the market, and access is typically restricted to the small group of people actively working any particular deal. If this group is formed of specialists from different parts of the organization, the M&A data could be exposed too broadly through the normal operation of the role hierarchy.
Highly confidential client relationships – In some fields and industries, such as health care and private banking, only the individuals working directly with customers should have access to their data. Even senior executives are not allowed to see this private information.

In these cases, the role hierarchy that simplifies how record access is provided to managers works against you. Fortunately, you can use other Salesforce sharing features to set up the tightly restricted access you need for these situations.

Sharing Strategies for Maximum Security

Getting to the Sharing Settings page When your confidential data is contained in a custom object, you can easily prevent record access from rolling up a hierarchy for that specific object. From Setup, click Security Controls | Sharing Settings. In the Organization-Wide Defaults section, you should see the Grant Access Using Hierarchies column.

If you set a custom object’s organization-wide default to Private and deselect “Grant Access Using Hierarchies” for that object, then without additional sharing, only record owners and administrators can access the object’s records.

If your security challenge is like the previous “highly confidential client relationships” use case, deselecting the “Grant Access Using Hierarchies” option will do most of your security work for you. You will also want to thoroughly review these other areas to make sure the data is locked down as tight as possible.

Profile settings and permission sets that grant the “View All” or “Modify All” permissions for the confidential objects
Sharing rules, Apex managed sharing, and other sharing mechanisms that might expose confidential records
Encrypted fields that restrict particularly sensitive information, even for those users who can see protected records

In the case of merger and acquisition activity, shutting off the default hierarchy access is only half the job. Once you protect the data in this way, you then need to make sure that all the people on the M&A team have access. To accomplish this goal, you can take advantage of a public groups option that you might not have noticed in the past.

If you create a public group and add everybody on the M&A team as members, they will all have access to whichever records are shared to that group. Deselecting “Grant Access Using Hierarchies” for the group ensures that this access isn’t extended to managers who are higher in the role hierarchy than the M&A team’s members. You can then share data to the group with ownership based sharing rules, criteria-based sharing rules, or Apex code, and record owners can share their records to the group using manual sharing.

Record Ownership and Standard Objects

When implementing the strategies described in this blog post, it’s important to keep in mind that every record in Salesforce must have an owner. And unless a record owner doesn’t have the Delete object permission—which you can configure through a custom profile—the record owner has full power to delete any record he or she owns. The record owner also has the ability to manually share those records to any other user. Even if you remove the Sharing button from the user’s page layout, the underlying permission remains. So there is a risk that technically savvy users could find a way to share records they own programmatically.

This level of security might fit with what you need for the “confidential customer relationship” scenario, where the record owner is acting as an adviser and a manager of the client’s business. In that case, it does make sense for the record owner to manage the sharing of the record personally. But this might not be desirable, and it certainly doesn’t fit the use case for M&A activity. If you, as an administrator, don’t want anyone else, including a record owner, to be able to delete or share the record, you might need to create a “dummy” or “integration” user to own the data, then use sharing rules or Apex code to share the data to the appropriate groups and individuals. You should either make this dummy user the sole member of a role that’s at the very top of the role hierarchy or avoid putting the user in a role altogether. See the “Ownership Data Skew” section of this paper for more information about concentrating record ownership.

You will also need to concentrate ownership this way to employ any of these strategies to lock down standard objects, because the option to prevent roll up of visibility for records owned by users in the hierarchy is not available for them.

Summary

The role hierarchy in Salesforce greatly simplifies the task of configuring management access, report roll-ups, approval workflows, and collaboration between teams and business units. But when you are trying to restrict access to highly confidential data, you might have to think creatively about when and how to use the hierarchy to share records. With a clear understanding of record ownership and the features that allow you to exclude specific data from the normal sharing operations of the role hierarchy, you can easily implement very strict data protection policies.

Related Resources

About the Author

Bud Vieira is an Architect Evangelist within the Technical Enablement team of the salesforce.com Customer-Centric Engineering group. The team’s mission is to help customers understand how to implement technically sound salesforce.com solutions. Check out all of the resources that this team maintains on the Architect Core Resources page of Developer Force.