Salesforce Admin ADM-211 – Security and Access : Record Level Access Part 3

10. Manager Groups

Manager groups and manager subordinate groups as part of the salesforce security model. We already discussed about object level access in that we understood about profiles, permission sets. And then we moved on to the record level access wherein we discussed about Owd role hierarchy sharing, rules, manual sharing, user record sharing. So now let’s jump on on to the next method of record level access in salesforce that is using manager groups. Manager groups, as the name says manager groups. It means basically a group of managers. As simple as that. So say for example, I say my manager group. So who all will be there in my manager group? In my manager group I’ll have my direct manager and his manager, and then his manager, and then his manager all the way to the top of the hierarchy. So the group of my direct and indirect managers will form in the manager group for me.

So that is called as manager group. But when we talk about this manager group, we have to be clear about one thing. This manager hierarchy that we are talking about is not the role hierarchy that we have in salesforce. We already discussed about role hierarchy and we know what our roles and what is role hierarchy, right? We know there are different roles set up in an organization. And basically we can control the record level axis using this role hierarchy.

We can use role hierarchy to further more expand the axis. And by default, whoever who is there higher in the hierarchy can basically access records of those who are lower to them in the hierarchy. All that we know, but that is a role hierarchy. And in manager groups what we are talking about is completely different. It is manager hierarchy meaning every user is defined a manager. And where do we define that? We define that in the user detail page. So a manager is tagged to every user.

So I’ll have a manager and my manager will have another manager and it keeps on going on, right? So that is called as manager hierarchy. In our salesforce. org we very much know that this manager detail is available in the user detail page. So when you go for any user to the detail page, you will be able to see the manager details. So in this scenario in developer. org we know we have only two users. One is the system admin user, the other is a different user. So I am user one, basically the system admin user and I have tagged the user two as my manager. Like this, every user will have a manager defined and that forms the manager hierarchy. So now yes, we know what’s a manager hierarchy. Now we have to understand when this manager hierarchy actually comes into picture, when do we actually use manager hierarchy? We know that in salesforce we use Owd and role hierarchy for basically controlling the record level access.

And generally for the standard objects, the grant access using Hierarchies is a by default check. And for the custom objects we have control on whether to grant access using Hierarchies or not. But in some cases we do not want to grant access through Hierarchies. The best example that we can quote is maybe say, employees performance records, the appraisal annual apprisal records. We do not want all the people who are higher in the hierarchy to basically view our performance records because those are not business related information, right? So it should not be accessed by all the people who are higher in the hierarchy. So in those scenarios, organizations want to restrict the level of those particular records. So in that scenario, basically the Owd will be set to private so that not all the other users get access to data and the grant access using Hierarchies would be disabled so that people wouldn’t get automatic access because of the role hierarchy.

So in this scenario, basically the managers, they do our appraisals, they do their prizes for their team. And his manager, he does the appraisal for his team like it goes on. So generally these appraisal records should be shared with the manager groups. So manager group means my manager, his manager and it goes on like that. So in those scenarios where we want to give access to manager groups, we then use this manager group’s functionality. This is a pictorial representation of the manager hierarchy. Consider these four users and these two users report to this user and these two users report to this user. This is pretty self explanatory.

Say for example, we are this user one. So my manager is user two, user two’s, manager is user three, user three’s, manager is user four. So now the business scenario is such that all the appraisal records should be accessed by their own manager groups. So my appraisal records should be accessed to buy two, three and four. And if this person, then again it is two, three and four. And if this person, then it should be three and four. Basically the the manager groups should be able to access the records. So how do we enable this functionality in salesforce? In salesforce we have a functionality called as manager groups using which we can make this happen. Before we enable the manager groups functionality, I have basically done the basic data setup. For that I’ve created a custom object and I’ve named it a performance appraisal. And in that custom object I’ve created one single record. And now I have done this as user one. Basically this user, all right, I’ve created this record as user one and the Owd of that object is set to private and the role hierarchy, I have disabled it. Meaning my manager, that is user two, wouldn’t be able to access that record, right?

We basically know that because in salesforce automatic access to records comes only through role hierarchy, right? It doesn’t come through manager hierarchy just because user two is my manager, he doesn’t get automatic access to my records. So now that Manager Groups is not enabled, what we are going to do is let’s quickly log in as my manager, that is user two, and check if he is able to access the record. Now I have logged in as user two, basically my manager and I’m in the performance appraisal object and we see no records as such here. Perfect.

So the data setup is done. So what is that we have done till now? We have created a custom object. We have basically logged in as user one and then created a custom object. We created a record as user one. All right, this user. And we should also note the security settings of that object. The Owd is set to private the grant access using role hierarchy that is disabled and also for Manager Groups to work properly. Setting up the manager hierarchy is also very, very important, right?

