In this episode of the ShellBlack Whiteboard, Shell illustrates how to setup security by taking us through a set of security requirements for a fictitious company. Shell uses different use cases to illustrate how you can leverage the Role Hierarchy and Sharing Rules to grant record access in Salesforce.com. Shell touches base on sharing rules based on Roles, Groups and Criteria.
View this video on YouTube: http://youtu.be/Wdmkc6oT-5Y
The first segment in this series about configuring security in Salesforce.
Video Transcription:
Hello everyone. Welcome to another edition of ShellBlack Whiteboard. I am Shell Black, President and Founder of ShellBlack.com and Salesforce MVP. In this installment this is going to be the second part of our security series. The first part we talked about the tool kit of what’s available to lock down your org, grant access back and in this installment we’re going to take a real life example that I was actually working on this with one of these clients this last month and these requirements are real. I made it anonymous so you don’t know who the client is but I thought this was a great way to drive home how to set up security with some real life examples.
So, first thing I need to do to kind of set the stage for this is talk about our role hierarchy. Not necessarily the org chart as we talked previously. The role hierarchy is one of those vehicles that we can use to grant access. So every level of this org chart looking chart is really the role hierarchy. So, we have a sales role, a sales operations role, a sales vice president role, an executive role and an approval committee and you notice that I have three groups of salespeople. So I have a sales VP, they have their own sales operations group and three salespeople below. So there’s sales team one, sales team two, sales team three, exact same structure, just three groups so you can think this is west coast, central, east coast, however you want to look at it. So that sets the stage on who our users are and how the Role Hierarchy is set up.
So let’s go through some of these use cases one by one and we are going to set security in our org. We’re going to keep focused really on Accounts and Contacts. The first requirement is salespeople cannot see other salespeople’s Accounts and Contacts. So when I see restriction, I know that we need to put this in a private model so we’re going to take our OWDs or organization wide defaults and we’re going to ratchet the security down to a private model. As I said before, “shields up,” think Star Trek. What that will do if we set the OWD to private for Accounts and Contacts, you’ll start putting fences or barriers between these groups of users at the same level of the role hierarchy. So salesperson one cannot see anything owned Account wise by salesperson two. We still have the roll up of data based on the Role Hierarchy, so sales operations can always look down, but then that OWD private model restricts our sales VP’s, restricts sales operations from seeing these, executives can always look down. So to solve for question one, how do we make those private or how do we hide things from the salespeople, we’re going to ratchet down our OWD’s make it a private model and the rest of this is all about granting access back.
So second requirement, marketing needs to see everything. So there’s a couple of ways we could solve for this. We could create a sharing rule and say records owned by these people share with marketing. There’s actually an easier way to do that and that is just to put them up here with the executive group and the Role Hierarchy is going to grant access for us and a perfect way to look at the Role Hierarchy, because marketing is here not because people report to marketing, but putting them higher in the food chain is going to give marketing the ability to look down and now they’re going to be able to see all records owned by the entire organization simply by the fact that their position on the org chart or the Role Hierarchy.
Sales VP’s need to see accounts and contacts owned by any salesperson. So right now, this sales VP can only see records owned by the team below them, across all these units so if we want to let sales VP’s see everything, we have to create a couple of things. We have to create two groups and a share so the first group, we’re going to create is the group that has the sales VP’s as members. So we could call it the “group of sales VP’s.” Then what we’re going to do is create a group that has everybody in the entire company, so you could call the group “entire company” if you want, you put all of the users in this group and the share that you’re going to put in place is going to be that grant records owned by the entire organization give access to this group. You’re going to make a sharing rule between this entire organization and the sales VP’s and that will give them access, almost as if they were the Administrator to see all records in the database. So that’s how we’re going to solve for that one.
Then we have a requirement where the approval committee needs to see Opportunities that are in the stage of approval. So, let’s assume that our Opportunities are private just like Accounts and Contacts, we’re going to use criteria based sharing to get access to that so you can share between groups and roles. When you create a sharing rule, there’s a radio button that says I want to make the rule based on criteria and what we’re going to do is almost write a filter that says Opportunities at this stage equals approval, grant access to the users in this role and that is how we will solve that. That’s going to be a criteria based sharing rule on Opportunities is how we solve for requirement number four.
So let’s look at our fifth security requirement. The requirement is that sales VP’s need a way to grant one-off share access to the other groups and what that’s really trying to say is if there’s a record that this VP has in their sales team, they want to be able to check a box and share that with either the entire sales group or with one of their neighboring sales groups. So maybe think of it as they want to make an Account open, but they want to track who granted the access and they want to control which group was able to see it. One of the requirements is we wanted to track who did it and there’s no good way to track who clicked the sharing button, so the way we did this was a set of check boxes on the account record and we used field history tracking to know who clicked it and when and then we made some groups. So we made a group called “sales team one,” a group called “sales team two” with all of these roles and a group called “sales team three” and we created a sharing rule that said and it’s a criteria bases share, so it’s a looking at a field, kind of like this approval stage that was a criteria that said if this check box that says share with team one, if that is true, share with the group team one. If the second check box share with team two was checked, share with the group team two and so on. We deployed that actually using permission sets because we didn’t want to have to make separate page layouts and we granted that permission set only to the sales VP roles so they are the only ones that can see it, that and the System Administrator. So it was really nice because we could keep it down to a one page layout, but using field level security permission set, we were able to deploy to those users in that role.
Ok, last requirement. We want to in our use case there are going to be Accounts and Contact in Opportunities that are owned by the sales VP, but for sales operations to do their job, they need to see records owned by their boss, but we could’ve solved that by putting sales operations higher up in the food chain by moving them higher up in the Role Hierarchy, but because you inherit privileges of the records below them, if we put them above, they would inherit this other share to see all of the other records in the organization and we didn’t want to do that. So we knew that we had to keep them below the sales VP because we didn’t want them to inherit this permission of seeing everything that was requirement number three. So, what we had to do is we had to create another share that says records owned by users in this role grant to users in this role and that essentially allowed this group to look up so they could service and have access to records above them in the food chain. Normally you can look down, so basically we had to grant access by creating a share so they could look up. Again, if we put them higher in the role hierarchy they are going to inherit that privilege of that VP of being able to see everything in that entire organization and that’s not what we wanted to do.
So a fairly complex use case. Actually it was a real use case from this month and I thought it would turn out to be a great example of how to drive home some of the things we talked about in our earlier installment how to use a Role Hierarchy, OWDs and sharing to set up security in Salesforce.com.
I hope you like that. I would love to hear your feedback so we can keep that in mind in future episodes. There’s a couple of good ways to get ahold of us. You can reach me on Twitter I’m @Shell_Black. Make sure you get the underscore there and you can always email whiteboard@shellblack.com, it goes to me. I would love to hear your feedback and we look to see you soon. Thank you.