Security in Salesforce is not something that I’ll go into in too much detail unless I decide to change the approach of this site because it just isn’t as applicable to using dev orgs. It is however very, very applicable to providing a solution to clients.
Security is not just about locking down information so that others can’t see it, it’s also about limiting what they can see to improve their user experience by filtering out the noise.
Salesforce has an entire guide to explaining all of this that can be found here
All I want to do here is show you my favourite slide of all time on sharing, and then spend a few minutes explaining it so that everyone is clear. We will assume that the objects are private, and are being opened up by this model. Hopefully Salesforce doesn’t mind me stealing their slide.
I don’t want to get caught up in everything, I just want to cover the big stuff.
- OWD is Organization-Wide Defaults. You can set this to private or public. If you set it to public, you have no way of limiting access after that besides taking it away from the entire object. In general, set the default to private if there is even a single record that people shouldn’t see, and then open it back up with roles and sharing rules.
- Role Hierarchy – This opens up access vertically. In easy terms, it means your boss can see everything you own, and so on, and so on up the chain of command. When setting up a role hierarchy, don’t focus as much on the actual org chart, just use it as a starting point.
- For example, the System Admin should be at the very top so that they can see everything when someone asks them a question
- Sales Support should be above all sales people if they are a shared service that supports everyone
- If defaults are private, people in the same role cannot see each other’s records. This is a common mistake in assumptions that people make. They are still hidden
- Sharing Rules – This opens up access horizontally. In easy terms, sharing with another team. So let’s say that settings are private, and there are 6 North American sales reps. You could create a sharing rule to share all Accounts between the 6 reps, but with no one else in the company. Kind of like they are working in a pod so that they don’t step over each other. Very, very common request.
- Sharing rules can also be criteria based. This is also helpful. A prime example is to share all Closed Opportunities with the Shipping department. They don’t need to know about pending deals, but once a deal is closed, they should gain access. I’ll talk about these more in a future post as well
- Manual Sharing – Not commonly used, but this is also how Apex (code-based) sharing is displayed on records so it’s important to know that it exists. Try to use other avenues first, and use this for one-offs.
This became longer than I thought, I really just wanted to show this amazing slide that I bring up on a regular basis when trying to explain security to people, hopefully it makes a little more sense now. As long as you remember Vertical vs Horizontal sharing you’ll be able to work backwards to the rest. And remember, none of it matters if the client says make access public because you can’t then lock it down! Salesforce security is about opening things up to the right people, not restricting access to those who shouldn’t have it.