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

4. Role Hierarchy – Considerations

Now that we have a good understanding about roles and setting up role hierarchies, let’s take a quick look at some of the considerations while using role hierarchy and some good tips about how to succeed. Setting Up Roles in Organization so, the first consideration is that to simplify user management in organizations with large number of users, enable delegated admin administrators. So this concept of delegated administration we’ll be discussing in detail in the forthcoming sessions. So, delegated administration, to keep it simple, it is basically delegating our work. If the organization is very large with a large number of users and large number of roles, then we can basically provide administrative access to some specific users. But when I say administrative access, it is not like all of the administrative access we can select which all access we want to give to the delegated administrator that very much exists in organizations. That is a very common practice. So in organizations with large number of users and roles, it is a best practice to enable delegated administrators and we can assign some specific roles and subordinate roles to them, so they can manage those roles and users. So this delegated administration is a powerful concept in organizations with a large number of users. And basically we can create up to 500 roles in any organization and every user in the must be assigned role.

Because a role plays a major part in determining what the level of data that will be displayed in their opportunity reports, in their forecast roll ups and the other displays. And whenever a user’s role is changed, the sharing rules for the new role will be applied, right? As simple as that. Because the role determines the sharing rules. So when the user role is modified, the sharing rules also gets modified. So, as per salesforce guidelines, it is advisable to have the number of records owned by a single user to be less than ten k. And if they need to own more than 10,000 number of records, then maybe they are not assigned to any role. That is one option that we can do, otherwise we can place them at the top of the hierarchy. And when an organization is using territory management territory management is also a very extensive concept that we’ll be discussing in later sessions. When an organization is using territory management, forecasts are based on the territory hierarchy and not the role hierarchy. Meaning, if an organization is not using territory management, then forecast will be based on role hierarchy and if it uses, it will be based on the territory hierarchy. So these are some of the key points that we need to have in mind while working with roles.

5. Sharing Rules : Owner-based Sharing Rules

Sharing rules as part of the salesforce security model, we already discussed about profiles, permission sets, Owd and role hierarchy. Now it’s time for us to understand more about sharing rules. And as we already know, sharing rules also provide a record level access in salesforce. Based on this pictorial representation, which we already discussed before. This is basically a representation of how we can open up access in salesforce. So it starts with Owd, which provides the most restrictive access, record level access, which can still more be opened up by role hierarchy, which can still more be opened up by sharing rules. So basically, sharing rules comes into picture when we want to share records to a group of users. So when we say like sharing records with a group of users, we have to understand how it works and based on which criteria, which factors it works. We can broadly divide sharing rules in these five different categories owner based sharing rules, criteria based sharing rules, manual sharing manual, user record sharing, and finally, Apex managed sharing.

These are the five different methods of sharing records with another group of users. We’ll be discussing about the first four types of sharing rules in this course. However, Apex managed Sharing we wouldn’t be discussing as part of this course because it is more related to Apex. But it is always good to know that there is another type of sharing which also exists via Apex. So, coming to the first one, that is owner based sharing rules, in this video we’ll learn about what’s owner based sharing rules and how do we implement it salesforce. So sharing rules, as I already mentioned, they are basically used to open up the record level axis based on roles, roles and subordinates, or based upon certain criteria. And sharing rules comes into picture when Owd is either private or public read only, right? We know that if Owd of a particular object is public read write, what does it mean? It means that we have complete control on others records. We have full access on others records.

When OWOD in itself giving the full access to others records, then there are no real usage of the other methods of sharing that is role hierarchy or sharing rules. No, we don’t need that, right, because Owen itself is giving us the full access. But in scenarios when OWDA is restrictive, say private, wherein we have no access, or public read only, wherein we have only read access to other records, in those scenarios we’ll use sharing rules. Sharing rules basically this owner based and criteria based. So what is the difference between owner based sharing rules and criteria based sharing rules? As the name says, owner based, meaning it is based on the owner, that is a record owner. Criteria based, meaning it is based on the criteria based on the record field values. Say, for example, I want to share records of particular owner to another group of users.

