Permission Set Design Guidelines

Permission Set Design Guidelines provide standards for naming and configuring permission sets. It can be difficult to tell at a glance what a permission set grants, so it is important to write clear names and descriptions to identify a permission set's purpose and scope.

Determining the Scope

Permissions are granted primarily through a user's profile as well as any permission sets assigned to them. Each user can only be assigned to a single profile but they can have many permission sets.

Profiles

Nimble AMS includes custom profiles for standard users and for integration users. If the Nimble AMS Standard User profile is too broad of an application for all staff, we recommend cloning it and reducing the permissions in the cloned profile so it accommodates a more specific group of staff. The specific permissions you removed from the profile can be added back to individual staff through permission sets.

Permission Sets

In the same way that information spreads out across several objects in a normalized data model, permissions can be spread out across several permission sets by applying a normalized security model. This reduces the need to assign staff a profile bloated with too many permissions, which acts like a dangerous "master key," potentially giving staff access they should not have.

For staff that have a more slimmed down profile and require additional permissions, we recommend granting these through various permission sets. Each permission set should have a very specific purpose; avoid turning permission sets into bulky "master keys."   

Custom tabs and object relationships are a good indicator when determining the scope of a permission set. For example, International Society for the Exceptionally Nimble has a custom object named Widget, accessible via a Widgets custom tab. They initially granted the permission to all users through a profile, but now want to reduce who has access. Some users need the ability to view all widgets, while others need the ability to create and modify all widgets. Here, we recommend removing all Widget object permissions from any assigned profiles, and then creating two distinct permission sets:

• Widget View All—grants View All (including Read) access to the Widget object and tab.
• Widget Create and Modify All—grants Create access and Modify All (including Read, Edit, and Delete) access to the Widget object and tab.

In this example, you need to first revoke permissions from all profiles because a permission set can only ever grant more permission to a user; a permission set never revokes permissions a user receives from their profile or other permission sets. Learn more about Permission Sets (external).

Placing permission for only one object in a permission set ensures users do not get more access than necessary. In some cases, however, you can combine permission for multiple objects into a single permission set. For example, if the International Society for the Exceptionally Nimble has a Material object that is exclusively a child object of the Widget object, Material permissions can also be included in the Widget permission sets.

We only recommend you combine permission for multiple objects and tabs if there are no use cases where staff need permission to a subset of these objects and tabs.

An example in Nimble AMS are the permission sets for Schedule and Schedule Line. These objects and tabs go hand-in-hand with one another, from a security perspective, so a single series of permission sets can be used:

• Nimble AMS Schedule View All—grants View All (including Read) access to the Schedule and Schedule Line objects and tabs.
• Nimble AMS Schedule Object Create and Modify All—grants Create access and Modify All (including Read, Edit, and Delete) access to the Schedule and Schedule Line objects and tabs.

When creating a custom field, the field creation wizard prompts you to assign field-level access to profiles, but it does not prompt you to assign field-level access to permission sets. After creating a custom field for an object in which permissions are granted via permission sets—and not via profiles—you need to go to each relevant permission set and grant the appropriate field-level access.

Naming

We recommend naming permission sets with a Label in title case and API Name in Pascal case with the format:

Learn more about title case and Pascal case in Component Design Guidelines.

For example, the association acronym for the International Society for the Exceptionally Nimble is ISEN:

• A custom permission set that grants Create permission and View All permission to the Widget object is named ISEN Widget Create and Modify All.
• A custom permission set that grants Manage Salesforce CRM Content permission is named ISEN Manage Salesforce CRM Content.

If listing every permission in the permission set's name affects the clarity of the permission set's purpose because it yields a permission set name that is too long, we recommend writing a brief summary of the permission set's purpose instead.

Adding your association's acronym helps distinguish your association's custom permission sets from permission sets included in  Nimble AMS or other apps. Nimble AMS permission sets are prefixed with Nimble AMS.

Description

The permission set's description is the primary field to write specific information about what is included in the permission set. Be as clear as possible about what is included in the permission set, calling out specific permission names.

For example, the Description for the Nimble AMS Logistic Create and Modify All permission set is Create and Modify All permissions for the Nimble AMS Logistic object, including the tab, all record types, and all fields.

Every time you modify a permission set, remember to update the description accordingly, unless you plan to confound your future self or other administrators.