Mute Permissions in Permission Set Groups

Learning Objectives

After completing this unit, you’ll be able to:

• Describe why you might mute a permission.
  
• Mute permissions in a permission set group.
  

Accessibility

This unit requires some additional instructions for screen reader users. To access a detailed screen reader version of this unit, click the link below:

Open Trailhead screen reader instructions.

What Is Muting?

Earlier in this module, you learned that permission set groups allow you to bundle permission sets together based on job functions. A permission set group includes all of the permissions in its included permission sets. And you can include a permission set in more than one permission set group.  

Hmmm. Let’s pause here. The ability to include permission sets in more than one permission set group offers a lot of flexibility. However, what if you don’t want to assign all of the permissions in a given permission set to users in a permission set group? 

Muting permission sets let you customize a permission set group by disabling (muting) selected permissions in it. You can have up to one muting permission set per permission set group and mute object, field, and user permissions and other access settings.

With muting permission sets, you get greater reusability, because you can avoid creating similar permission sets with slightly different permissions to meet each user’s individual needs. Consider including all permissions related to a task or feature in the permission set that your different users require. Then, use a muting permission set in the persona-based permission set group to ensure that users have only the permissions they need for their role.

For example, you create a Service Reps permission set group and want to add an existing Case Management permission set to it. However, this permission set contains the Delete object permission for Cases, which you don’t want the users assigned to the Service Reps permission set group to have.

To solve this issue, create a muting permission set to mute just the Delete object permission before you add the Case Management permission set to the Service Reps permission set group. That way, users have only the permissions they need via the Case Management permission set. There’s no need to modify the existing permission set, which could inadvertently affect other users, or create a new permission set, which could make your access configuration harder to manage over time.

Muting Permission Set Considerations

As you can see, muting offers you great flexibility when you design your permissions model. As you plan how to configure your permission set groups, keep these behavior considerations in mind for how muting permission interact with other features:

• When you mute a permission in a permission set group, the muting affects only users assigned to the permission set group.
  
• Users assigned directly to a permission set outside of the permission set group aren’t affected.
  
• If a user is assigned a permission set group that has muted permissions, but the user is assigned the same permissions via a profile, permission set, or different permission set group, the user still has these permissions despite the muting permission set.
  
• Both the User Access Summary and Permission Set Group Summary take muting permission sets into consideration when determining what permissions are enabled.
  

Try Muting Out

There’s nothing like experimenting with a new feature to really understand how it works. The Sales Processing permission set group that you created for E.J. earlier in this module contains two permission sets. 

1. Sales Orders Permission Set, with permissions to:
   

• Activate orders
  
• Read, create, edit, and delete orders
  

2. Sales Contracts Permission Set, with permissions to:
   

• Read, create, edit, and delete contracts
  

Alyssa from the Contracts department has users that need to work with sales contracts. Alyssa’s users need to:

• Read, create, edit, delete, view all, and modify all contracts
  
• Delete activated contracts
  

You could create permission sets specifically for Alyssa. But let’s pause, because it might make sense to reuse an existing permission set—specifically the Sales Contracts permission set. Reusing works because both teams have tasks that involve contracts, even though people in the two teams have different job functions.

The glitch is that the Sales Contracts permission set lacks some permissions that Alyssa’s users need. And if you simply added these additional permissions to Sales Contracts, users assigned to the Sales Processing permission set group would have permissions they don’t need.

Are you stuck? No way! Remember that permission set groups are flexible and you can use muting permission sets to make sure users have only the permissions that they require. Here’s the plan.

1. Mute the permissions that the users assigned to the Sales Processing permission set group shouldn’t have by creating a muting permission set. Do this first. Why? You want to avoid giving this permission set group’s assigned users access to the broader permissions for contracts that Alyssa’s team needs (even temporarily). By creating the muting permission set first, you maintain the integrity of the permission set group for Max.
   
2. Update the Sales Contracts permission set by adding the permissions that Alyssa needs for her team.
   
3. Create a new Contracts Processing permission set group for Alyssa’s team. Add the updated Sales Contracts permission set.
   

Let’s start. If you haven’t already completed the steps in Unit 2, do that first or you won’t be able to do this activity.

Create a muting permission set.

1. From Setup, in Quick Find type Permission Set Groups and then select Permission Set Groups.
   
2. Click Sales Processing—the permission set group you created in Unit 2.
   
3. Under Permission Sets click Muting Permission Set in Group.
   
4. Click New.
   
5. For label use Contracts Permissions Muted.
   
6. For API Name, use Contracts_Permissions_Muted.
   
7. Save the muting permission set.
   

Select permissions to mute.

1. Click the name of your muting permission set.
   
2. In the Find Settings box, enter Contracts, and then select Contracts.
   
3. Click Edit.
   
4. Mute the View All and Modify All object permissions.
   
   
5. Save your changes.
   
6. In the Find Settings box, enter Contracts, and then select Delete Activated Contracts.
   
7. Click Edit.
   
8. Under Sales, mute the Delete Activated Contracts permission.
   
   
9. Save your changes.
   

Now when you add the permissions for Alyssa’s group to the Sales Contracts permission set, they’ll be muted in the Sales Processing permission set group. Let’s add Alyssa’s permissions to the Sales Contracts permission set. Enable these permissions in the Sales Contracts permission set:

1. Delete Activated Contracts app (user) permission
   
2. View All and Modify All object permissions for contracts
   

When you’re ready to create the Contracts Processing permission set group for Alyssa, you can add the Sales Contracts permission set to it. Members will receive all enabled permissions, including Delete Activated Contracts and View All and Modify All for the Contracts object. Voila!

Muting and Permission Dependencies

When you mute permissions in muting permission sets, dependent permissions are also affected. For example, suppose that you grant users Create, Read, Edit, Delete, View All, and Modify All permissions for an object. Now, if you mute the Read permission, Create, Edit, Delete, View All, and Modify All are also muted because users can’t perform those tasks without the ability to read the data.

That example is fairly straightforward, but dependencies can get tricky. When you mute permissions, pay attention to the permission change confirmation message when you save your changes. For example, when muting permissions in the Sales Contracts permission set, if you had muted Activate Contracts, then Delete Activated Contracts would have been muted as well.

As you work with your permission set groups, keep permission dependencies in mind to avoid removing permissions from users who need them. For more information on permission set group muting dependencies, see Salesforce Help.

Muting in Installed Packages

We have one more benefit of muting permission sets to share. If you subscribe to a managed package, you can mute permissions in permission set groups for features that you’re not ready to adopt yet.

For example, let’s say you create a permission set group and then add a managed permission set, installed from a managed package, to it. You receive an automatic update from the independent software vendor (ISV) for the package, but you aren’t ready to enable a new field that’s now available in the managed permission set. Is this a problem? No. You can receive the update and the benefits it offers but mute this field permission until you’re ready to adopt it for your org.

Nice job! You now know about muting permission sets and have a complete picture of permission set groups. You learned all the benefits of using permission set groups and how to design your permissions model to make use of their flexibility and reusability.

Resources

• Salesforce Help: Muting Permission Sets