Skip to main content

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.
Note

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. 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.

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 lets you customize a permission set group by muting (disabling) selected permissions in it. To mute a permission, you add the permission to a muting permission set in the selected permission set group. When you mute a permission in a permission set group, the muting affects only users assigned to the permission set group, not users assigned directly to a permission set outside of the permission set group. So, muting offers you great flexibility when you design your permissions model. 

Moreover, if you subscribe to a managed package, you can mute permissions in groups for features that you’re not ready to adopt yet. For example, let’s say that you have a local 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 anything in permission set groups that you’re not ready to adopt for your org. 

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, with permissions to:
    • Activate orders
    • Read, create, edit, and delete orders
  2. Sales Contracts, with permissions to:
    • Read, create, edit, and delete contracts

Diagram corresponding to the preceding description of the Sales Processing permission set group.

Elisa from the Contracts department has users that need to work with sales contracts. Previously, you assigned profiles to users who needed specific object permissions. But the company is growing, and you want to move away from using profiles to assign permissions. Let’s see what you can do for Elisa. 

Elisa’s users need to:

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

You could create permission sets specifically for Elisa. But let’s pause, because it might make sense to reuse a permission set from the Sales Processing permission set group. 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 in the Sales Processing permission set group lacks some permissions that Elisa’s users need. 

Are we stuck? No way! Remember that permission set groups are flexible and allow you to reuse permission sets. Here’s the plan.

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

Venn diagram depicting the Sales Processing permission set group and the Contracts Processing permission set group, with a circle representing a muted permission set pointing to Sales Processing.

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 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 Elisa’s group to the Sales Contracts permission set, they’ll be muted in the Sales Processing permission set group. 

Let’s add Elisa’s permissions to the Sales Contracts permission set. Enable these permissions in the Sales Contracts permission set:

  1. Enable the Delete Activated Contracts permission.
  2. Enable the View All and Modify All permissions for contracts.

When you’re ready to create a permission set group for Elisa, you can add the Sales Contracts permission set to it. Members will receive the Delete Activated Contracts and View All and Modify All for the Contracts object. Voila!

Venn diagram showing the Sales Processing and Contracts Processing permission set groups. The overlapping area contains the Sales Contracts permission set, indicating that it’s included in both permission set groups. A muting permission set within the Sales Processing permission set group affects only the Sales Processing permission set group, not the other permission sets within the permission set group.

Muting and Permission Dependencies

When you mute permissions, keep permission dependencies in mind. For example, suppose that you grant all users Create, Read, Edit, and Delete permissions for an object. Then you grant some users View All and Modify All for that 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.

Permission Changes Confirmation message showing that both Delete Activated Contracts and Activate Contracts will be muted. 

As you work with your permission set groups, keep permission dependencies in mind to avoid removing permissions from users who need them.

Resources

Keep learning for
free!
Sign up for an account to continue.
What’s in it for you?
  • Get personalized recommendations for your career goals
  • Practice your skills with hands-on challenges and quizzes
  • Track and share your progress with employers
  • Connect to mentorship and career opportunities