Salesforce Certified Platform App Builder – 4 – Security Part 4

10. Sharing Settings and Granting Access Using Hierarchies

Okay, guys, now we’re going to set up sharing settings and then also get into granting access using Hierarchies. So first off, I want to remind you where we left off and that’s with the end user of Jim Doe, which I’m logged in as Jim right now, he has that custom marketing profile and so he only has access to these two productions, the Andy Griffith Show and she Years. And so I’m going to log out as him and show you how to set up a sharing setting so that we can then give him access to other productions. So now if I log out as Gym, then I log back in as myself and I’m going to click on the all tabs button and click on productions. So now if I go to All Productions for myself as a system administrator, I can see all these records here.

So the two that Jim cannot see are gone with the wind and the wizard of Oz. Both of these productions were created in the year 1939. So I’m going to create a sharing setting to share these records for any productions that were created in the year 1939. It’s a really specific rule that I’m going to set up in order to demonstrate this, because these two records happen to have a production year of 1939. And so before I do so, I need to fill those back in. I’m adjusting the Gun with the Wind record back to 1939. And if I go back to the list of all productions, the wizard of Oz as well has a year of 1939. Now we had this earlier in this course and then deleted those records and then restored them as well. So you see now that I’ve changed the year to 1939 in the field history tracking on this production record. So now these two records do have the year of 1939. And so let’s go into setup and search for the word sharing in order to bring up the sharing settings.

And that is where you set up the sharing rules. And we were in this in the previous lecture. Here we see the organization wide defaults. And for production we have the orgwide default set to private. So that means that only the owner can see the records that they own, but other people cannot see them. And so a way that we can begin to open up access to productions, though, is to create a sharing setting. So a way that we can open up production records is through creating the sharing rule. And so if I scroll down here below, you see that there’s these different sharing rules that we can set. And that would be for these standard objects here. First off, there’s lead and Account and opportunity. But if you keep scrolling, you’ll get into your sharing rules for your custom objects. And so scrolling down, we see now the production sharing rules and there’s none. If I click new to create a new sharing rule, I can begin the process of creating a production sharing rule.

So I need to give the sharing rule a label. In a real world situation, you normally wouldn’t be so specific to just share records for productions that were created in only the year 1939. But for sake of an example of showing you specifically how this works, I will just be very specific and just allow the productions that were created in the year 1939 to be shared with other profiles. So I’m going to name this 1939 and then tab through and it’s added an X here to this rule name. And the reason it’s added in an X is because the name must begin with the letter and it can only use alpha numeric characters and underscores in the role name and then the name cannot end with an underscore, have two consecutive underscores and so it’s added the X because it can’t start with a numeric value. And so step two of creating the sharing rule is saying that we can create a rule type based on the record owner or based on criteria.

And so we want to select based on criteria. And try and follow along with this in your own here and consider this a practice activity, if you would. And we’re going to select then the criteria in step three of a field and we’re going to select the year on the production record. So when the year equals 1939, we’re going to share this record and we can share that with either public groups or roles or roles and subordinates. I believe I misspoke earlier saying that we could open up these records with other profiles. But one thing you need to note is that you can share things through sharing settings here, sharing rules with either public groups or roles and roles and subordinates. And so if we select public groups we’ll be able to see if we have any public groups already created and there is one and it’s all internal users. And so that means that we can share this record with all other internal users.

So that would include Jim Dose. I’m going to select that for my example, but I could use the role hierarchy or roles in subordinates and select a role in the role hierarchy. And so I believe that Jim had the marketing team role in the role hierarchy, so I could select that if I wanted to. But instead I’m just going to go with public groups and select all internal users because I want to be sure that Jim gets access opened up to him in this example. And so the access level, I’m going to make this just read only instead of read write. So that means that he’ll be able to view these records but he won’t be able to do any edits. So I’m going to click save in order to create this new sharing rule for the production records. And so this prompt appears saying the recalculation of sharing access will continue in the background. You will receive an email notification upon completion. Do you want to continue? So I’m going to click OK. And so now it updates the records and you get this notice that there is a sharing operation that’s being initiated. You will receive an email once the calculations have been refigured in your salesforce. org and then that will tell you that the access has been updated. But if I scroll down, we should be able to see the sharing rule for productions that I just created. I want to show you what that looks like. Here’s the further notice notification down below that they were referring to and it’s saying that it’s in progress and the initiating user will receive an email when each operation finishes.

