Setting up salesforce security through profiles and roles can take a while to get your head around. Here’s a dummy’s guide to get you up to speed.
The analogy I like to use is driving a car. A profile is like a driving licence: it gives you the right to drive cars and even sets out what kind of vehicles you’re allowed to drive. In contrast, a role is like owning a car, or being given someone’s keys: it gives you access to drive this particular car. In the same way to drive a car, a licence (profile) is mandatory however having a car to drive (role) is optional.
Profile Level Security
Profiles is where you can set out which kind of vehicles (objects) you’re allowed to drive. Object security determines what actions (Create, Read, Edit, Delete) each user of that profile can perform on records of each object. These settings only apply to your own records so if you have edit enabled for the account object you will only be able to edit the account records you are the owner of. To be able to edit other peoples accounts you would need ‘Modify All’ ticked and in the same way ‘View All’ gives the user the ability to read all records for that particual object not just your own.
Other useful profile level security settings to think about:
✓ Ability to run or export reports
✓ Ability to view the setup menu
✓ Restricting login hours
✓ Restricting IP range access
✓ Which tabs/apps are visable
✓ Record type permissions
Once you have profiles set up you can start to think about roles (who gets the keys to which cars). Roles give an organisation the ability to control access to information. This is useful when the organisation wide defaults (OWD) are set to private (only the owner can access the record) as roles then give you the ability to open this up to grant additional access.
The Salesforce’s Role hierarchy is structured as a tree and permissions roll up from the bottom. This means users at any given role level can view, edit, and report on all data owned by or shared with users below them in the hierarchy, unless your organisation’s sharing model for an object specifies otherwise.
Using the below image as an example the VP of Hardware will be able to see the hardware and sales rep’s data but would not be able to see the software rep’s or the VP of Software’s data as they are on different branches of the tree.