role hierarchy

  • Protecting your data security with sharing rules

    Data security, sharing rules, org-wide defaults, role hierarchies – are all parts of a bigger puzzle, which can feel like a maze sometimes.  It isn’t a sexy topic by any stretch of the imagination, yet defining a robust data security policy is fundamental to all Salesforce orgs.  Let’s dive into what data security is, and how to set it up within Salesforce.


    Data security in Salesforce

    Data security within Salesforce has a number of facets to it.  You have varying levels of security controls, which can seem quiet complex to start off with.  Though it is this flexibility which actually gives you a lot of control, allowing you to show a specific object/record/field to one group of users while hiding it from another.

    The most common form of data security is controlling access to an object or field through the user’s assigned Profile/Permission Set.  For example, you set a user’s access to an object by defining if their profile can either Create, Read, Edit or Delete.  This is often referred to as CRED permissions (or CRUD where the U = update).

    Object access is the first level of security a user will need to pass.  If a user doesn’t have access to an object, they will never see any records.  This gives you a sledge hammer approach to control access, but what happens if you need to finesse this?

    Say you want to control access to a record based on a specific field value and then share that with certain groups of users?  Controlling a user’s access to an object doesn’t really help you out, does it?

    This is where your Salesforce instance’s Org-wide Defaults (OWD) & the sharing rules come into play.

    Org-wide Defaults (OWD)

    Org-wide Defaults or OWDs for short, is the next level of security and will allow you to define what the default level of record security is per object.   If you were to try to visualise it, most people draw it out as a funnel.  This is because you first start by restricting the Org-wide Defaults of an object, and then extend access from that default.

    visibility of a record
    Controlling record-level access (source: Trailhead)

    What do I mean by first restricting access?  In Salesforce you have three levels of default record visibility per object:

    • Public Read/Write – all records are publicly available to read & edit for all users who can access the object.
    • Public Read Only – all records are visible for all users who can access the object, but not edit.
    • Private – no records are visible/editable for users who can access the object.

    Now the above rules have two key exceptions. The first is when the object in question is part of a Master-Detail Relationship.  If it is and it is the child object, it will inherit the OWD from the parent object(s).

    The second ‘gotcha’ is when the user is an owner of the record in question.  Ownership of the record will grant access to the specific user who owns the record, providing their profile grants them access to the object.

    Role Hierarchy

    Role Hierarchies within Salesforce play an important part in record visibility.  As they allow you to build in general record visibility for those higher up the hierarchies branch.  The most common example would be when you want a manager to see what their team is doing within the system.

    This is important to note as when you set your OWD to either Public Read Only/Private, the role hierarchy needs to be taken into account to ensure that relevant hierarchy above the owner of the record still have the relevant access.  When setting the OWD, you do this by ensuring ‘Grant Access Using Hierarchies’ is enabled.

    (For more information on Role Hierarchies, Salesforce Help & Training article)

    Sharing Rules

    Now we have built the foundations for who can see what, we need to extend access as required to the various types of users.  This is where Sharing Rules comes into the picture, they help you extend the default settings from above.  One example could be where a team of sales users needs access to each other’s records.  If the OWD is Private, you would need to extend the sharing of records within that team.

    Sharing Rules within Salesforce give you two types of control, based on either the:

    • Record owner (eg user ‘Sharon Williams’ owns the record), or
    • Criteria based sharing (eg if field ‘Record Type’ equals ‘North America’)

    This allows you to define how a record gets shared.  And this can be to a group, specific role or a role and all of its subordinates in the hierarchy.  You then pick how to the level of access to finish up (read only or read/write).

    Options for owner based sharing
    Options for owner based sharing

    There are some nuance’s with sharing rules, and limits are enforced on the number of rules you can have by Salesforce.  For example you can have up to 300 sharing rules on an object, with 50 criteria based sharing rules.  And only specific field types can be used for Criteria based sharing rules.  To view the considerations, go to the Help & Training article for more.

    Manual sharing

    Manual sharing is an additional control which allows you or the user to manually share a record.  This is done by clicking the ‘Sharing’ button on a record (if it is on the page layout).  This is where you can also see the sharing detail, which will display who has access to the record, what that access is and why they have that access.


    Final words

    Hopefully that helps you control your org’s data security, as you can see there is a lot of detail and thought that goes into ensuring the right people see the right data.  As an additional topic, there are also Apex Sharing rules which can give you even more control over who can see records, but I won’t cover these in this post.

    There are also some great resources are available from Salesforce if you want to dive into this topic further.  I found this video walk through provided which is ~5min video.  It shows you how to setup the rules we discussed here in Salesforce Classic. There is also an awesome Trailhead on the topic of Data Security, which you can find here.


Back to top button