Because the whole functionality works based on the manager hierarchy. So ensure that all the users in your organization are appropriately mapped to their managers. So once we are also done with this manager hierarchy setup, now we are going to enable the functionality. For enabling the functionality, login as system administrator go to sharing settings. We are already very familiar with this regarding the Owd settings.

And then comes the sharing rules and all these. So here click the edit button and there you should be able to see this Manager Groups option. And now that I have already enabled it in My, you see it’s to be enabled. But then if you have not done that, it should be by default it is disabled. So enable this. But do remember one thing. Manager Groups, once enabled, cannot be disabled, as you see here. And if you want to disable Manager Groups functionality, then you have to contact salesforce support because you cannot do it yourself. So have that in mind. Enable manager groups and click save. Perfect. So now Manager Group is enabled for this. All right, we see that here. So now that Manager Group’s functionality is enabled, do all my direct and indirect managers, do they get access to my records? No, definitely not. The function is enabled.

Yes, but then you have to either share the records using sharing rules or manual sharing. Only then the Manager Groups will be able to access the records. And in our case it is the performance appraisal records. So it is a custom object. So go for performance appraisal sharing rules. Hit the new button. Now that we are going to create a new sharing rule, fill in the details I’ve given the label as share with Manager Groups and also give a more meaningful description. And let’s choose based on criteria. What I’m going to say is the owner ID should be equal to user one. So this is the salesforce ID of that particular user, that is user one.

So I’ve given that select the users to share with. So to which users? Basically we are sharing this data. Now you can see manager groups and manager subordinate groups appear here. If you recollect the previous video wherein we were creating sharing rules, these options weren’t available. Why? Because Manager Group functionality wasn’t enabled then. Now that we have enabled Manager Groups, we get this option out here. All right, so choose manager groups. And I’m saying my manager groups. So my Manager Group would include my direct manager, managers manager and so on. And the level of access, say for example read, write. Okay, so now that we have created a sharing rule perfectly, now it’s time for us to log in as my manager and see if user two is able to access the performance appraisal record. I have logged in as user two, basically my manager, and now I’m able to see the performance appraisal record. Why? Because we have granted access using Manager Groups.

And as you can see one, just enabling that functionality will not give any automatic access. Enabling the functionality will just give us an option to create a sharing rule using that option. And once you enable it, if that Manager Groups and manages subordinate groups, if those options does not appear in the drop down, just wait for a couple of minutes, relax with a cup of coffee, and by the time you come back, those options should be there. Well, now that we have a good understanding about this Manager Groups and as I already mentioned, we only have two users in our salesforce. org. So we are only able to demonstrate number one and user two. However, in real time when we have more number of users, we will be able to use the same functionality for user three, user four or not.

And now we enabled our Manager Groups functionality using a sharing rule. So sharing rule is basically giving automatic access, right? Once we create a sharing rule, what happens? All the existing performance appraisal records that is owned by user one, it is automatically access granted to the Manager Groups and also it also applies for the future records, right? That is one way of using the Manager Groups. The other way of using Manager Groups is through a manual sharing. We know that we will have a sharing button. So using that button we can also explicitly go and share a record with a Manager Group. I am now logged in as user one and this is my performance appraisal record. So if I want to share my record with a Manager group, then also I can do that. Here we see the manager groups option. So what is the difference? Sharing rules are basically automated. We very well know manual sharing is manually sharing the record.

So once a Manager Group functionality is enabled, either we can use sharing rules to share the records, or we can manually share every single record to a manager group. So that is also possible. Similar to this manager groups functionality, there is also another related functionality which is called as manager subordinate groups. As the name says subordinates. So when we say that the manager subordinate groups of user three, it would include one, two and three. So the manager subordinate group of this particular user would be all these users and manager subordinate group of this user would be all the users. So subordinate group would basically include that user and all the users reporting to him. And this is also again based on the manager hierarchy and not the role hierarchy. So we should understand the difference between manager group and manager subordinate group. Manager group means my direct manager and all the managers.

So basically my direct manager and the indirect managers and manager subordinate group means it includes me and all those users who are reporting to me. And this is based on the manager hierarchy and not the role hierarchy. Once we enable manager groups in sharing settings automatically, we’ll have both these options while creating our sharing rules, all while doing manual sharing. Here you can see both options are available manager group and manager subordinate groups. So just enabling the manager group’s functionality will bring both these options out to us. But however, the users are different. Manager group of user one is different from manager subordinate group of user one and based on which team of users we have to share the record with, we can use manager groups or manager subordinate groups accordingly. So this is the overall concept of manager groups in salesforce. But while we talk about this manager groups, there is one disadvantage here. Basically there is also an idea exchange that is raised for this particular requirement.

