Even though Salesforce has a comprehensive, multi-layered, yet fairly easy to set up and use security Model, people still seems to get ‘twitchy ‘whenever the word ‘cloud’ is mentioned.
Never more so than now with the imminent introduction of GDPR and the demands it will impose on data security.
Salesforce is pretty hot on security and the model they have developed has several components that give finite control over:
- Who sees what;
- Who can access what and where from;
- What they can do with what they can access;
OK, sounds good, so how do they do this?
Record access can be managed in four ways:
Organisation Wide Defaults (OWD)
Denotes the access level users have to each other’s records. OWD locks down data to the most restrictive level.
Top down access for users higher in the hierarchy.
Used to provide automatic exceptions to OWD’s for specific users or groups of users, so they can access records they don’t own or have access to. Like Roel Hierarchies they are only used to give additional users access to records. They can’t be stricter than your OWD’s.
Owners of specific records can share them manually with other users. Manual sharing isn’t automated like the other options, but it can be useful if situations such as Holiday or sick cover.
So, let’s delve a little deeper into each of the four Types.
OWD’s specify the baseline minimum level of access to the records in an Object. Privileges granted by the OWD’s affect everyone. Different OWD’s can be set for internal and external users.
The option for OWD’s are:
Private – only accessible to users who have access via ownership, role hierarchy, permissions or sharing or manual sharing rules.
Public Read Only – all Object records can be viewed by everyone internally.
Public Read/Write – all Object records can be viewed and edited by everyone internally.
Controlled by Parent – Users can perform the same actions on a Controlled by Parent record as the Actions set for all associated master records.
Automatically grants access to data owned by users in roles below them. Although a role is not a pre-requisite when we create a user, it represents a useful way of securing data level access. Don’t think of it in terms of your Organisation’s hierarchy, think of it more as groups of users who need access to the same data.
Sharing Rules are used to further extend user access to specific data. They can be based on the record owner, roles or other criteria. You can create Public Groups and share records between Groups.
Allows record owners to share access from individual Records to other individual users, roles or groups. This isn’t automated it provides an additional flexibility to share records which the other security features don’t cover. Allows owners to give the following levels of Access:
So those are the standard Salesforce Security features, however, there is one more that is very useful and that is Permission Sets.
Say you have a User with a Sales User Profile, which allows them to Read Create and Edit Leads, however, part of their role is to transfer leads to other members of the Team, how would you do that?
Create a new profile maybe? Is that worth it for one person though?
This is where Permission sets come into their own!
Here you would create a Permission set giving rights to Transfer leads and assign that Permission set to that specific user. It doesn’t change their overall Sales User Profile, it just gives them alone additional functionality with Leads.
Permission sets can also be used to open visibility to certain fields within an Object. If you have restricted field accessibility on say Accounts for a certain Profile in Sales but there is one person who needs to see the figures, then you would create a Permission Set, make those fields visible and editable if required and assign that Permission set to that specific user.