Then it is owner based sharing rules. But criteria based means I want to transfer. I want to share a particular set of records where the country is United States or where the status is set to completed or some different field value, or the probability is a different field value. So in that scenario, then we use criteria based. So when we want to share the records based on the record owner, we go for owner based sharing rules. And when the sharing of the records has to be based on a field value in a record, then we go for criteria based sharing rules. Perfect. So now I think the basic concept is clear. Let’s consider a quick business scenario. I would like to share all the records of users with role customer Support International. With Customer Support United States. All right, just consider two different roles. That’s it. So to have a better understanding and visibility of this requirement, let’s quickly go to a developer. org and go for Roles.

So go to roles and expand all you can see the entire role hierarchy. I haven’t modified anything as such. This is the default role hierarchy that we have in Salesforce Developer Edition because we are more concerned to learn about the techniques here and not about configuring any of these. But in real time, don’t expect these roles. It will be completely based on the company’s role hierarchy. All right. So now the business scenario is you can see in the role hierarchy there are two different roles. That is Customer support international and Customer Support North America. And as you can see in the hierarchy they are at the same level, right? They are not reporting to each other, they are at the same level in the role hierarchy. So consider the scenario owd is private, meaning we cannot see others records, so no one can see others records. As simple as that. And then comes role hierarchy, right? That is how our pictorial representation is. So Owd is private and then comes role hierarchy. For role hierarchy, assume that for that particular object the grant access using Hierarchies is set to true. Perfect. But will that help? In this scenario it owned. Why? Because both the roles are in the same level in the hierarchy, right? The grant access using Hierarchies only work when roles are reporting to each other. Say for example in this scenario, the SVP customer service and Support will automatically get access to all the records owned by these people. But our scenario is different. Our scenario like we are talking about two different roles who are on the same level in the hierarchy. So role hierarchy will not help.

So the next option for us is sharing rules. So sharing rules we are going to use to share some set of records with a group of users. And as we already learnt, it can be based on the owner or it can be based on some criteria. In our scenario to share all records of users with the role as customer support on International. So basically records owned by this particular role has to be shared with another role. So in that scenario we’ll be using owner based sharing rules. This is the scenario that we were just talking about. So the scenario is the Owd is private and we have two users. Here in real time we’ll have the N number of users, but in Developer Edition we know that we can have only two users. So we have two users and for one of the user the profile is system administrator because definitely we need to have a system administrator and we cannot update the profile of this user. So let it be as a system administrator and this user’s role is Customer Support International. User two profile is a custom profile and a role is Customer Support United States. .

All right, so this is our scenario. So in this scenario as the Owd is private, we can see each other’s record. But this is an exception. System administrator is definitely not the best profile to consider while testing or while doing POCs because system administrator basically has access to every single thing in salesforce. However, we have no other option because one of the user is a system admin. But this scenario would be even more clear if it had been a different profile. However, we can definitely learn sharing rules with the scenario itself. Okay? And now as the Owd of opportunity is private, it means that all records owned by this user will not be accessible by user two, right? As simple as that. We know that. So let’s go quickly check that out. I’m in the Owd settings and I have set the Owd of opportunity to private. All right, this is the scenario that we have created and we have two users. One is system administrator, the other is a custom profile and update the role of the system administrator to the Customer support International and update the role of this user to the Customer Support United States. Now, what we are going to do is all the records, this is generally the primary user that I use. So all the records created in the is basically owned by the first user.

But of course you can create records based on this user as well. So, what I’m going to do is I’m going to log in as user two and I’m going to see if I am able to see any records owned by user one. Obviously I shouldn’t be because Owd is set to private. However, let’s quickly check it out. I have now logged in as the second user and I am in opportunities. I go for all opportunities. I do not see any opportunities. Why? Because all the opportunities that is there in the system is owned by user one. I can create new opportunities which I would be able to see. However, I am not able to see others opportunities because the Owd is set to private. So this is our requirement and this is how the scenario is. So now to solve this requirement, what do we do? We go for owner based sharing rules. So how are we going to define our sharing rules? We are going to define our sharing rules in such a way that share all the records owned by one particular role to another role.

And here we are going to say that share all the opportunities owned by this particular role customer Support International to this particular role customer Support United States. So once we define that sharing rule, once we configure that sharing rule, user two should be able to access those opportunities. Let’s quickly try that out in salesforce go for sharing settings and here you can see the Owd settings and then you see all the sharing rules. You see all the sharing rules defined for the standard objects and then you see the sharing rules defined for the custom objects here. And now in this scenario we are going to set up sharing rules for the opportunity object. So go for opportunity sharing rules and hit new. Now we are going to define a sharing rule sharing rule as I told you, it can be based on the record owner or it can be based on criteria.

