Security Considerations for Flow Design | Secure Coding Guide

Develop Flows Securely

Flows act like global classes and don’t have any IP protections for flow code. Create flow code carefully, as any code on the subscriber org can invoke the flow in any context.

Use Subflows

Use subflows to modularize your processes and control execution context. You can run a main flow in User Mode and run privileged operations in a System Mode subflow. For example, your main flow creates an opportunity in User Mode, and the subflow assigns ownership in System Mode.

Dividing flows into privileged and unprivileged portions is recommended.

Unprivileged portions run in User mode.
Privileged portions run in System Mode and can be placed into subflows.

For example, to avoid duplicates, run the duplicate detection search in a privileged subflow while running the lead insertion flow in User Mode.

Use an Appropriate Execution Context

Choosing the execution context of a flow helps in determining the context of any CRUD flow element.

User Mode returns the records for which the user has permissions. CRUD/FLS rules are automatically applied.
System Mode With Sharing returns the records that are shared with the user as the sharing rules are applied. CRUD/FLS rules aren’t enforced in this mode.
System Mode Without Sharing returns all records. This mode is only for specific use cases, such as guest user scenarios, where additional security validations are in place.

If no context is set, the default context is used. For flows invoked via UI, the default mode is User Mode. Any other flow runs in System Mode Without Sharing by default.

Explicitly setting the execution context is recommended. The execution context is determined by the advanced "Run in Mode" settings that are controlled by the flow author and by how the flow is invoked. If invoked from an Apex class, the flow inherits the execution context of the calling Apex code and typically runs in system mode. In any other case, the flow follows the configured flow settings.

Note

Use Apex for Custom Access Control Logic

Implement procedural access control policies in Apex. Passing control to Apex helps in implementing custom access action control logic as a number of utility functions to manage permissions are available, such as usermode and stripInaccessible.

For details on how to implement procedural authorization checks for org users, see Apex Security and Sharing. For Experience Cloud site users, especially guest users, go to Guest User Record Access Development Best Practices for examples of custom control.

Set User Mode for UI Flows

Screen flows must run in User Mode to ensure that the flow respects the user’s permissions and follows the org security policies.

Validate Flow Inputs

Validate all variables marked as “available for inputs” in the same way as user input in any other code.

Handle Record-Triggered Flows

Record-triggered flows run in system mode and are commonly used for data validation and automation tasks. Flows launched from Apex inherit the execution context of the calling Apex code.

Limit the functionalities performed in record-triggered flows.
Ensure that the flows don’t modify unrelated records in the triggered flows. If records that aren’t related to the record triggering the flow are being modified, enforce user authorization control on the unrelated record.

Document Flow Functionality

Document flows to understand their functionalities better. As flows increase in number, it can become difficult to keep track of them. To help document flows, follow these guidelines.

Use clear and informative names for flows and subflows.
Use consistent naming conventions to identify the execution context, mode, and other details about the flow.

Implement Regular Reviews

To ensure that security standards are consistently followed, regularly review your flows and subflows, especially after changes or when new flows are deployed .