twittergoogle_pluslinkedin

Before I undertook a complete re-building of my company’s roles in SFDC, I thought that I understood how user roles worked. I also thought that security settings were simple and easy to understand. That was some highly delusional thinking! During this project, I learned so much about roles, sharing rules, and profile permissions – and made countless mistakes while learning – that I decided it was worth a blog post. In my Before Implementing SFDC post, I barely mentioned the subject – but security settings are a huge consideration and involve some very complex relationships. Here are a few tips that I hope will save you some effort.

1) You do not necessarily need a role for every title. Roles exist to provide levels of access in the form of a hierarchy. Let’s say you have three Sales Team Managers, and you want them to have access to objects owned by each other’s teams, but keep the team members from seeing anything outside of their team’s ownership. You would give all of the managers the role “Sales Team Manager” and then assign separate roles to the users on the teams:

However, if you do not want the managers to have access to any team other than their own, you would set it up like this:

2) The role hierarchy is part of the sharing rules. A user can access objects owned by users in roles below theirs in the hierarchy. Keep this in mind when assigning roles, and when selecting the organization-wide defaults for your sharing rules. “Private” actually means “anyone above me in the role hierarchy can see my stuff.”

 

3) You can add sharing rules to share access of specific objects with groups, queues, or roles that do not have access in the existing role hierarchy. Let’s say you want your sales reps to have access to leads owned by Marketing. This is the sharing rule you would create:

This would give everyone under the VP Sales role access to leads whose owner has the Marketing Team role – without forcing you to rearrange the entire role hierarchy just to change security settings on one object.

4) Any user who requires access to the entire database should be assigned the highest role in the hierarchy. An SFDC support rep gave me this advice, and it saved me a lot of trouble! Put your System Administrator role at the very top of the hierarchy:

5) “View All” and “Modify All” permissions in profiles will affect your sharing rules. Let’s say you’ve got the System Administrator role somewhere in the Sales role hierarchy, and a sharing rule that grants access to everything owned by users in the VP Sales role hierarchy to each other:

This will cause major issues! (I am assuming that anyone in the System Admin role has “View All Data” and “Modify All Data” enabled in their profile.) Anyone within the hierarchy in the sharing rule now has access to the same data as the System Admin. You must consider profile permissions when you create a sharing rule. Also – and this is a best practice no matter how you look at it – be extremely selective about enabling “View All” or “Modify All” in profiles other than the System Administrator profile.

If you’re only going to remember one thing from this post, here it is: When you look at your role hierarchy, it should have at the top those who require the most access, and work down to those who require the least access. The System Administrator would be the highest role, and users who only access their own objects would be at the bottom (meaning, they should have no roles under theirs).

For more info: SFDC provides useful demos on Managing Users and Security and Customizing User Profiles. Best of luck!

Liked this post? Follow this blog to get more. 

One Response

  1. avatar Chanel Francoise says:

    Fantastic info and interestingly written. Keep up the superb stuff!