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

7. Manual Sharing

Manual sharing as part of the salesforce security model. We’ll be next talking about manual sharing. Manual sharing as we know it falls under record level axis. And as per this pictorial representation, which we have already discussed a couple of times before, manual sharing is basically on the top. Meaning if we are not able to provide access by any of these, then we can use manual sharing. Owd as we know is the most restrictive method of sharing and then comes role hierarchy and then like sharing rules. And now we are talking about manual sharing. In fact, manual sharing is also a kind of sharing. Basically there are five different methods of for sharing records owner based sharing rules, criteria based sharing rules, manual sharing, manual user record sharing and Apex managed sharing. We already discussed in detail about the first two.

Now let’s talk about this manual sharing. Say for example, there is a record opportunity record or a lead record, all right? And we want to share that record with a different user. So what would we do? We would first check like if that is available, that wouldn’t be available because the Owd is either private or public read only, right? If it is private, then absolutely there will be no access for other users. Public read only, meaning it will be only readable and based on the role hierarchy. Also like the access is not given to the other user and there are no defined sharing rules as such to share the records with the other user.

But now that there is one record, then we would like to share it with another user. Can we do that? Yes, we can do that. How we can do that? We can do that by manual sharing. So, manual sharing, as the name says it’s manually. Meaning you have to manually go to the detail page of the record and then share the record with a specific user or a group or a role. So say for example I want to share some ten lead records, what would I do? I would go to the detail page of the ten records and then specifically share that record with the other user.

Meaning I would do that ten times. Why I’m stressing is this unlike the sharing rules, which is automated, because we define a rule and all the records that satisfies the rule will automatically be shared with a set of users, right? It is automated. And even after creating the sharing rule, thereafter, if any record that gets created, if that falls in that rule, that will automatically be shared with a set of users. But unlike that, manual sharing is basically a manual process. You have to manually go and share the record. That is called as manual sharing. So when we talk about manual sharing, first we have to understand on which all objects it will be applicable.

As we already know, if Owd is public read write, then there is no much significance for the role hierarchy or the sharing rules or this manual sharing, because Owd itself giving the maximum access to other users. So when Owd is private or public read only, then automatically the Sharing button will be available on those objects. Based on our previous discussion, for creating the criteria based to sharing rules, or for configuring the owner based to sharing rules, we updated the Owd of Leads and also for opportunities to private. So the odibly of Leads is private.

So when I go to a lead record, we are able to see this Sharing button. So, using the Sharing button to share a record is called as Manual Sharing. So the first thing that we need to understand is the Sharing button will not automatically be available on all objects. It will be available only on those objects whose Owd is set to private or public read only. First important point. Second important point. Now that we know on which all objects it will be available, the second point is for which all users it will be available. All right, say for example, the Owd is private for leads. So does it mean that this Sharing button will be available to all the users? Definitely not.

This Sharing button will be available only to those users. Either they have to be the record owner of that particular record, or for system administrators or users above the record owner in the role hierarchy, or users with full access only. For these users, the Sharing button will be available not to all the users. This is also very important. We should know on which all objects it will be available. And we should know which all users it will be available. Who all can access that Sharing button for the record owner, for the system admins, or users above the record owner in the role hierarchy, or users with full access. Only these users will have access to that Sharing button. Only these users will be able to use that Sharing button and share the record with other users. Perfect. So the second point is clear. We now know that which all users have access to the Sharing button.

Now we should know using that button to which all users can I share those records? We should know that the records can be shared with other users roles. Roles and subordinates public groups, manager groups or manager subordinate groups. It is just not for users, it’s for also the other group of people. And like any other button, the visibility of this button also can be controlled with the help of page layouts. And also please note, this is a classic only feature. This feature is not available in Salesforce Lightning. Perfect. Now that we have a good understanding of this manual sharing, let’s quickly go to the UI and try to share a record. So we are in leads. The Owd of this object is private.

So that’s the reason I’m able to see the sharing button. When I go to all leads, I’m able to see all the leads. With country as USA, we have only two users, user one and user two, to already learn about the criteria based sharing rules. We created a criteria based sharing rule wherein we shared all the USA leads to a different group of people and in that group user two is there. So user two has access to all USA leads and user two does not have access to this Taiwan lead and the Japan lead. So user two does not have access to these two records. So now what I’m going to do is I am going to use manual sharing and I’m going to share this single record with user two. So for that, what I’m going to do is hit the sharing button. And now you can see to be all users, it is available, it is just available only to me. All right. And now hit Add.

