[#Blogged] - Salesforce Administrator Guide: Propelling your Career Forward - Part 5

 

Part 5: The Lowdown on Salesforce Permissions

In Part 5 of our series Salesforce Administrator Guide: Propelling your Career Forward, let’s take a few minutes to discuss Salesforce Permissions. To be clear, Salesforce permissions run deep and wide, and you will eventually need to put in a decent amount of time to become an expert at this, however, today we’re just going to go over some basic terms to make sure you understand the gist of things.  Let’s dive in!

Image: OWD and Sharing Settings

Organization-Wide Defaults (OWD) - This controls the record level access for the entire org, on whether records should be privately viewed or not. For example, you may not want Sales reps to see each others’ Opportunities, so you can make the Opportunity object private.

Role Hierarchy - As you create users in Salesforce, you determine which Role they may be in, such as Sales rep or Services rep, for example. Specific roles can be nested under others, such as the Sales Rep, which looks up to the Sales Manager, which looks up to the VP of Sales. You can grant record access based on Role Hierarchies to ensure a Manager can always see his rep’s records. 

Sharing Rules - These are another way to work within the OWD you have set, to allow users to see certain records. You can set up Sharing Rules to work with Public Groups that you have established, in order to grant access to certain records with specific criteria. This is a great way to share records across departments.

Manual Sharing - Manual sharing is an option for individuals to share individual records. Maybe your sales rep only needs to share a record with the Service rep once or twice a month, and they only need to see one or two at a time. This would be a good way to allow record sharing without the setup involved for sharing rules.

Field Level Security - Also known as FLS, field level security is where you can allow certain profiles to have access to a field. You may find that some fields should remain hidden from lower level end users, or reserved for a specific department, such as Finance. This allows you to limit clutter and unauthorized permission.

Image: The Role and Profile are located on the User Record

Profiles - Each user record has a profile, which houses object and system permissions. These are separate from roles, in that these give what is known as “CRED” access: Create, Read, Edit, or Delete. This allows your user to take those actions on records, and should be thoughtfully considered before doling out. 

Permission Sets - The idea of Profiles is to give users that need the same permissions their access in a way that’s easiest for you as an Admin. You simply don’t want too many profiles. However, you may find that there are permissions that may be needed for a select group of users that are very specific to an object or setting that others should not have. A permission set can be created and added to the user record to grant that access.

That’s a lot - and only scratching the surface. If you’re looking for a pretty awesome trailhead on this topic, check out the Data Security module.