If you notice this sharing rule that we created, it is basically based on the ownerid, right? So this owner ID is my owner ID. So it says this is user one and then I’m sharing it with my manager group. So like that, we have to create a sharing rule for every single user, right? There is no option of creating this dynamically. So this is already raised in salesforce ideas and hopefully Salesforce will get a chance to work on that sometime. However, I thought it would be good to point that out as well. But this is the overall concept of manager groups and manager subordinate groups.

11. Standard Report Visibility

Standard report. Visibility. Standard Report Visibility falls under the record level access in Salesforce Security model. All that this feature does is basically for objects where the Owd is set to private. Enabling this feature would expose the standard report types and by doing so, what happens is the viewing user will be able to see other users ‘records as long as the viewing user is about the record owner in the role hierarchy. So this is the functionality of the standard report visibility.

And how do we enable that? Again, go for sharing settings, hit the edit button. There you would see standard report. Visibility checkbox. We already discussed about manual user, record sharing and manager groups. This is for standard report. Visibility. So once you check this checkbox, the viewing user would be able to access other users records as long as he is above the record owner in the role hierarchy, basically exposing the report type whenever the Owd is set to private.

12. Community and Portal User Visibility

Portal and community user visibility. This portal and community user visibility also falls under the category of record level access in salesforce security model. And as the name says, this feature controls the access level of external Portal and community members. So obviously we understand and that this feature is applicable only to those salesforce orgs where Communities and Portals are enabled. In our basic admin course we have already discussed in detail about enabling Portals and Communities and how to configure them.

So let me not redo that. So once it is enabled and configured, then we would have options to control the settings in our Sharing settings page. So once that is enabled in our Sharing settings, if you hit edit under User Visibility settings, you will have two options available. Remember, if Portals and Communities are not enabled then you will not see these options and when they are enabled, then you will be able to see these options out here. So what is this portal user Visibility what is this? Community User Visibility this Portal User Visibility when this checkbox is checked, this option enables Customer portal users to see other users under the same Portal account. As simple as that. The Community User Visibility when this checkbox is checked, this option enables the community members to be seen by all other users in their communities. So this is about this portal? User visibility and community user visibility.

13. Access to Record Types

Access to record types. This access to record types. This concept is the final concept that we are going to discuss in Record Level Access. Record types about what are record types, how do we create record types, how do we use record types in salesforce. org? All these we have discussed in detail in our basic admin course. So here, here I would just like to highlight a couple of points about how record types impact the Record Level axis. As we know, an object can have multiple record types and a Record Type assignment is done for profiles. So every profile will have certain record types assigned to that. Sometimes one, sometimes many. Let’s say for example, Account Object and there are three record types in that account object and consider a profile, say any sales profile and there is a user with that particular profile.

And the Record type assignment is such that of the three record types, only two record types are assigned to that profile. So basically, as a user user, a who has that profile, I would be able to create and edit records using those two record types that are assigned to me. However, the third record type which is not assigned to my profile, I’ll still be able to read those records, do not create or edit. So this is the Record access level that is given by Record types. It is actually a small concept. I thought it would be nice to include it here in the Record Level axis so that we don’t miss out on anything as such.

Now, we have successfully completed all the various types of Record Level access in salesforce. We have completed object level access and we have completed record level access as well. Perfect. Now let’s move on to the third one. That is a field level Access. So let’s talk about the field level security in the upcoming sessions.

14. Why someone is able to see a record?

Now that we have understood about record level access, there’s one important concept that we need to know. We know that if a person has got access to a particular record, it may be through various settings, right? He might have got access through Owd or through role hierarchy or sharing rules criteria. By sharing rules, manual sharing, there are so many different ways by which which your record access is given to a user. So in real time, as a senior admin, many times you might want to troubleshoot some scenarios.

Like you might have cases like I’m not able to see these leads and these leads does not belong to mine or my team, so why am I seeing these leads? So there will be many questions like why am I seeing this record or why am I not seeing this record? So in those scenarios, as a senior admin, we should be able to troubleshoot why this person is seeing this record, what is basically giving him access to this record. So for this in our salesforce. org, consider any object, say for example leads and here, say for example this particular lead record. This is what we are trying to troubleshoot. So here you have the sharing button. So click on the sharing button.

So once you click on the sharing button, you would be able to see like the users who all have access to this record and you can also see the access level. So this being me, I have full access because I am the owner of the record and user two has got rewrite access. And how did user two get rewrite access? Basically because of manual sharing. So by this you can understand why a particular user has got access to this record. You can furthermore expand the list and then here you have this action and you also have the explanation against that.

It will give you like why this particular user has got access. Similarly, you can also do for other users. So this user, he has got access through manual sharing. Using this we can easily troubleshoot why access is given to particular records in salesforce. Though a simple concept, this is actually a very efficient concept that we use in real time. This comes very handy when we are troubleshooting issues. And I thought as a senior admin it would be really nice for us to know and use this feature. So just added this as well.