So I’m going to click Refresh on my browser and see if that notice goes away, which will also tell me that the recalculations are done. And so now we have this sharing rule in place. So now the big test will be to log in as Jim Doe again and see if he can now see the productions that were created in 1939 because as you recall, he wasn’t able to previously. So I’ve gone to his user record for Jim Doe and I’m going to click the login button to log in as Jim. And so now if I click the all tabs plus sign here and select Productions. And so now if I click Go, I can now see Gone with the Wind and wizard of Oz because the sharing rule that we just created has opened up access to Jim. And so now if I log back out as Jim and log back in as myself as an admin, I do need to cover granting access using Hierarchies. And so if we go back to the sharing settings by searching for the word Sharing in the setup menu and clicking on Sharing Settings in the menu on the left, you notice we have this column here for granting access using Hierarchies.

And so granting access using Hierarchies is a pretty complex subject and we’re not going to be able to go into all the depths of this in this lecture. But I do encourage you to click on this organization wide defaults help and then look for more details on the grant access using Hierarchies designation for further reading. But I do want to show you that if we scroll back down to the production object, which if you recall, we’ve set that to Private, but we do have grant access using Hierarchies checked. And so if I were to edit this, we can uncheck this in order to not grant access using Hierarchies. So if I click Save, it says that an organization wide default update has been initiated by me and you can’t submit any changes prior to the completion of this operation.

And I’ll receive an email once it’s complete. I’m going to refresh to make sure that everything is done now. And so now we scroll down to production and it is set to Private. But you notice that the grant access using Hierarchies is now unchecked. So what that means just at a high level is if I were to go into the role hierarchy by searching for the roles in the setup menu and then selecting roles under Manage Users and then click Set up Roles to view your role hierarchy. And I’ve expanded all. You can collapse all and expand all and so as an administrator, I have the ability to see all records. So there’s really no good way to demonstrate this in a free developer account because there’s just two user accounts. One is the Admin or system administrator account, which is yourself. The other is the new user that you created, which is Jim Doe, which is an HR intern here in this role hierarchy. And so if I click on the assign link here, for instance, you can see that Jim Doe is in this role in the role hierarchy.

So I’m going to cancel out of that. But what granting access using role hierarchy means at a high level is that anyone that sits higher up in the role hierarchy will have access to anyone’s records beneath them if access has been granted in the role hierarchy. So for instance, this SVP of Human Resources, let’s click Assign here and let’s use the security user and put them in that role in the role hierarchy and click Save. So in this instance, we’ve got a security user in this role in the role hierarchy above Jim Doe. And unfortunately, I’m not able to log in as the security user. But for sake of an example, just to understand the concept, we’ve got someone in this role and it could be yourself if you weren’t a system administrator. And then you’ve got your HR intern that owns a couple of records. Now remember that the Productions object is set to Private and we have not granted access using the role hierarchy. So with a private organization wide default and also the setting of not granting access using the role hierarchy, then only the HR intern user of Jim Doe would be able to see those records that he owns. If we grant access using the role hierarchy, then those would roll up to those higher up in the role hierarchy, which would be this SVP of Human Resources and then upwards to the CEO.

So if we go back to the sharing settings and as we round this lecture out discussing the granting access using Hierarchies, and just as a reminder, we’ve got this set to private and then also we are not granting access using the role Hierarchies. I want to go ahead and set that back to Public Read, Write and granting access back using the role Hierarchies, I’m going to click Edit and then I’m going to select Public Read, Write and then checking once again to grant access using the role hierarchy and click Save. So I do encourage you to review the organization wide defaults help for more details on the granting access using Hierarchies. And I apologize for not being able to demonstrate that further because of the limitations of the two user accounts that are available to us, but we’ve at least explained the concepts behind it and you can explore that further. Now, there’s other ways that we can actually share records, and that’s by manually sharing records in salesforce, which we’ll cover in.

