Experience Cloud Developer Guide

Get Up to Speed with Experience Builder Sites
Develop Experience Builder Sites: The Basics
Brand Your Aura Site
Develop Secure Sites: Authenticated and Guest Users
Limit Declarative Access
Determine a Security Model
Limit Access to Apex Classes
Flow Security
SOQL Injection
Develop Secure Sites: CSP, LWS, and Lightning Locker
Analyze and Improve Experience Builder Site Performance
Add Pardot Tracking to Your Experience Builder Site
Use a CMS with Your Experience Builder Site
Report on Deflections: The Deflection Signals Framework
Deploy an Experience Cloud Site from Sandbox to Production
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Flow Security

If guest or external users must run flows, override the flow permission to grant access only to specific external user profiles, permission sets, or site guest user profiles, rather than allowing users to run all flows. Avoid running flows in system context when possible, and restrict access to subflows. Otherwise, ensure that you implement procedural access controls for those flows and subflows.

Flows are a powerful feature that can override platform security settings for access to objects and Apex classes. Flows can be used to activate and deactivate permission sets. Yet screen flows are driven by the browser with user-controlled input parameters. Therefore, we recommend overriding the run flow permission to assign access to specific flows based on the guest or external user profile or permission set. For guest users, configure flow access policies on the guest user profile for the appropriate site.

It’s also a good security practice to remove permissions to run subflows, even if users run the subflow independently. From a security perspective, it’s better to create two separate flows and give access only to the flow that the user runs directly, and not the one running as a subflow. Grant flow access only to the highest-level parent flow and not to the subflows. The same recommendation can apply to invocable Apex methods called by flows. Avoid granting user access to those classes, so that calling those methods is limited to only the flows that they were meant to be called from.

Be aware that if a user has permission to run a screen flow, they can:
  • Invoke the flow at any time and with parameters of their choosing.
  • Cancel the flow at any time.

These considerations also apply to subflows, or flows called from other flows.

In particular, flow users can:
  • View and modify the input (start) variables to a screen flow.
  • View output variables returned from a screen subflow to the parent flow.
  • If they have permission to run the subflow, modify input variables to subflows.

If any of these abilities violates your security policy, don’t use subflows. For example, if billing information or other sensitive information that must be kept confidential is handled by subflows. Keep business logic in the main flow.