Get your FREE 30-day trial.
Please complete all fields.
In lots of organizations Salesforce security is like Fight Club because the number one rule is that we “don’t talk about Fight Club.” I think it’s because security in Salesforce is so flexible that it can be overwhelming and intimidating and so it becomes the thing that admins don’t want to talk about or deal with. The truth is that we think it’s going to be difficult so we make it feel difficult. However, lend me your geeky minds for a few minutes so that I can convince you that security should be easy to setup and maintain.
Also, (sorry Salesforce.com) but mostly people just find it scary; really, really scary. Which is another feature it has in common with Fight Club. So rather than leave your security setup in Fight Club mode let’s make it more like The Wizard of Oz where data and activities are revealed automagically and there’s a no divine inspiration behind sharing your company’s information. What follows is an attempt to simplify how security works and explores how to implement and test the basic features so that your company’s data will be safe and sound from the Brad Pitts and Edward Nortons of the world.
First Round: Who can see what vs. Who can do what
Security can be confusing because there are so many layers but at its simplest terms security can be divided into two segments: what you can see versus what you can do.
We are going to understand:
Let’s use the following scenario to help successfully start setting up sharing (say that five times fast!):
Profiles: Power over what a user can do
Profiles give users permission to each object and determine what a user can do to records within the object. Profiles also control access to apps, tabs, page layouts, record types and fields. The ability to edit records is referred to as CRUD (Create, Read, Update/Edit, Delete) and as the System Admin you can set each permission by profile.
Based on our scenario above here is a sales user’s profile who can create, read and edit Opportunities but cannot delete them. I also left the “View All” enabled so that they can see any record regardless of ownership which will save writing a few sharing rules.
Note: In Professional Edition you can assign different profiles with various permissions but you can’t create new profiles or edit existing ones; in Enterprise you can create and modify profiles a large profile-to-user ratio is difficult to manage so you want to use as few as possible.
Org-Wide Defaults: OWD not OMG!
Org-wide defaults (OWD) provide a baseline level of access for each object; lots of organizations leave their Org-Wide Defaults set to “Public Read Write” but when you need some privacy around your data you need to change the OWD. Again referencing our scenario above (only the record owner or their Manager should edit Opportunities but everyone should still see everything) you would set the Org-wide defaults for Opportunities to “Public Read Only.”
Role Hierarchy: Give everyone a promotion
The role hierarchy indicates where a user sits in terms of the data they need to see and it’s important to communicate to users that the role hierarchy is not usually reflective of your organizational hierarchy - it is simply a way of organizing groups of people according to the access they need to read and edit records.
To the left we can see that the Director of Direct Sales can see and edit all the records of her direct reports and the Director of Channel Sales can see and edit all the records of his direct reports while the VP of North American Sales can see and edit records belonging to everyone below her in the role hierarchy.
And when looking at “My Team’s” reports each user will automatically see the data for their appropriate group.
Sharing Rules: Not scaring rules
With the OWD and role hierarchy in place we now need to create sharing rules to extend edit permissions to the Support Team. I think this feature is the most common barrier to implementing security within Salesforce because it’s like doing algebra or a crossword puzzle but in fact all you are doing is overriding “Public Read Only” for specified users.
The easiest way to determine who should have access to what is to draw a big grid on a whiteboard (or spreadsheet) with each object on the side and groups of users along the top then complete each box indicating if they need to read/edit/delete records that don’t belong to them
A picture speaks a thousand words and now we can see that all users can view everything but we need to make changes so that Support can edit other user’s records.
Having defined what we want to do we then create new rules so based on record owner so that we can extend edit permissions. Based on the record owner I start at the top of the role hierarchy with the VP of North American Sales and her subordinates and work down so that I create as few sharing rules as possible and I enable edit for anyone in the role of Service and Support Advisor.
And all that thinking looks like this when saved:
Record Based Sharing: Give power back to record owners
Users can also share single Opportunity records with other users who are not automatically granted access rights by sharing rules or hierarchies. For example, if I want to give a colleague on the West Coast access to work my Opportunity I would just click the “Sharing” button on the far right.
Test Your Changes: “Professor Marvel never guesses, he knows!”
The last thing you need to do is to test your changes. Make these amendments in your sandbox first and login as each type of user profile and role to check that you can create, edit, save, change but not delete records and check that the “My Team” reports and list views automatically display the appropriate data. It’s pretty easy if you just refer to your spreadsheet as you work through each role.
If I was working with Professional Edition I would make each change and test it as I go so that I can easily unpick a single mistake rather than make all the changes at once and have to try and pinpoint where I “broke” my configuration.
Remember - you can always pull the "Audit Setup Trail" to see what you've changed.
The Last Word: “If this is your first time at Fight Club, you have to fight”
See, Salesforce security is now a bit less scary.
It will always be a little complex just because it is very flexible and there are many moving parts and you might need to read this blog more than once to get it but, hey, I had to watch Fight Club twice to understand that Norton and Pitt were the same character in the end (and I’m willing to bet I’m not the only one!).
Extra Resources: "Lions, and tigers, and bears! Oh, my!"