And here you can see it can be shared with public groups roles roles and subordinates or with other users. We haven’t created any manager groups or manager subordinate groups, which we’ll be doing in the later part of the course. However, right now there are no groups as such the manager groups assets, so we are not able to see that. But in case if we have, we would be able to see those options as well. But right now let me choose users and I’m choosing user two.

So I’m manually sharing this single lead with user two. And you can also decide on the level of access that we need to give the other user. Perfect. So now what we have done is we have manually shared this particular lead with user two. So let’s quickly log in as user two and check if he is able to access it. So now I have logged in as user two. Let me go to leads, all open leads. Now you can see user two has access to all USA leads because we shared the records, USA lead records with user two, while creating our criteria based sharing rule. On top of it, he now has got access to this Taylor lead as well. And how did he get this access? Through manual sharing. So this is called as manual sharing. When we want to share a record manually to another set of users, then we can use manual sharing.

8. Manual User Record Sharing

Manual user record sharing as part of the salesforce security model. We already discussed about the other types of security there’s profiles, permission sets, Owd, role hierarchy sharing rules manual sharing. Now let’s understand what’s manual user record sharing in fact, manual user record sharing also falls under the main category of sharing. We already know that there are different types of sharing. Owner based, criteria based manual sharing. Now we are going to discuss about the last type of sharing. That is manual user record sharing. Before we understand this manual user record sharing, one thing we have to be very clear about.

Manual sharing and manual user record sharing are two different things. We shouldn’t get confused by the naming convention manual sharing meaning when the Owd is set to private or public read only, in that case a sharing button appears on the detailed record and thereby the record owner or whoever is eligible, they can use that sharing button to share that particular record with other users. That is manual sharing, right? But now this manual user record sharing as the name says, this manual user record sharing is only applicable to the user records meaning the records in the user object. So this feature of manual user record sharing is only applicable to the user object. It is not applicable to other objects. We have to be very clear about it. And what can we do using this feature? Manual user record sharing? Basically this feature is used where communities are being used when we want to share our own user record with different user.

So this manual user record sharing we use for sharing our own user record with a different user. And as I mentioned, this is very much used when communities are used in salesforce. org. Now to understand this better, let’s quickly jump into our salesforce. org and have a look at it. So I have logged into my salesforce. org go for manage users, users other than the integration user and the other users, the two users that we can create in developer. org.

So one of the user is of a system admin profile and the other user I have a custom sales profile. So leave off the system admin. Choose the next user, that is user two with a custom sales profile. Log in as user two, the user with a custom sales profile and drill down on that particular record. So basically user two is clicking on his own record. So when you go to that particular user record we are not able to see any sharing button as such, right? This is because manual user record sharing is not enabled. So now what we are going to do is we are going to log in as system administrator, do the necessary changes and we’ll come back and check it out. Now I have logged in as the system administrator to enable or disable this manual user record sharing. Let’s go to the sharing settings, hit edit.

Once you hit on edit you would be able to see these options standard Report, Visibility, manual User Record Sharing and Manager Groups. You can see that manual User Sharing feature is not enabled. Now let me enable that and hit Save. Perfect. Now that Manual User Record Sharing feature is enabled, what I’m going to do is I’m going to log in as user two and I’m going to be able to see whether I’ll be able to see that sharing button or not.

So now I have logged in as user two and this is my record. Click on the user record. Now we see the sharing button, meaning I will be able to share my own user record with different user. So that is the concept of this manual User Record sharing. And here you can add users as we normally do. This is the overall concept of this manual User Record sharing. It applies only to the user object and it is all about sharing our own user record with other users. And this is very commonly used when community is in use.

9. Sharing Rules – Considerations

All right, so now that we have a good understanding about sharing rules, let’s have a quick look about the various considerations we need to note while using sharing rules. We know that sharing rules provide a record level access in salesforce and we know that sharing rules we have five different types owner based, criteria based manual, sharing manual, the record sharing and Apex manage sharing and the sharing rules. Actually, when do we use the sharing rules in? When objects Owd is either private or public read only then we use the sharing rules to further more expand the access for those related object records. So that is how that is when exactly sharing rules comes into picture and that is a basic concept of using sharing rules. And we also know that sharing rules can only open up more access than Owd, but not a restrict access that is already granted by Owd.

And yes, the Owd of the particular object should be private or public read only. Only then we’ll be able to create sharing rules. Okay, this is the case of multiple sharing rules because in an object in real time we create multiple sharing rules. So for some set of records through a sharing rule I have got read only access and through another sharing rule in the same object I have got read write access. Maybe because I am in different public groups, due to some scenarios I have gained different access levels from different sharing rules. So in that scenario, what happens? In that scenario I’ll get the most permissive access level, meaning the maximum access level. So one sharing rule is giving me read write access so I’ll be able to have the read write access on those records. And this is about a related records. So when we get access to some set of records, automatically we are also granted access to its related records. Say for example opportunity sharing rules.

