Data Security within Salesforce Org - Profiles, Roles & OWD: A beginners guide

Salesforce is a transactional system which means the data that resides within Salesforce is supposed to be accessed by users regularly in form of some sort of transaction. Like any transactional system, Salesforce also has few features to hide or selectively hide few piece of information from selected users or if you look at it from the other side, show or selectively show few piece of information to selected group of users. Getting confused already? Hang on!

Lets cover this complex topic with an example. Think about a Time Tracker Application of a company. Contractors enter their daily worked hours into the system and their manager approves them. Towards the end of the month, the finance team accesses these approved hours and process the payments. Simple stuff.

The core object of such a system would be Daily Hours Entry[DHE]. Key fields would be Date worked(Date), Total Hours(Integer), Owner(User). The users(i.e. Contractors) will have their manager also assigned to them using Role Hierarchy.

Now before we design the sharing security of our Time Tracker Application, lets see what all tools we have and what wonders they can do for us.

The Salesforce sharing model is a matrix. One side of the matrix is Object Level Access[OLA] - the settings which defines what all objects a user will have access to and the type of access[Create, Read, Edit or Delete]. The other side of the matrix is Record Level Access[RLA] - the settings which defines, if you have access to an object from OLA**, which all records of that object would you be able to access. Like if that object has 100 records, you might not want a user to see all 100 of them but only his own 10 of them.

** The bold line is important, if a user do not have any access on an object using OLA, RLA is irrelevant to that user.

The OLA tools:

1. Profile - Profile is the basic OLA tool we have. Every user will have one Profile assigned to them. We will define the access for objects, fields of those objects, Record Types, Page Layouts and some more advanced stuff which we can park for the time being. First 2 are important for now. Objects and Field of those objects.

2. Permission Set - This is another OLA tool and this works on top of what you define in Profile for a user. Permission Set will also have same options like what we have in profiles - Object access, field access. Then whats the need of Permission Set when we have Profile, right? Permission Set is used for expanding the access level we have set in profiles for a set of users. Example - say 2 users has same profile with read access on Account. One of them temporarily needs Edit access on Account for some reason. We would not create a separate profile for this short purpose, instead we will provide the user a permission set with Edit access on Account. So in combination of the existing profile[read] and this permission set[edit], the user will have read and Edit access on Account. And when the purpose is fullfilled, we will remove the permission set from the user, so he is back at read access on Account. You see how permission set was expanding the original access of the user?

Note: Permission Set can only expand the existing access, it can not shrink the original access given to a user by profile.

The RLA tools:

1. Org-Wide Defaults[OWD]: From the RLA perspective, OWD is the basic access defined for an org[Note: for an org, not for a user]. Anything that you define at OWD, like the name suggests, its applied Org-Wide. So here we define how records should be visible to users in our org. For each object, we have 4 options here

a. private: if this option is selected, the records of this object would be private in nature and the owner[usually the creator] of any record is the only person who can access the record. Nobody else can see the record.*

b. public read only: this option tells the org that records of this object can be seen by all users of the org but they cannot edit/delete it. Only the owner can edit/delete it.

c. public read/write: this is the most permissive access level. If this is selected, any user of the org can see, edit, delete it. But wait, it doesnt mean its a open field for grazing, users would still need OLA on that object, without that RLA is useless for them, remember?

d. controlled by parent: This is the fourth option and it's only available for those objects which are the detail[child] in one master-detail relationship. So the child object inherits the OWD setting of its parent object. If a user has access on a record of the parent object, it has access to the child records of that parent records. More on this sometime later.

2. Sharing Rules: This is the last RLA tool for us. Sharing rules works on top of OWD. Same like Profile-Permission Set, it can only expand the access, can not shirnk the original access. Here we can share selective records of an object to a group of users with Read Only or Read/Write access.

Okay, now that we have known our tools, lets use them to design our sharing model for Time Tracker Application.

TT Application will have below group of users:

1. Contractor - They are the people who will log their hours in Daily Hours Entry object. So they get Create, Read, Edit, Delete access on DHE object using Profile.

2. Contractor Manager - They are the people who will approve the DHE records created by their subordinates - they need Read & Edit access only on DHE using Profile.

3. Executive Leadership - They are basicaly Contractor Managers but since they also hold Executive level positions, they need visibility over the full system. As they play a Contractor Manager role in the system, their original profile is Contractor Manager. So satisfy their need of full visibility, we shall use a permission set for these handful of people. This permission set will have View All permission on DHE.

4. Finance Team - These people usually don't need any access on DHE because their work on DHE is limited to month end only. Lets say their work area is another part of the application, for which they have their own Finance Team profile with no access on DHE. A permission Set[Finance MonthEndAccess] with View All access on DHE will be assigned to these users only during month end. So we will expand their access to DHE keeping their original access on the system intact.

5. System Admins - They are the back end guys who keeps the application running and provides any technical support users need. So they need a full access of the system, so Read, Create, Edit, Delete, View All, Modify All access on DHE object. Supermans of this system!

So well and good. All done! Users should be able to get onto log their hours. But wait! We have only decided OLA, what about RLA? We don't want Contractor John to see and edit Contractor Smith's Daily Hours Entry records. We have hide these records, so that only the person who created them should see them.

So we set OWD for DHE to private. But again, we would also have to let the Managers see the records in order to approve them, right? Here is another tool we didn't mention earlier, do you see the little checkbox next to the OWD selection drop-down? Grant Access Using Hierarchies. Just tick this checkbox, this will allow the private records to be visible to the owner's manager. So this little checkbox will take care of our this crucial need.

So now, our records are secured and shared with the creator and his/her manager only. The managers[having profile Contractor Manager], can only read and edit the record based on his profile access. 

Lets put this on a matrix. Click to enlarge the image.

What a beautiful world!

I have tried to cover only the basic of Sharing Settings. Needless to say this is just the tip of the iceberg. However, this is the most crucial part to understand for beginners. Once the co-working of OLA and RLA is understood, rest of the Data Security journey will be effortless.