After completing this unit, you’ll be able to:
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.
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.
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:
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.
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.
Select permissions to mute.
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. Remember, first activate the link for Back to Permission set Groups. Then, under the Permission Sets heading, activate the link for Permission Sets in Group. Find the Sales Contract permission set in the table and press ENTER on it before looking for these settings in the Find Settings box.
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!
Let’s add Elisa’s permissions to the Sales Contracts permission set. Enable these
permissions in the Sales Contracts permission set. Remember, first activate the link for Back to Permission set Groups. Then, under the Permission Sets heading, activate the link
for Permission Sets in Group. Find the Sales Contract permission set in the table and press ENTER on it before looking for these settings in the Find Settings box.
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!
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.
As you work with your permission set groups, keep permission dependencies in mind to avoid removing permissions from users who need them.
Click to return to the unit on Trailhead to access your challenge at the end of the reading.