There is an opportunity sharing rule and that opportunity sharing rule is giving me access to the opportunity records. So in that case I also get additional access to its related account. Similar scenario, it happens when we create contact sharing rules, case sharing rules, even in those scenarios we get access to the related account. So that’s what it means when we have access, we also get access to its related records. This year we are very well aware of users in the role hierarchy they automatically get access which users who are lower than the hierarchy gets. Say, for example, there is a person who reports to me and he gets access through a sharing role. So automatically as I am above him in the role hierarchy, I automatically get access.

And we know that for standard objects the grand access using Hierarchies is automatically selected and for custom objects the checkbox is editable. So if that option is selected, then automatically the person being lower in the role hierarchy if he gets access, then automatically I get access. And once we create a sharing rule and once it is done saving, when you go edit the sharing rule in that scenario we can’t change the share with field settings. We can quickly see that in our developer. org we have already created a lead sharing rule and now that I’m editing the rule and now you can see that this share with option is not editable. So you cannot edit this particular field value. You can actually add or remove users from that this particular group yna sales reps.

But as such, this share with value is not editable. These are actually minute things, but important things that a senior admin has to know. And once a sharing rule is created, it automatically applies to all the existing records of that object and it also applies to all the newly created records and it applies both to active and inactive users. And when we change the access level for a sharing rule, then all the existing records are automatically updated. Meaning this is a sharing rule we were talking about. And here we have the access level. And once a sharing rule is created and then we can go and edit the sharing rule at a later point of time there this access level is editable, so currently it is read write. If I change it to read only, then the related access for those records also gets changed.

And what happens when we delete a sharing rule? Sharing rules can be deleted as well, right? So when we delete a sharing rule, the sharing access created by that rule is also automatically removed. Say for example there is a sharing rule that gave me access to some 100 account records and if that sharing rule is deleted, then automatically I lose access to all those 100 account records. Yeah, this is a very important concept that is a sharing reevaluation. So what is this sharing reevaluation is? It is a little different from what we were talking about. We were talking about like what happens when a sharing rule is created and what happens when a sharing rule is edited, right? And what is the impact of the records, what is the level of access that user gets and all these but now what we are talking about is sharing reevaluation, meaning a sharing rule gets reevaluated. So under what scenarios? A sharing rule gets reevaluated whenever we modify users in a public group or a role or territory.

In all those scenarios sharing rules gets reevaluated. Like for example for Owd, we have already seen when we change the Owd setting of a particular object then we see that reevaluation is happening in this, right? Similarly for sharing rules also reevaluation happens, this reevaluation happens when one of these changes takes place and how long this reevaluation takes. Basically this recalculation of this sharing rules can take anywhere between 1 minute to several hours. So that depends on basically the number of users in the basically the customizations that is there in the and also the number of records that is there in your salesforce. org. Based on all these, the revaluation time, it varies. And while this recalculation runs in the background, at that time we will not be able to create any new sharing rules or will not be able to modify any security settings as such, like updating the Owd or other security settings. And while we understand about this sharing reevaluation, we should also know about one important thing that is called as a differ sharing calculations. So what is this differ sharing calculations? Meaning like in real time when we have large number of records, say for example the lead object, consider the lead object like you have like 3 million or 4 million lead records and then we make a change or we create a rule that is impacting the lead records, that is impacting a large number of lead records. In that scenario, definitely this reevaluation is going to take a really long time.

So in that scenario, what we can do is we have this option of differ sharing calculations. Meaning which can temporarily suspend the automatic recalculations that take place. And how we can do that, we can do that by raising a support ticket. And basically this differ sharing calculations is a limited feature and salesforce support can definitely help you enable that.

And once you have that feature enabled then you can temporarily suspend these automatic recalculations and plan those recalculations to happen during a maintenance phase so that will have very less impact on the users. These options though we do not use in every project, though we do not use in every, it is definitely a good to know for senior admins that one such option do exist. Perfect, moving on. And basically this is about transferring records from one user to another. So in that scenario also sharing rules are reevaluated and in the reevaluated which can add access also which can remove access also.

This recalculation we know that it automatically happens and we know, we discussed about in which all scenarios it automatically happens, but other than that we can also manually force this reevaluation to take place. How we can do is that in our salesforce. org in the sharing rules we should have a button which is called as a recalculate. So when we hit this button automatically the sharing rules gets recalculated. But this button we should use only in case of troubleshooting or when the sharing rule is not showing the expected behavior in those scenarios we use this recalculate button. So these are some of the important considerations that we need to note while using sharing rules.