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!
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.
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.
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.
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.
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.
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.