Record accessibility between Object CRUD/OWD/Manual Sharing/Role Hierarchy

We will discuss Record accessibility considering Object level (Profile Object CRUD) and Record level (OWD/ Role Hierarchy /Manual sharing) access. Trust me, it is very interesting and also straightforward. Let's discuss them in quick words with some simple examples.

1.  Object CRUD

Object CRUD defines the access level given to that particular object and its fields. If object level access is not given then record level access is of no use. For example If object level Edit permission is not provided, then the user can not edit the record even if record level access is provided (ex, through OWD or sharing rules etc.)

At object level, there are 6 object CRUD permissions are available:

1. Read

If Read is not selected, then for that object:

 The user can not view any records. 

The user even could not see the tab(classic/lightning both) for that object.

If the user has created any records(Ex. Rec A) in the past (when he had Create access enabled) but currently Read access is not available then he can not see any records. He can not view ‘Rec A’ as well though he was creator/owner of the record. 

2. Edit:

If ‘Edit’ permission is given then ‘Read’ permission will also get enabled/checked. This is quite obvious, isn't it.

If edit is not given, then the user can not edit any records of that object. 

If the user has created any records(Ex. Rec B) in the past (when he had Create access enabled) but currently Edit access is not available, then the user can not edit any records. He can not edit ‘Rec B’ as well, though he was creator/owner of the record. 

3. View All:

If ‘View All’ permission is given then ‘Read’ permission will also get enabled/checked. 

If ‘View All’ permission is selected then the user can see all the records of that object. 

4. Modify All:

If ‘Modify All’ permission is given then View All, Delete, Edit and Read permissions will also get enabled/checked. 

If ‘Modify All’ permission is selected then, even if OWD is private, user can read, edit and delete all the records for that object.

Note: So if you notice ‘View All’ and ‘Modify All’ permissions, they actually deal with data/record level access as well. But don’t worry, during interviews, discussions we generally say that profile controls the app/obj/… and other system settings while Role controls the data/record level access through Role hierarchy. As in general, we refer to Object CRUD access, while talking about Profile vs Role comparison.

2. Record Level Access:

There are mainly 4 ways of controlling the record level access. They are listed in order of increasing access:

a. Org-wide Defaults Settings:

This setting provides the default minimum access level of records for that object to users (other than record owner). So if this is set to ‘Public Read Only’ then it means all the users will get read access by default, for all the records of that object. 

We use organization-wide sharing settings to lock down our data to the most restrictive level. We use the other provisions (like role hierarchy/sharing rules and manual sharing etc.) to provide additional access. 

Organization-wide defaults are the only way to restrict user access to a record.

OWD defines non record owner’s record level access. Record owner by default has all the access to that record (if profile CRUD permissions are given of course).

b. Role Hierarchy: 

Using Role Hierarchy, the user above in the hierarchy also gets access to records, which his subordinate(s) have. To enable it for a given custom object, go to the ‘Sharing Settings’ and enable the ‘Grant Access Using Hierarchies’ Checkbox for that object. 

For standard objects this setting is not configurable. 

Let's say user A is assigned with Role ‘Manager’ and user B is assigned with role ‘Sales Executive’. Role ‘manager’ is just above the Role ‘Sales Executive’. Then If Role Hierarchy access is granted/enabled for a given object, then user A (Manager) will get all the access to records that user B (Sales Executive) have.  

But if user B is able to see records due to ‘View All’/’Modify All’ permission, then role hierarchy won’t  help in getting these records access to the manager. So Manager gets access to the subordinate's  data where the subordinate is either owner or has access due to other sharing options (Ex. sharing rules etc.). 

c. Sharing Rules:

Using Sharing Rules we can provide additional access to users based on the predefined criterias. 

d. Manual Sharing:

Manual sharing is helpful when users want to share specific records with each other manually. This is helpful when they are working on the same records or for example want to delegate work when going on leaves. 

3. Use cases:

Let's assume we have have 2 users: 

User A (Manager) - Role manager

User B (Sales executive) - Sales Executive under the Manager Role

Manager has just one subordinate ‘Sales Executive’. For this object OWD is Private. 

Now let's take some interesting use cases:

1. Use case A: (Though Sales Executive can not edit records but manager can)

In this use case, Manager will get all the access that his subordinate has. Technically Sales Executive should be able to edit all the records that he owns. As the Record Owner has full access to that record.  But as the sales executive does not have EDIT access at profile level, he can not edit any record. But the Manager will be able to edit records that manager owns and also he can edit the records that the Sales executive has access to. 

2. Use case B: (View only record can not be shared even if you have Edit CRUD access)

In this use case one admin person has shared one record ‘Rec 11’ manually with the Sales Executive. 

Manager : He can edit his own records, he can edit records of Sales Executive as well. He can view but can not edit the shared record ‘Rec 11’. He Can not view/edit records of other users and other records of admin.

Sales Executive: He can View/Edit his own records. He can not edit the shared record ‘Rec 11’ of Admin as it is shared as Read Only. He Can not view/edit records of other users and other records of admin.

3. Use case C: (Though Sales Ex can not edit records but manager can even Manually shared record)

Manager :  Manager can edit his own records, can edit records of Sales Executive and manager can also edit the shared record ‘Rec 12’. Manager can not view/edit other records.

Sales Executive: He can view his own records. He will not be able to edit any record. Even there will not be any EDIT button available on UI to the Sales Executive. 

4. Use case D: (Impact on Modify All on Manager)

Manager :  Manager can edit his own records, can edit Sales executive’s records and can also edit the shared record (Only shared record not other admin records).  Manager can not view/edit other records. Though ‘Modify All’ is selected for Sales Executive. 

Sales Executive : He can edit all his records and all other records. Notice Modify All is selected for the Sales Executive. 

Reference: https://developer.salesforce.com/docs/atlas.en-us.dat.meta/dat/dat_components.htm