If you’ve been a Salesforce Admin for a while, you’ll likely recognise this pattern – you purchase a new Salesforce feature, read the guide which says to assign the Permission Set License and matching Salesforce-provided Permission Set, assign them, then your users get access. Everything works, and you move on to the next task.
But here’s the catch – those “out-of-the-box” Permission Sets from Salesforce may be granting far more access than you realize. In today’s climate, where Salesforce security is under the spotlight, ignoring these defaults could expose your org to unnecessary risk.
Why Reviewing Permission Sets Matters
When you install a managed package from an ISV on the AppExchange, the included Permission Sets are usually restricted from granting core Salesforce permissions. Salesforce’s own Permission Sets, however, do not have that limitation.
That means a standard Salesforce-provided Permission Set could be quietly enabling powerful permissions like API Enabled or Manage Flows without you realizing it. For Admins who pride themselves on carefully curated Profiles and Permission Sets, this can feel like a back door you didn’t mean to leave open.
A Note on Responsible Disclosure
Before we dive in, it’s important to highlight Salesforce’s responsible disclosure policy. If you discover what you believe to be a security vulnerability, you should report it directly to Salesforce at security@salesforce.com.
The examples in this article have not been classified as vulnerabilities by Salesforce’s security team when reported. Instead, they fall into the “shared responsibility” category where Salesforce provides the tools, but it’s up to you to configure them securely for your org.
Case Study: Sales Engagement Basic User
Let’s start with the SalesEngagementBasicUser Permission Set, which you can find in your Trailhead Playground orgs as well as many production ones. The name has ‘User’ in it, and the description suggests this is for accessing the basics. However, if you look closely, this Permission Set contains the ‘Run Flows’ App Permission. This allows the user to run any active flow.
Why This Matters
Flows can be configured to operate under the System Context, allowing them to reach far beyond a standard user’s permissions. They can also be triggered via the REST API, allowing an attacker who has gained access to an account to extend their reach far beyond the limitations imposed. Put simply, when a user can run a flow without limitations or considerations to context and business processes, it opens a door to abuse not only internally but also from external threats.
Some teams have built screen flow-based administration control panels to allow a reduction in permissions granted for everyday use, yet still provide access to controlled processes for more junior administrators or external contractors via Screen Flows running under a system context. Unwittingly providing access to these flows for a greater number of users in an organization is unlikely to be intentional.
Many administrators are getting ready for the Winter ‘26 changes, restricting user access to flows, and yet may be surprised to learn that their carefully crafted list of per-flow permissions may be subverted.
How to Lock it Down
Since you can not edit Salesforce-provided Permission Sets directly, the solution is to use Permission Set Groups with Muting Permission Sets:
- Create a new Permission Set for the flows you do want users to be able to run. I use the name ‘Sales Engagement Flow Access’, but you are free to use your own naming scheme.
- Add both this Permission Set and SalesEngagementBasicUser to a new Permission Set Group. I use ‘Sales Engagement’ – again, the freedom is yours to use another name.
- Create a Muting Permission Set within the group to mute the Run Flows permission.
- Assign the Permission Set Group instead of the default Permission Set to your users.
- Use the ‘View Summary’ feature to ensure only the permissions you intended to provide are present and that there are no surprises.
This way, you preserve the functionality Salesforce intended, but without the risky default where all flows can be run.
Another Example: Revenue Cloud Advanced
Sales Engagement is not the only culprit. In Revenue Cloud Advanced, one of Salesforce’s newest products, not only do some Permission Sets provide Run Flows, but some also grant Manage Flows. It cannot be overstated how powerful a permission that allows users to view, create, edit, delete, and activate all flows is, especially in the wrong hands.
Some Permission Sets, like DRO Admin User, at least warn you in the description that this is intended for System Administrators. Others, like Fulfilment Designer, suggest it’s for end users and ‘gives users access’, despite including the same elevated access.
Again, the fix is the same:
- Add the built-in Permission Set to a Permission Set Group.
- Apply a Muting Permission Set to omit the Manage Flows permission.
- Assign the Permission Set Group instead of the default Permission Set.
- Verify the permissions granted using ‘View Summary’.
Key Takeaways for Admins
- Never assume Salesforce defaults are safe for your org. Review every Permission Set before assigning it, and make the right choices for your security model.
- Use Permission Set Groups with Muting Permission Sets to neutralise risky permissions that you do not wish to grant.
- Test in a sandbox first. Muting permissions can have unexpected side effects, so validate thoroughly before rolling out to production.
- Stay vigilant – security is a shared responsibility. Salesforce provides the tools, but it’s up to you to configure them responsibly.
Final Thoughts
Salesforce’s provided Permission Sets are designed to make feature adoption easier, but convenience can come at the cost of security. By taking the time to review and adjust these defaults, you can protect your org from unnecessary exposure without slowing down your users.
In today’s environment, where Salesforce org breaches are making headlines, this extra diligence isn’t optional. It’s essential. Stay safe.
