Salesforce Profiles

Profiles define how users access objects and data, and what they can do within the application. When you create users, you assign a profile to each one.

Reference: Salesforce 

And my recommendation is that, before you start and create a Profile for each Role in the Role Hierarchy, you should read carefully what a Permission Set is, how it defines too how users access objects, and get a good understanding of what is the difference between a Profile and a Permission Set.

Check the table at the end of this post The Fall of the Profile Empire to see what you can do only with profiles.

The Profile Minimum Access - Salesforce proposed approach

I will use the example Hiring Application proposed in the Data Security Trailhead Module to develop the approach. Regarding data security, the module deals with permissions at 4 levels: Org, Object, Field, and Record. But I will work with only two levels: Object and Field.

The required permissions are:

Custom Object	Recruiting Manager	Recruiter	Interviewer	Standard Employee
Position	Read Create Edit	Read Create Edit	Read (No min/max pay)	Read (No min/max pay)
Candidate	Read (No SSN)	Read Create Edit	Read (No SSN)	Not Applicable
Job Application	Read Edit (No lookup fields)	Read Create Edit	Read	Not Applicable
Review	Read Create Edit	Read Create Edit	Read Create Edit	Not Applicable

And the Role Hierarchy proposed is:

Source: Salesforce

In the Trailhead Module, the solution proposed is two Profiles and two Permission Sets. It's important to notice that one Profile is a clone of the Minimum Access - Salesforce profile.

The analysis followed to solve the problem with two Profiles and two Permission Sets is one that leads to an optimal solution for strictly the problem of the Hiring Application.

We know as Salesforce Admins and Project Managers, that when a project starts, during the analysis phase, it's quite difficult to have all the needs and requirements about the objects and fields permissions in one place and at the same time (especially if we do sprints), then having a table like the one above is not easy. Let alone if you include more standard objects like Account and Contacts to the problem.

... Use profiles to grant the minimum permissions and settings that all users of a particular type need ...

I propose a general solution, using a reduced set of Profiles and more Permission Sets that still solve the problem. The idea is based on the fact that a Profile will never include CRED settings for objects, and will only include (or have the ability to include) settings for those permissions that can only be set in a profile.

Then we end up with a situation like this:

• Profiles (copy of Minimum Access - Salesforce)
• Department VP - MA
• Department Director - MA
• Department Level 1 - MA
• Permission Sets
• Position - CREx
• Position - xRxx (No min/max pay)
• Candidate - CREx
• Candidate - xRxx (No SSN)
• Job Application - CREx
• Job Application - xREx (No Lookups)
• Job Application - xRxx
• Review - CREx

There are two important achievements of this solution:

1. The profiles are a clone of the Minimum Access profile, they are practically the same unless there are some settings in each one that you can do only through profiles (like Login IP Ranges). Very simple, less error-prone, and easy to manage.
2. We have Permission Sets for one "objective" only, CRED properties on a particular Object, then in the future, if more roles are included in the hierarchy, we can reuse our Permission Sets easily.

As an administrator, you know that there will be more complex situations regarding the permissions we configure on an object and its fields, like for instance, if some SW Engineers can work as Recruiters too. We will deal with this on Salesforce Permission Sets post.

Here we want to understand how can we identify and list the properties of a profile to report them, those in (1) above.

Profile Properties

A Profile has several properties, and each property has different settings. The properties and settings are part of the Profile metadata as a class. Hence, to automatically list Profiles properties (not using the Salesforce interface), we need to understand and deal with the Profile metadata. 

If we can automatically read the Profile metadata, then we will be able to list it in a report or compare it against other Profiles.

I know it is not a simple task, and that's why I developed Toolsforce. Here is the list of Profile properties that currently Toolsforce deal with:

Property	Attributes / Description
Profile Name	The API name
Description	The description
Is Custom?	TRUE if it is a custom profile
User License	The type of license used
Application Visibilities	Application Visible Default
Category Group Visibilities	Data Category Group Data Categories Visibility
Class Access	Apex Class Enabled
Custom MetadataType Access	Name Enabled
Custom Permissions	Name Enabled
Custom Setting Access	Name Enabled
External DataSource Access	External DataSource Enabled
Field Permissions	Field Editable Readable
Flow Access	Flow Enabled
Layout Assignments	Layout RecordType
Login Flows	Flow Flow Type Friendly Name UI Login Flow Type Use Lightning Runtime VF Flow Page VF Flow Page Title
Login Hours	Sunday Monday Tuesday Wednesday Thursday Friday Saturday
Login IP Ranges	Description Start Address End Address
Object Permissions	Object Create Read Edit Delete View All Records Modify All Records
Page Access	Apex Page Enabled
Profile Actions Override	Action Name Content Form Factor Page Or SObject Type Record Type Type
Record Type Visibilities	Record Type Visible Default PersonAccount Default
Tab Visibility	Tab Visibility
User Permissions	Name Enabled

When you use the button Profile in Toolsforce, you will be able to create a report like the one below in a new Excel worksheet.

Don't wait, download and install the tool, it's free! 😊