Sharing Knowledge About Being A Salesforce Sharing & Visibility Designer

These are called domain specialists. The Certified Sharing and Visibility Designer Certification is a specialization that I like to focus on and will drop a little bit of knowledge here to hopefully help anyone who reads this to obtain this certification.

Sharing and Visibility go beyond Profiles and Roles these days in Salesforce. There is a lot to know about under the covers of how to share and essentially hide pertinent data from specific users at any given moment. I’ll describe what I did to prepare for this certification as I armed myself with the knowledge necessary to now call myself a Certified Sharing and Visibility Designer.

Profiles and Roles - Still the King and Queen

Despite what I wrote just one paragraph above, at the end of the day visibility and sharing are largely responsible for what a user in Salesforce can do and what they can see. I like to think of it as a large Excel sheet. The rows in the sheet are records in Salesforce. The columns represent the fields on a given object. The profile acts as a hammer in some cases and the org-wide defaults + role hierarchy act as the scalpel. For example, if a user’s profile says they can “view all accounts” and your sheet is full of accounts then the user will see every row. Their profile may also state that they’ll never ever see data in column H. Even though the user can see every single row, they’ll never see whatever it is in column H.

Here is where things get a little more interesting. If the profile isn’t the hammer and just states that a user has Read access on Accounts then we rely a little bit more on our defaults and our roles. By default if accounts are set to private then the user would be able to see Accounts that they own and only ones that they own (or are owned by someone below them in the hierarchy - more on this shortly). Simple so far… Let's introduce roles into the scenario. Roles act as a hierarchy, the higher up the hierarchy the more data the user will see. This is where things get really fun. You can share data with users at the top of the proverbial food chain by putting them higher in the role hierarchy. This is one very simple way of executing, though not always resulting in, the outcome that you are looking for.

Org Wide Defaults and Sharing Rules

Continuing on the above example, if someone isn’t supposed to be setup all the way up at the top of the hierarchy just to see Accounts, because perhaps they should only see accounts of a certain type, we can create criteria based sharing rules. These add to the already existing default of private; used to open up privacy to more records based on criteria on a record that is evaluated when a user clicks on the record. Records can be shared based on most things about them and can be shared with Roles, Roles & Subordinates, or even Public Groups. Public Groups add a finer level of flexibility (this is why the sharing is the scalpel in our scenario). A user can be a member of one and only one Role yet they can be a member of many more public groups. Roles can even be nested inside of Public Groups to create an Uber Role if you will. Creating visibility using a private model and public groups is a fantastic way to streamline visibility.

Overwriting Everything for One User

Permissions Sets have long been a favorite feature here at Arkus. They mimic most of the permissions that are available on a Profile but can be assigned to specific users as additions to their existing permissions. Sometimes you will have one or two users who need access to everything. You can create a Permission Set with View All Data at an object level or dare I say Modify All Data at an org wide level to give these types of permissions to very special and specific users at any time regardless of their Role, Profile, or public group membership.

Apex Sharing

For the daring and extremely complex sharing requirements, sometimes you have to resort to Apex custom code to write sharing rules. These are often extremely complex sets of business rules that require custom sharing records to be written on certain records based on criteria that cannot be written in a simple WYSIWYG fashion. For example - if a user is an owner of a record that is related to an Account via a junction object, then give them Read Only access to the Account when otherwise they wouldn’t have access at all.

I’ve Shared Lots of Knowledge

Now that you are armed with all of this knowledge perhaps try to take the next step and go for the Sharing and Visibility Designer certification. If you were to focus on the basics as I’ve laid them out here then you are likely about 75-80% of the way there. Understanding how data is shared or hidden within Salesforce is key to having a secure environment where users have a excellent experience and management get the proper piece of mind that data isn’t visible to everyone while also having the proper visibility set for themselves.

Please feel free to comment below, on the Salesforce Success Community, on our Facebook page, or directly at me on Twitter @JustEdelstein.