11. Manually Sharing Records

Okay, so another way to share records with other users is through manually sharing records. Now in the previous lecture towards the end, I changed the organization wide defaults to public read write on the production object. And so what I want to do instead is I want to now change this to just public read rather than read write. And I need to do this in order to share production records. And so I’m going to click Edit and go back to the production object. Instead of doing Public read write, I’m going to say public read only. I’m going to click Save and I’m going to click Refresh to know that all the updates are now done in my organization. So now if I go to the Productions tab and let’s go to one of these productions, you see that we have a sharing button here.

And so what a sharing button does is you click on that, it will show you the users that have access to the record and it also explains why. And so right now, I am the only user that has access to Gone with the Wind. And that’s because the organization wide defaults on this object are public read only. But also I am higher up in the role hierarchy than anyone else in my organization. I have full access because I’m the owner. Let’s go to different production such as the Cheers production, which is owned by Jim Doe. And click the Sharing button.

You see that Jim has full access because he is the record owner. I’m going to click Expand list and you see as well that I have access as well as the security user. You can click why? And you can see that I am able to see it because I am an administrator. And then as well, the reason that the security user has access is because Jim Doe is the owner and the security user, their relationship is they’re the manager of the owner. They are higher up in the role hierarchy than Jim Doe. So let’s go back to the wizard of Oz and let’s expand the list there. So I click on Sharing and Expand list and just wanted to clarify that no one else had access to this record because I’m a system administrator and there’s no one above me in the role hierarchy.

And so the way that you can then share a record if we go back to the wizard of Oz record and we verified already through the sharing button that there’s no one else that has access by clicking expand list, if we want to share this record with someone else, we can click the Add button and then we can add other users. I’m going to manually share the wizard of Oz production record with Jim Doe by selecting him. After having selected users from this drop down here, selecting Jim Doe, clicking the arrow to the right to share with Jim Doe.

Now the access level could be read right, because the organization wide defaults for this object are read only. So this is opening up further access level for Jim Doe beyond the organization wide default. So I click Save, and now in the expanded list, we have not only Jim Doe, but also you notice the security user is also being given access because he sits higher up than Jim Doe in the role hierarchy. And so now you can see how to manually share a record with another user and then as well, how to see who has access and why. So just keep in mind the Add button to add additional users and the Expand List button along with or in conjunction with the Y link so you can begin to understand why certain users have access to a record.

It’s very helpful if you’re tasked with trying to develop security around an application and someone’s asking, well, why does this user have the ability to edit these records? I don’t want them to have read only or private or full access. So there’s these different explanations of the access levels as well. And so, as you can tell, as we near the completion of this section, we’ve got one more lecture coming up around to create, read, update, and delete operations, which are known as Crud operations, which we’ll be going into in the next lecture.

12. Create, Read, Update, Delete Operations – aka CRUD

So now we’re going to talk about Create, Read, Update and Delete operations. And this is often referred to as Crud operations or even Object Crud. And that is an acronym taking the first letters of each of those words for Create, Read, Update and Delete. And so if you go to Profiles and Setup we’re going to go to the custom profiles in our order. So I’m clicking on Profiles and set up and I’m going to select the Custom Marketing profile. And so when we talk about object Crud in Salesforce you can access those settings through the Object settings in a specific profile. And the main thing to recall or to remember for the exam specifically is that if you’re dealing with Object specific ability to read, create, Update or delete, you would do that through the Object settings on a specific profile. I’m in the Custom Marketing profile now and so what we refer to as Crud, the Create, Read and then Update is the same as Edit and then Delete.

The main thing to bear in mind is that you can control these settings at the object level. So we’re viewing the settings for all objects in Salesforce for this custom marketing profile. So for example, on the Accounts object, this profile can read, create, Edit and delete account records. And so for example, if we go back to this profile we can see who’s assigned to the profile by clicking the Assigned Users button and we should see Jim Doe here in the list, which we do. Now I’m going to log in as Jim Doe. You notice you got the login link here from this list of those assigned in the marketing profile. I’m going to log in as Jim, I’m going to go to an account and you notice he has the ability to create a new account record and then as well he can come in here, he can also edit and delete an account record.