Now it will be based on the record owner. So let’s fill in the details first give an appropriate label, give a rule name and also give a meaningful description. Choose the rule type to be record owner. And here what we are going to do. We are going to share based on the role that is a customer support international to Customer support North America. So this is what we are going to do. And you can also see here that we have other options of sharing with the public groups or sharing with roles and subordinates. Basically all the subordinates under that particular role will also get access and then we can choose what level of access basically we want to give the users and let me say read, write and then let’s share the sharing rules. Perfect.

Now we have created our sharing rule for opportunities. Now what we are going to do is now we are going to log in as the user two and then we are going to see if we are able to access the records. I have logged in as user two. Now we are in the opportunities tab and then I’m hitting Go. We basically see all the opportunities. So this is how sharing rules work. Sharing rules comes into picture when we want to further expand the access from Owd and role hierarchy and we can do that based on the record owner or the criteria. In this video we learned about record owner and in the next video we’ll see how do we we do that by using criteria based sharing rules.

6. Sharing Rules : Criteria-based Sharing Rules

In the previous lecture we already discussed about sharing rules. What are sharing rules? In which scenario we use a sharing rules, what are the different types of sharing rules and all these among that we discussed in detail about the ownerbased sharing rules. Now let’s study about the other type of sharing rule, that is the criteriabased sharing rules. Criteria based sharing Rules as the name says, this sharing rule is configured based on some criteria. So how do we build that criteria? The criteria is built based on the field value of records because we very well know that sharing rules are used for giving record level access. So based on the field values of the records, we would be configuring this criteria based sharing rules for this to understand this criteria based sharing rule, I’ve considered a business scenario wherein we have leads and we need to share all the leads with country as United States of America with a group of people that is DNA sales reps.

So this is our business scenario. So how do we do that? So when we have such a business scenario, first we need to understand what the current configuration is in our system. Here we are talking about leads and when we check the Owd of leads it is private meaning we cannot access other leads, leads owned by other owners basically. And here we have two users and now we want to share all USA leads with NA sales reps. So how we are basically going to work this out is we’ll be creating a public group like ena sales reps and let’s assign user to to the public group. Once done, we’ll be creating a sharing rule and we’ll share the USA leads with this particular public group. This is how overall we’ll be configuring the sharing rules. So before we go ahead and create our sharing rule, let’s check the existing scenario in our salesforce. org I have logged in as user two and let me go for leads. Go for all leads.

We are not seeing any leads as such. Why? Because the Owd of leads is private so basically we will not be able to see others records. This user two does not own any leads of his own. So basically there are no leads out there as simple as that.

So after we create that sharing rule, user two should have access to all USA leads. So as part of that, let’s first create a public group. Let me log in as the original user, I have logged in as user one and I have also created a public group. We already know what a public group is. How to create public groups, how to use public groups we have discussed in detail in our basic admin course so let me not go into all those have already created a public group and there is only one user in my public group that is user too. So now this public group is created. We have added all the users. But for our requirement as such in real time, what we’ll do is we’ll be creating a public group NA sales reps and we’ll be adding all the NA sales reps in this public group who all needs access to the US leads.

But here we have only two users so I’ve just added user two. So now let’s create a sharing rule. So for creating a sharing rule, we know we’ll be creating a lead a sharing rule. So go for lead sharing rules. Fill in the details here and here. Choose the rule type as based on criteria. We are basically creating a criteriabased sharing rule and our criteria is based on company sorry country. So look for Country USA and share it with a public group. Choose our public group NA sales rep and also choose the level of access that you want to give the NA sales reps. Perfect. So our sharing rule is now created. Yeah, it is in progress and once it is done you will be getting an email about the completion.

Once the sharing rule is successfully created, you also get an email notification and once it is configured for testing purpose, what I’ve done is I’ve logged in as user two, go for leads, all open leads, hit go and you should be able to see all the leads with country as USA. So this is called as criteria based sharing rules. Sharing rules which are created based on some criteria as I already mentioned. This is this criteriabased Sharing rules is one of the very effective tool that we use in real time with different scenarios and different objects. We use them very effectively to better have access to records.