Salesforce Permissions: Scalable Distribution with Permission Sets

Salesforce recently rescinded its decision to retire profile-based permissions. While this may seem like a reprieve, the core challenges associated with distributing permissions via profiles persist. This guide outlines a robust strategy for managing permissions using permission sets and permission set groups, emphasizing scalability and the principle of least privilege.

The Limitations of Profiles

Historically, profiles have served as the primary mechanism for distributing permissions. The traditional approach involved cloning profiles for elevated access and using permission sets as supplementary 'band-aid' solutions. However, profiles present several significant drawbacks:

• Deployment Complexity: Profiles are notoriously difficult to deploy, even with advanced tooling.
• Limited Flexibility: Each user can only be assigned a single profile, restricting granular control and making it challenging to implement the principle of least privilege.

Permission sets offer a more granular and flexible alternative, allowing users to be assigned multiple permission sets as needed.

Retaining Profile Functionality

While the goal is to shift away from profile-centric permission management, profiles still have specific use cases. They should continue to manage:

• Record Type and App Defaults
• Page Layout Assignments
• Login Hours and IP Range Restrictions

All other permissions should ideally be transitioned to permission sets.

Distributing Permissions with Permission Sets

Implementing a structured approach to permission sets is crucial for scalability. Consider the following strategy:

1. Establish a Uniform Structure: Define a consistent naming convention and structure for your permission sets across the org to facilitate long-term maintenance.

2. Granular Permission Sets: Create at least two permission sets per object as a baseline: Read Only and Full Access. These should grant field-level access, excluding sensitive or privileged fields.

   For example:

   • MyObject__c Read Only
   • MyObject__c Full Access
   • Meridian App Access (for Lightning App access)

Leveraging Permission Set Groups

Manually assigning individual permission sets to users is unsustainable for large organizations. Permission set groups provide a solution by allowing you to bundle related permission sets.

1. Map User Roles or Tasks: Define user roles or the specific tasks users need to perform within the system.

2. Create Role/Task-Based Groups: Group relevant permission sets into permission set groups that align with these roles or tasks.

   For example, a Portfolio Director permission set group might include:

   • MyObject__c Read Only permission set
   • Meridian App Access permission set

This approach streamlines user onboarding and permission management. Furthermore, multiple permission set groups can be assigned to a single user, offering greater flexibility than single-profile assignments. This is particularly beneficial for Independent Software Vendors (ISVs) managing permissions for their applications.

Managing Sensitive Permissions

For highly sensitive or privileged data, create specific permission sets that are not part of general permission set groups. These should be assigned directly to a limited number of users.

Muting Permission Sets

In complex permission scenarios, Muting Permission Sets can be used to explicitly deny a specific permission to a user, overriding other assignments.

Key Takeaways

• While Salesforce has halted profile permission retirement, the underlying issues necessitate a move towards more granular permission management.
• Utilize permission sets for granular control over object and field access.
• Employ permission set groups to bundle permission sets for specific roles or tasks, streamlining assignment.
• Adhere strictly to the principle of least privilege in all permission distribution strategies.
• Reserve profiles for essential configurations like app defaults, page layouts, and login policies.
• Muting Permission Sets offer a mechanism to explicitly deny permissions.