And so I’m going to log out as Gym now. So I’m going to log back in as myself. Then I’m going to go back to the profile for Jim Doe and I’m going to take away some of his access. If I go back to setup and the setup home. And then under my most recently used items I’ve got the Custom Marketing profile, I’m going to click on that to save time and I’m going to go back to the object settings for the Account object in Salesforce. So if I click on this, this gives me the account object settings for this custom Marketing profile. I can click Edit here and this will give me the ability then to do several things such as assigning page layouts and record types as well.

But the main specific things we’re dealing with right now is the Object Crud. So I’m going to take away some of his abilities. I’m going to give him only read access to accounts. So I’m going to click Save and so now Jim Doe should only be able to view accounts but can’t edit and he can’t delete and he can’t create new. So if I go back to the profile overview and then the assigned Users button, once again I could log in as Jim Doe. So now if I go to the Accounts tab, you notice right off that there’s still the new button here. So Jim can still create new accounts, even though we’ve just updated the object crud for his profile.

To remove that access. We got to do a little troubleshooting to figure out what’s going on. So we’re going to cancel out of this, then let’s go to one of these accounts that he can see here by clicking on it. And remember, I’m still logged in as Jim Doe here. So also you notice that he has the ability to edit and delete these records. And so there’s a couple of things that could be causing this. One is that he may be assigned to a permission set such as View All access and then it may have something to do with the wide default.

So we’re going to first check permission sets to see what Jim is assigned to remove him from that and then come back here and see if we can still edit and delete and create new or not. So I’m going to log out as Jim and log back in as myself. So once I log in as myself, I can go into permission sets. And I did a little digging to figure out what was going on here because I was expecting it to work. I didn’t realize that Jim is assigned to these permission sets for managed chatter groups. I’m going to click on this first one here and this will probably be the same in your own instance as well. I’m going to select Manage User groups and then for the Manage assignments, it shows that Jim Doe is assigned to this Managed Chatter groups permission set. I’m going to remove him from this and then I’ll show you where it’s messing things up for. So I’ve removed Jim Doe from this permission set. So clicking done. I’m going to go back to that permission set and look at the object settings.

So I’m on the managed chatter groups permission set. So if I go to the object settings for this permission set, you see that for accounts, it gives, read, create, edit, delete, view all and modify all. And so even though I had removed the crud settings on the profile level, jim was assigned to this permission set and so was able to do a view all, modify all four accounts. And so I’m going to go back to the other permission set as well and see if he’s assigned to that one. So I go to the object settings for that permission set. It has view all and modify all.

So I’m going to look at the assignments to see if jim is there and he’s not. So let’s try one more time to log in as Jim and see if that works and then do further troubleshooting. If not, and this is a good scenario of what you’ll be faced with as you’re developing on the platform as you think you’ve addressed everything and address security and it’s still an issue. And so you’ve got to do a little further digging. This shows you how other settings can impact the Object Crud as well. It’s not only through Profiles, but also permission sets can open up further access. So we log in as gym, go to accounts and so now fortunately, the new button is gone. So let’s go to this ABC core. And so he has read only access. Now there’s no edit and delete buttons either. So as you can see, the Object Crud or the Create, Read, Update and Delete settings, those can be done from the profile level and those can also be impacted through permission sets as well. And so I’m going to log back in as myself and go back to this custom marketing profile just as a recap here. We started off by going into the object settings and then addressing the Accounts Crud permissions which were previously view all, modify all and Create, Read, Edit and Delete.

Just keep in mind when you hear Object Crud, the U is update but in Salesforce it’s edit. And so I guess you could call this Object Crud and that might be a little more appropriate for sensitive ears, but I digress. Okay, so we’re going to wrap up this section now and it’s been a pretty large and intense section around salesforce security. We’ve covered profiles, roles, we looked at profiles versus roles, permission sets, organizationwide defaults sharing settings, granting access manually and then also the Object Crud or Cred. And now it’s time to take a quiz related to security on the Salesforce platform. And then I’ll see on the other side as we get into the next section of this course, which is Business Logic and Process Automation.