Is there a way to limit which Flow Actions users can see or execute based on their permissions?
For example, users with a Marketeer permission set should only be able to see/use actions related to Marketing Cloud Next and Data Cloud, such as Send Email Message and Execute Data Cloud SQL Query, but not actions such as Delete Records.
The goal is twofold:
- Keep the Flow Builder action list relevant and less cluttered for different groups of users.
- Control which types of Flows different users are allowed to build.
If it isn't possible to hide specific Flow Actions, would it be possible to prevent users from activating a Flow if it contains restricted actions
?
Has anyone implemented something similar, perhaps using Custom Permissions, Permission Sets, or another Salesforce security mechanism?
N
o, Salesforce doesn't give you native, permission-set-based control over which actions appear in the Flow Builder palette. What you're describing (hiding "Delete Records" from a Marketeer persona while showing "Send Email Message"/Data Cloud actions) isn't supported out of the box, and this has been a long-standing IdeaExchange request rather than a shipped feature.To be precise about what does exist vs. what doesn't:
What Flow security features actually control
- "Run Flows" permission / flow-level "Override default behavior" → gates who can execute a specific named flow. Doesn't touch the builder's action palette at all.
- "Manage Flow" permission → binary: you either can open Flow Builder and use every standard element/action in the palette, or you can't. There's no sub-permission that trims the palette per persona.
- Winter '25's "Restrict User Access to Run Flows" release update → same story, it's about running flows, not building with restricted actions.
So there's no supported mechanism not Custom Permissions, not Permission Sets that grays out or hides specific standard core actions (Delete Records, Update Records, etc.) inside the builder canvas for one persona but not another.
How this is actually handled in real orgs- Don't give "Marketeer" personas raw Manage Flow access. If the goal is "these users should only be able to build Marketing Cloud Next / Data Cloud flows," the reliable pattern is: admins own Flow Builder access org-wide, and marketing users get a curated Screen Flow or subflow (built by admins, using only the intended actions) surfaced to them via a Lightning page/App not open-canvas Flow Builder access at all.
- Use CRUD/FLS as a runtime backstop, not a build-time one. If a flow is set to run in User Context (not the default System Context without sharing for autolaunched flows), a Delete Records element will fail at runtime for a user who lacks delete permission on that object so even if they can drag it onto the canvas, it won't execute destructively. This doesn't stop them from building it, only from it doing anything.
- Governance via CI/CD, not the UI. Add a pre-deployment check (custom script or PMD-style scan) that inspects .flow-meta.xml for disallowed element types (recordDeletes, etc.) authored by non-admin users, and blocks activation/deployment if found. This is the most reliable way to actually enforce "type of flows different users are allowed to build" procedurally, since the platform won't do it declaratively.
- Custom invocable Apex actions can self-gate. If "Execute Data Cloud SQL Query" or similar is a custom Apex-defined invocable action, you can have the Apex check a Custom Permission and throw before executing but that only applies to actions you built yourself, not standard OOTB elements.
Net: treat this as an access-model/governance problem (who gets Flow Builder access at all, and what you let them deploy) rather than something solvable with a permission set toggle inside Flow Builder itself. If you're on a very recent release and want to double check nothing's shipped since I last confirmed this, worth a quick check against current release notes before you finalize the design Flow security has been an active area (three releases a year) and this specific granularity has come up on IdeaExchange repeatedly.
I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.
