Both Profiles and Permission Sets can be created and packaged in your application to help administrators of your application control access to your objects, fields, tabs, and pages. Fundamentally, profiles have been historically used to prepackage roles, such as team principle, that you envisage the user having when using your application. In contrast, Permission Sets can be used to express the functionality in your application, such as the ability to assign a driver to a race.

By now, most people are familiar with configuring profiles to control security. The issue is that they can eventually lead to a proliferation of profiles; as small differences in needs between users arise, profiles are then cloned and this increases the administration overhead when performing common changes. To manage this, Salesforce created Permission Sets, which are a much more granular way of expressing security controls.

From an application perspective, you can package Permission Sets and even have them upgraded automatically as they change in accordance with the new or updated functionality in your application. They can also assign them after installation, in contrast to profiles, which can only be done during installation. Also, unlike profiles, administrators cannot edit them, though they can clone them if there is a need (this is not possible in Professional and Group Editions of Salesforce). Because of these benefits, it is recommended that Permission Sets be used over profiles when packaging security information about your application.

It is important to plan your use of Permission Sets from the start so that your development team keeps them updated and their usage remains consistent throughout. Consider the following when designing your Permission Set strategy:

• Think features, not roles: Do not be tempted to fall back to expressing the roles you envisage your application's users being assigned. Enterprise organizations are large and complex; rarely does one size fit all. For example, a team principle can have many different responsibilities across your application from one installation to another. If you get this wrong, the administrator will be forced to clone the Permission Set, resulting in the start of the proliferation of unmanaged Permission Sets that do not track with the new or changed functionality as your package is upgraded.
• Granularity: As you design the functionality of your application, modules are defined (you can use Application under Setup to indicate these), and, within these objects, tabs, or pages, each has distinct operations. For example, the Contestant object might describe the ability to indicate that a driver has crashed out of the race and update the appropriate DNF field, which is Update DNF Status. For example, this permission might be assigned to the race controller user. In contrast, you might have a less granular Permission Set called Race Management, which encompasses the Update DNF Status permission plus others. Considering this approach to design your Permission Sets means that administrators have less work to assign to users, while, at the same time, they have the power to be more selective should they wish to.
• Naming convention: When the administrator is viewing your Permission Sets in the Salesforce UI, ensure they are grouped according to the functional aspects of your application by considering a naming convention, for example, FormulaForce - Race Management and FormulaForce - Race Management - Update DNF Status.

Perform the following steps in the package org to try out this process:

1. Create a Race Management custom application (under Setup | Create) and add the Driver, Season, and Race tabs created earlier to it; make the Race tab the default and check the Visible in Lightning Experience checkbox.
2. Create a Race Analytics custom application and add the Race and Reports tabs to it; make the Reports tab the default and check the Visible in Lightning Experience checkbox.
3. Create the Permission Sets for the FormulaForce application, as shown in the following table. Leave the User License field set to None.

4. Finally, add the following Permission Sets to the FormulaForce package:

Here, Full Access means it gives access to read, create, edit, and delete all Custom Fields. Also, at the time of writing, the Custom Application and Custom Tab components within Permission Sets are not packable. Until they become packable, it is recommended that you still maintain this information in Permission Sets.

The Salesforce DX CLI has commands that allow you to easily assign permission sets, for example, when you have just deployed your application to a new scratch org. The following commands will assign the above permission sets to the current user:

sfdx force:user:permset:assign 
  --permsetnam FormulaForceRaceManagementUpdateDNFStatus
sfdx force:user:permset:assign 
  --permsetnam FormulaForceRaceManagement
sfdx force:user:permset:assign 
  --permsetnam FormulaForceRaceAnalytics