In this episode of the ShellBlack Whiteboard, Shell introduces the major areas in “setup” that impact record access – Record Ownership, the Role Hierarchy, Organizational Wide Defaults (OWDs), and Sharing Rules. Shell highlights how the Role Hierarchy differs from your organizational chart and how it allows managers to see records for owned by their subordinates. Additionally Shell provides some tips on how to troubleshoot security and access in your org and the “Perils” of setting an object’s OWD as “Private.”
View this video on YouTube: http://youtu.be/qZziJ_jodnA
The second segment in this series – An Example of Security and Sharing Rules
Transcription of the video:
Hello. Welcome everyone back to ShellBlack Whiteboard. I am Shell Black, President and Founder of ShellBlack.com and Salesforce MVP. We are going to tackle a huge topic, security. Security in Salesforce. We are going to make this a two part series because it’s a big topic. The way I’m going to do this is the first part I am going to introduce a lot of the concepts of how security works, the levers you have at your disposal to set up security and then we’re going to go through in our second installment of this a use case. We are going to take a sales organization and we’re going to run through some problems that we have to solve to illustrate how you use that tool kit that Salesforce provides to you to set up some real security requirements.
So, to get started let’s look at some of the levers that we have at our disposal to set up security in Salesforce. First of all, if you’re a small organization, you may have no security and that’s fine. There are bigger organizations where you need to start hiding stuff and restricting access and record visibility and so security is something that you’ll need to learn especially as a Salesforce Administrator how to set up.
So, let’s go through some of the major parts of the tool kit. I am going to start off with something called the OWDs which stands for Organizational Wide Defaults. What the OWDs do is by objects, say Leads, Accounts and Contacts, maybe Cases, Opportunities or Custom Objects it sets the baseline security for that object and there’s three tiers that you can set. The default is “Open”, which is really no security. It means everybody can see everything, it’s a big love fest, no concerns there. There’s “Read” which means I can search and see the record, but the edit button is gone. There is also the setting called “Private”. I like to say “Shields up,” kind of like the old Star Trek. “Shields up” when you’re in private mode because then you can’t look over the fence and it restricts visibility. The thing to remember about OWDs or Organizational Wide Defaults is that is how you ratchet down security, how you make something more secure. Use other methods to grant access or open things up like sharing rules and those types of things. So, it’s only used to restrict, it’s the baseline access.
If you have to hide records from one person, one user in the organization, you’re in a private model. You have to lock everything down to hide records from somebody and then use things like sharing rules or whatever it might be to grant access back to the rest of the organization. So, if you have to put one person in the penalty box and make sure they can’t see their neighbors stuff, you’re private for that object, whatever that object might be, and then use sharing rules to grant access back.
So, let’s assume that we are going to a private model and our illustration we’re going to be in the context of Accounts and Contacts to keep it simple and if we put something on lock down and make it private, that means that people that are at the same level can not see information.
So, I should stop right there and let’s talk about the Role Hierarchy because this is where the role hierarchy gets into play. So the Role Hierarchy, I have different levels here, I have an executive bucket, a Sales VP, Sales Operations and Salespeople. The Role Hierarchy is not necessarily your org chart, or you organizational chart, it is really a way to roll up information to grant access. The thought is if you are higher up in the Role Hierarchy, you by the nature of your position higher in the food chain should have the rights to look down and inherit and see the information owned by users below you. So, let’s take sales operations. They are above these sales groups and the nature of the fact that they are on top of these folks, Salesforce assumes if you are a manager of another user or higher in the role hierarchy, you need to be able to have access to the records of the folks below you so that Role Hierarchy is granting access up.
You also inherit record access and inherit privileges of users below you. So, if you had a special record access privilege for sales operations, the sales VP who is above that person will inherit any privileges or extra access you give this person is inherited by their boss. The thought is that again, the fact that they are a manager of that individual they should have the same rights as the folks below them.
So, things to remember: it’s not necessarily an org chart, it’s really for record access and you inherit privileges of the folks below. If we were in a private model in this instance and we threw Accounts and Contacts using our OWDs threw that into a private setting, we’re really drawing “shields up” between our users. So I’m drawing shields or a barrier between our folks. So without any other access or sharing rules, this salesperson is not going to be able to see this salesperson’s information, this salesperson is not going to be able to see this salesperson’s information on Accounts or Contacts. They are only going to see records that they own and Record Ownership is kind of the key to that. Record Ownership by default allows you to see a record. If you’re the owner of the record, great. If you are the manager or higher in the Role Hierarchy you inherit that, but if you notice that I have a line here so people in the same role, this sales operations person can not see records owned by this sales operations person, this sales VP cannot see records at the same level of the hierarchy. So just like we have “shields up” between these salespeople, we have “shields up” between these sales vice presidents as well. Executive folks can see everything because they are at the highest part of the food chain and by nature where they are in the Role Hierarchy, they can see all the records below them.
Okay, so we talked about when we lock stuff down, how does that impact record access? How do you start granting access back to the folks? That is through sharing and sharing can’t restrict, it only grants. It’s the opposite of your OWDs and it allows you to give groups of users or certain criteria of records access being visible to other users. Lots of ways to do that. You can do that through sharing rules, you can do that through manual sharing, so if you’re the Record Owner, there’s a share button on the record that you can push and grant access to different users. Just “one-off” using the share button. Account Teams. You can establish Account Teams to say that this person is an inside salesperson of this other person by that nature because then the account team, maybe they do contracts or proposals, that person needs access to these people’s records because they are part of the Account Team. I’m not going to get too deep into that, but sharing is how you grant access back to a larger population. OWDs is how you restrict.
Okay, so we talked about how the Role Hierarchy affects regular access, OWDs and sharing. Let’s talk about as an Administrator troubleshooting because once you start locking things down, you’re doing these crazy sharing rules and granting access, it gets complicated very quickly and someone is going to ask you, “Can this person see this? Are they allowed to see that?”, and you’re going to need a way to test this. When you’re setting up security, you’re going to need a way to go in and validate that you’ve got your sharing model and your rules in place and they’re working correctly.
Two quick tips: You can open a case and this is a fairly recent feature in Salesforce and there’s a blog post on my website about how to open this case to be able to log in as any user in the system. Basically, the old school way is you’d have to get ahold of that user and tell them you need them to grant access to their Administrator. No longer. You can go in org wide and have the log in button on the user panel for any user by opening up a case. We’ll give you the link in the transcription of this blog post on how to do that. That is awesome because then you can log in as them and search and just see if you can get to that record. That’s very helpful. If they do get to a record that you didn’t think they should be able to get to, here’s the second part of the troubleshooting. There is a sharing button that will appear on the page layout and if it’s not, check your page layout to make sure it’s there. When you put an object into private security with your OWD, a sharing button becomes available. If you are questioning why a user can see something, click that sharing button, then there’s going to be a link to expand the list which gives you a list of all the users and there’s going to be a link with a question mark called “Why.” Click that “Why” button and it will tell you what is granting access to that user. Is it the role hierarchy or are they part of a group? Is it part of a manual share? Are they part of an Account Team? That will explain why that person can see that record. So troubleshooting, log in as any user and the sharing button. Super, super helpful to make sure you can validate and explain to somebody else why or why can’t somebody access a record.
Okay, kind of wrapping up this topic, I’m going to call the “Perils of Private.” So the “Perils of Private” is if you have to lock down your org using your OWDS and put something in a private mode, you risk having duplicate records. When people search for something, they won’t know it already exists in the database. If this is a private org and this salesperson has the account Acme, and this person is searching for Acme and there’s no sharing between the two, this person is going to think Acme doesn’t exist and it’s going to create a new account. As an Administrator, that becomes a headache because now you have a duplicate record in the database. So, I’m calling that the “Perils of Private.”
Really talk to your management team of whether that benefit of being private outweighs some of the data management concerns of duplicate records. There’s a balance there. From a business standpoint it might be required, but just realize you’ve now created this other monster of duplicate records and the other peril of that is what I’m calling “collisions.” So, what will happen is because this person does not realize that someone already owns this Account, they are going to start calling on that Account and there’s going to be a collision. You’re going to have two salespeople potentially calling on the same client. That can be embarrassing for your company. I’m calling it a collision, but those are the perils of being in a private model.
A lot of stuff to take in. We’ve barely scratched the surface of the big leavers of the tool kit you have to set up security. To kind of get this message home, we’re going to have a second installment to this where we’re going to take a real life example and set up security, kind of virtual with our whiteboard with some real use cases to kind of drive the points home of all of these leavers that you have at your disposal.
If you would like to give us some feedback of how we’re doing or maybe some topic suggestions, I want to make sure you know how to reach out to us. A couple of ways you can to that. I’m on Twitter @Shell_Black, don’t forget the underscore and you can always email us at whiteboard@shellblack.com. Love to hear from you and we’ll see you soon.