Salesforce Flow governance: who builds, activates and runs your flows

Flow is now where most Salesforce automation lives, and in many orgs it is also where most unreviewed change lives. An Apex class needs test coverage and usually a code review before it reaches production. A flow can be built, activated and exposed to a public site by one person with the right permission, in an afternoon, with nothing in the pipeline to notice.

Salesforce Flow governance is the process that closes that gap: who may build, activate and run flows, in what context, and how changes are reviewed. For the technical failure modes (run modes, guest-run flows, record ids from the URL), see our earlier post on Salesforce Flow security. This one is about the process around them.

#Who can build and activate flows?

The Manage Flow user permission lets a user open Flow Builder, create and edit flows, and activate them. Treat it as an administrator-grade permission. A user who can build a flow can build one that runs in system context without sharing, and that flow reads and writes records regardless of the running user's access. It is privileged automation without code.

Governance questions to settle:

• Who holds Manage Flow in production? Ideally a small group of administrators, granted through a permission set rather than a profile so assignments are visible and easy to review.
• Is production the place flows are built? Building in a sandbox and deploying through your release process gives you version control, review and a rollback. Building in production gives you none of those.
• Who may activate? Activation is the moment a flow starts affecting data. Some teams separate the person who builds from the person who approves activation, even if Salesforce lets one user do both.

The Setup Audit Trail shows after the fact who changed what. It is a record, not a control.

#Who can run flows: Run Flows and the Flow User checkbox

Running a flow is a separate question from building one. Historically a user needed either the Run Flows user permission or the Flow User checkbox on their user record. The Flow User checkbox is a feature license on the user detail page, and it is the setting people mean when they search for the "flow user checkbox".

This is an access-control topic, not just a licensing one. A user with Run Flows can run any flow they can reach unless the flow restricts access itself, and a flow can be set to override the default behaviour and restrict access to specific profiles and permission sets. For any flow that touches sensitive data or runs in system context, use that setting.

Salesforce has a release update titled "Restrict User Access to Run Flows" that narrows who holds Run Flows by default. Its enforcement date has moved more than once, so check its current status under Release Updates in your org rather than relying on a date you read elsewhere.

#Run mode is a governance decision

Every flow runs in user context, system context with sharing, or system context without sharing. Some types have fixed defaults (record-triggered and schedule-triggered flows run in system context), and others, like screen flows, can be switched. That switch is a single setting in Flow Builder and the runInMode element in metadata.

Treat it like an access grant: default new screen and autolaunched flows to user context, require a written reason and a reviewer for system context, and call out run mode changes in every deployment. A move to SystemModeWithoutSharing is a privilege change even if no other line moved.

#Screen flows exposed to guests

A screen flow placed on a public Experience Cloud page runs as the site's guest user. In user context, the guest's tightly limited access applies. In system context, the flow can read and write records no anonymous visitor should touch, and if the record it acts on comes from a URL parameter or a screen field, the visitor chooses it.

Governance here is simple to state: list every flow reachable from a public page, run each in user context unless there is a documented exception, and have someone other than the builder review each exception whenever the flow changes.

Our Experience Cloud guest user security checklist covers the rest of the guest surface.

#Apex actions invoked from flows

An @InvocableMethod called from a flow runs according to its class's sharing keyword and query mode, not according to the flow's run mode alone. A user-context flow that calls a without sharing invocable class still reaches past sharing inside that action. Salesforce has also published a release update about Apex actions respecting the flow's user context, so check how it applies in your org.

So a flow change that adds an Apex action brings that class into review.

#A Salesforce Flow governance checklist

1. Inventory. Every active flow has an owner, a purpose, a trigger type and a run mode on record.
2. Build permission. Manage Flow in production is held by a named, reviewed group through a permission set.
3. Change path. Flows are built in a sandbox and deployed through the same pipeline and review as Apex.
4. Run permission. Sensitive or system-context flows restrict access to specific profiles or permission sets.
5. Run mode. System context needs a documented reason and a second reviewer, and run mode changes are called out in deployments.
6. Guest exposure. Every flow reachable from a public site is listed and runs in user context unless an exception is approved.
7. Apex actions. Every invocable class a flow calls has a sharing keyword and enforces object and field access.
8. Error handling. Data, query and action elements have fault paths, so failures are visible rather than silent.
9. Hygiene. Inactive, orphaned and outdated flows are retired on a schedule.
10. Audit. Flow activations and permission changes are reviewed from the Setup Audit Trail on a regular cycle.

#Where Vulkro for Salesforce fits

Most of this checklist can be checked against metadata in your repository, which is what vulkro-sf scan does with every *.flow-meta.xml file. Rules relevant to governance include:

• flow-runinmode-elevated: a flow running in system context, or with no runInMode, so the implicit context depends on the trigger type.
• flow-runinmode-system-mode-recordcreates, -recordupdates and -recorddeletes: each DML element in a system-mode flow.
• SF-GUEST-FLOW-001: a guest-granted screen flow in system mode that selects its record from a URL, launch input or screen field.
• flow-missing-fault-connector: a data, query or action element with no fault path.

For the inventory, vulkro-sf flowmap maps how flows connect to subflows, Apex classes and objects, and the opt-in hygiene checks (VULKRO_SF_HYGIENE=1) report orphan flows and an automation inventory. vulkro-sf readiness includes rows for the "Restrict User Access to Run Flows" and Apex-action release updates.

vulkro-sf scan ./force-app
vulkro-sf flowmap ./force-app --format mermaid > flowmap.mmd
VULKRO_SF_HYGIENE=1 vulkro-sf scan ./force-app

The full list is on the Flow detectors page.

#FAQ

#What is the Flow User checkbox in Salesforce?

It is a feature license on the user record that lets a user run flows. Today most orgs grant the Run Flows permission through profiles or permission sets instead, and restrict sensitive flows to specific permission sets.

#What is the difference between Manage Flow and Run Flows?

Manage Flow lets a user build, edit and activate flows. Run Flows lets a user run them. Manage Flow is the more powerful of the two, because a builder can create a flow that runs in system context.

#How do you govern Salesforce flows?

Limit who holds Manage Flow, build in a sandbox and deploy through review, restrict sensitive flows to specific permission sets, require approval for system context, and keep a list of every guest-reachable flow.

See how Vulkro checks flows alongside Apex and metadata on the Vulkro for Salesforce page, or start a 14-day trial from /start/.