4 Pillars of Salesforce Security: Controlling Who Can See What
When I graduated from college, my first job focused on data security for a university in Boston. While it had next to nothing to do with the International Relations degree with which I graduated, and it was not the State Department job I had perhaps envisioned, it did have a profound impact on how I see data access. Forevermore when I look at a system I find myself asking, “Does this person (or role) have a business need to see this data?”
Fast-forward a decade and suddenly I found myself once again looking at how to protect student data for another education institution (amazing how things go full circle) but this time in London. As an inexperienced Salesforce administrator with no formal training, I cobbled together what I thought was an adequate system. However, at that time I did not know about all of the tools I had available in my Salesforce security arsenal that would have allowed me to secure the system faster and more effectively.
As I began to understand the four pillars of Salesforce security and which control what a user can see, the more I began to understand how easy it is to lock down and protect the data within a system. Likewise, I realized that just as a house cannot stand with only one or two walls, a truly secure system almost always must be supported by the four pillars: Organization-Wide Defaults, Record Owner, Role Hierarchy, and Sharing Rules.
Before going further, I want to highlight that these four pillars only control what a user can see; later in the summer I will write a second post on Profiles which control what a user can do. Profiles need to work in tandem with these four security pillars; otherwise, all of your hard work as a System Administrator will be undone (cheery thought I know). However, more on that at a later date!
Organization-Wide Defaults
If someone had told me about Organization-Wide Defaults (or Org-Wide Defaults for those of us who find three-syllable words too long to say over and over) back in the day, it would have made securing data a lot easier. New System Administrators may not realize that out-of-the-box the Org-Wide Defaults are actually extremely liberal. These settings are found under Setup | Security Controls | Sharing Settings and have four options: Private, Public Read Only, Public Read / Write, and Public Read / Write / Transfer.
As a best practice, lock down these defaults so they are as restrictive as possible yet still allow your users to do their jobs. For example, when looking at the Opportunities Object, do you want users to have the ability to edit any Opportunity record (Public Read / Write), see all Opportunity records (Public Read) or just have the ability to modify Opportunities that they own (Private)? When considering these default settings I recommend not only thinking about the current Users in your system, but be mindful of the future. It might be fine for now for everyone to edit everyone else’s records, but will you remember to go back and lock these settings down if a new department is added to your Salesforce instance two years down the road? If you forget to do this, what will the consequences be if everyone has Public Read / Write access by default? It is always easier to go back and relax settings if business demand dictates it rather than take access away.
Record Owner
All records in Salesforce must have an Owner, whether it is a User or a Queue. Always take the time to accurately set record ownership, as this will determine who can see a record based on the Org-Wide Defaults. How could assigning the wrong owner impact the business process? Let’s take a scenario where a System Administrator is asked to import a large number of leads, but he or she does not set a Record Owner for each one. By default, unless otherwise specified, the records are owned by the person doing the import, so in this example the System Administrator owns all of the records. This may be fine if the Org-Wide Default for the Lead object is set to “Public Read / Write / Transfer.” However, if the default is set to “Private” then the team that actually needs to see the imported leads will not be able to access them because they do not own them. As a result, whenever doing a data import, it is a best practice to ensure a column is added for Record Owner and the information is populated.
One other note of caution about Record Owners: records can only be assigned to active Users. Day-in and day-out this should not have an impact on your system; however, when importing legacy data you may need to reactivate or add an old User to make the appropriate assignment and then deactivate the User again.
Role Hierarchy
A question new System Administrators will often ask is “If I set an Object to ‘Private,’ then how can Managers view the records that their staff own?” This is where Role Hierarchies come into play. Found under Setup | Manage Users | Roles, the Role Hierarchy is similar to an organization chart that shows how Roles are related to each other. While it may or may not match your company’s org chart exactly, it will show how Users within Salesforce are related to each other. A role can have one, many, or even no Users assigned to it, and it is a best practice to ensure that every User is assigned a Role when first added to the system. Utilizing Role Hierarchy means that two Users at the same level, say the East Coast Sales Representative and the West Coast Sales Representative, will not see each other’s records if the Org-Wide Default is set to “Private.”
From a security point of view, the Role Hierarchy is important for two reasons: staff higher in the hierarchy will be able to see the records of people below them, and perhaps more significantly, they will also inherit the security attributes of the Roles below them. The first part of this is fairly straightforward. If the Sales Director is placed higher in the Role Hierarchy than the team of Sales Representatives, then you would expect the Director to be able to see each Rep’s Leads and Opportunities, even if he or she is not the Owner of the records. It also means that if the Sales Representatives have “Public Read /Write” to be able to edit each other’s records, then so does the Sales Director and anyone above him or her, such as the CEO. While for some companies this might not be a concern, in others it might be worrying that members of the executive team have unrestricted access to modify an opportunity record.
Remember that creating the Role Hierarchy is not enough; it is also a best practice to assign a Role to any new User added to the system. Otherwise none of the security settings that are inherited through Role Hierarchy will affect that user.
Sharing Rules
What happens when you have an exception to the Org-Wide Defaults? This is where Sharing Rules come into play. Also found under Setup | Security Controls | Sharing Settings, the Sharing Rules allow you to set exceptions to the Org-Wide Defaults. Imagine that Sales Reps should only have access to their Opportunities (Private) but Marketing needs to be able to view all Closed-Won Opportunities (Public Read). In this scenario the Org-Wide Defaults can be set to “Private” but a Sharing Rule can be created to grant Marketing users “Public Read” access to all records marked as won.
One of the benefits of Sharing Rules is that the rules can be based on record Owners or on criteria. This means you can share all records owned by a particular group or role, or alternatively you can only share records that meet a particular criteria, such as stage or industry. By creatively, and accurately, utilizing Sharing Rules, you can provide wider access to some roles while continuing to limit what most roles can see. However, as you build these, just be sure to check the rules carefully to make sure one rule does not override another. Also it is important to note that Sharing Rules can only make the security settings more liberal rather than more restrictive. If the Org-Wide Default for the Leads object is set to “Public Read / Write,” then a Sharing Rule cannot be used to change access to leads to “Public Read” for some users. However, if the default is “Private,” then a Sharing Rule can be used to give certain users “Public Read / Write” access.
Beyond utilizing Sharing Rules, there are other ways to share records that I will just briefly highlight. For the Account, Opportunity, and Case Objects there is an option to activate Teams if more than one user will be working with the Record. For one-off sharing there is the possibility of using Manual Sharing, giving another User access to just one particular record without writing a full Sharing Rule. Lastly, Apex Sharing Rules can be used by developers to share records programmatically.
Conclusion
Hopefully this high-level overview of Organization-Wide Defaults, Record Owner, Role Hierarchy and Sharing Rules has provided some food for thought on how to better secure your Salesforce instance. That said, at the risk of completely overwhelming newer Administrators, I must note that we have only begun to discuss the power of each of these four pillars of Salesforce security. Nevertheless, by beginning to understand how one impacts the other three, a system administrator will be able to utilize each of the four pillars to achieve a strong, robust security policy.
