Salesforce Permission Set Groups: Understanding the Muting File
Photo credit: luis gomes

Salesforce Permission Set Groups: Understanding the Muting File

As we shift our focus toward Permission Set Groups and Muting in Salesforce, and with the eventual phasing out of profiles, it is imperative to delve deeper into understanding how muting works, especially its underlying mechanisms. For those new to muting, it's a process where you utilize a Permission Set Group containing individual permission sets to selectively remove specific permissions without altering the underlying permission sets. This approach ensures the high reusability of your permission sets, reducing redundancy and simplifying your permission management.

Why delve into the intricacies of XML when the Salesforce UI offers an apparently user-friendly solution? This is a valid question, and the answer lies in the advantages that a profound understanding of the XML file structure can offer. Particularly for those who frequently work with tools like Visual Studio Code (VS Code), grasping the XML file can save a significant amount of time compared to configuring permissions via the UI.

Here are some compelling reasons to consider:

  1. Differences in Org Shape: In cases where your working environment, such as a scratch org, differs significantly from your production or sandbox instances, the permissions and muting settings may contain items not present in your higher-level environments. Understanding the XML structure allows you to easily identify and eliminate unnecessary permissions and deploy only the changes you require. (What's Org Shape?)
  2. Testing AppExchange Apps: When experimenting with new AppExchange apps in your sandbox or scratch orgs, you may create permission sets, permission set groups, and use muting to silence permissions in bulk. It can be cumbersome to revert these changes if you inadvertently grant permissions you no longer need. Additionally, you may not be ready to uninstall the AppExchange app. In this scenario, working with the XML file makes it easier to locate and delete specific permissions.

These are precisely the reasons why I embarked on the journey to understand how the muting XML file functions.

Reading the Muting XML File

Assuming your baseline permissions are at the admin level, and you start removing permissions using the Muting file, here's how you interpret it:

System and App Permissions

In the context of system permissions and app permissions, if a permission exists in your XML file, it indicates that it is muted. To provide users with a specific system permission, you should remove it from the muting file.

For e.g. you have a system permission of API Enabled. If this code exists in your muting file, it means that users assigned this permission set group, will not have API Enabled.

<userPermissions>
        <enabled>true</enabled>
        <name>ApiEnabled</name>
</userPermissions>        

So, to make sure your users have API Enabled, remove the above code in your muting file. I understand its not difficult to remove one or two permissions using the UI but lets say you have tons of permissions to be removed, especially if there is a pattern. For example, I had to remove all AI Insights from the muting because this didn't exist in higher environments. So using Find in VS Code, I was able to easily locate all instances of AI Insights and remove the file.

Object Permissions

For object permissions, consider a permission set that grants users the ability to Create, Read, Edit, Delete, View All, and Modify All. If you want your users to have Read, Create, and Edit permissions for Accounts, your muting file must have the opposite settings.

<allowCreate>false</allowCreate>
<allowRead>false</allowRead>
<allowEdit>false</allowEdit>        

Essentially, you are ensuring that users can now Read, Create, and Edit Accounts by unmuting these permissions.

Assigned Apps:

When dealing with App Visibilities, applications you want muted will have "True," and those you want visible to users will have "False."

<applicationVisibilities>
  <application>blng__QuotetoCash</application>
  <visible>true</visible>
</applicationVisibilities>        

In the example above, you are ensuring that users cannot access the "blng__QuotetoCash" app.

To manage and deploy metadata efficiently, we use tools like VS Code and Git Actions. Understanding how muting files work is invaluable in this context. Although comprehending and reading XML is not the same as writing code, it's a crucial skill for software consultants, as it allows for effective configuration and management of Salesforce permissions. As a mentor once said, "Software consultants must know XML and HTML."

Scott Covert

Salesforce permissions pro helping admins enforce best practices

2 个月

Thanks for the deep dive on a topic that doesn't get enough attention. I agree that PSGs will be much more wide-spread over the next few years and the muting file is a key component to understand!

Thanks Alekhya, I love these!

要查看或添加评论,请登录

社区洞察

其他会员也浏览了