Flow Scanner Rules Reference

The Flow Scanner rules help you identify security issues in your flows. To select these rules, use --rule-selector flow. For example, to run all the Flow Scanner rules:

Description: This rule finds CRUD (Create, Read, Update, Delete) operations in which user controlled data either determines which Salesforce records are selected for the CRUD operation, or in which user controlled data can modify the data of the selected records. This happens in flows that run in System Context Without Sharing.

If your flow violates this rule, the user running the flow can gain higher privileges and perform actions on records that they shouldn't have access to. This is a security risk known as a privilege escalation vulnerability.

Default Severity: High (2)

Default Tags: Recommended, Security, Xml

How to Fix: The best fix is to change the run context of your flow from System Context Without Sharing to User Context. See Change the Flow Run Context for details.

If you can't change the run context of your flow, you must implement your own procedural access control checks using decision elements and custom Apex actions; see the next section for helpful resources.

False Positive Guidance: A flow sometimes causes a violation of this rule, but the violation might be a false positive. This section provides guidance on what causes a false positive, and when you can safely ignore it.

In the following two use cases, the flow is required to run in System Context (either with or without sharing) for its secure operation:

  • The flow is public-facing and used by external guests or community users, and you intend that these users perform limited operations on records that they don't have access to.
  • The flow code modifies or accesses only custom fields that are owned by your app and you're intentionally ignoring the platform access control policies.

To safely ignore these two use cases as false positives, you must provide an alternative access control policy in the flow itself or in an Apex action called from the flow. You can't ignore the platform access control policy without building your own procedural replacement, because bypassing platform access checks places the burden on the flow developer of ensuring appropriate custom access checks are performed.

Additional resources:

Description: This rule finds CRUD (Create, Read, Update, Delete) operations in which user controlled data either determines which Salesforce records are selected for the CRUD operation, or in which user controlled data can modify the data of the selected records. This happens in flows that run in System Context With Sharing.

If your flow violates this rule, the user running the flow can gain higher privileges and perform actions on records that they shouldn't have access to. This is a security risk known as a privilege escalation vulnerability.

Default Severity: Low (4)

Default Tags: Recommended, Security, Xml

How to Fix: The best fix is to change the run context of your flow from System Context With Sharing to User Context. See Change the Flow Run Context for details.

If you can't change the run context of your flow, you must implement your own procedural access control checks using decision elements and custom Apex actions; see the next section for helpful resources.

False Positive Guidance: A flow sometimes causes a violation of this rule, but the violation might be a false positive. This section provides guidance on what causes a false positive, and when you can safely ignore it.

In the following two use cases, the flow is required to run in System Context (either with or without sharing) for its secure operation:

  • The flow is public-facing and used by external guests or community users, and you intend that these users perform limited operations on records that they don't have access to.
  • The flow code modifies or accesses only custom fields that are owned by your app and you're intentionally ignoring the platform access control policies.

To safely ignore these two use cases as false positives, you must provide an alternative access control policy in the flow itself or in an Apex action called from the flow. You can't ignore the platform access control policy without building your own procedural replacement, because bypassing platform access checks places the burden on the flow developer of ensuring appropriate custom access checks are performed.

Additional resources:

Description: This rule detects circular subflow references, where a flow calls a subflow that eventually calls the original flow again, either directly or through a chain of subflows. The Salesforce flow runtime doesn't allow cyclic subflows so these flows can fail.

Default Severity: Critical (1)

Default Tags: Recommended, Performance, Xml

How to Fix:

  • Map your flow architecture and identify the full circular dependency path.
  • Refactor your flows to remove the circular reference by using one of these approaches.
    • Remove one of the subflow calls to break the cycle.
    • Create a new parent flow that orchestrates the logic without circular dependencies.
    • Move shared logic into a reusable subflow that never calls back to its parent flows.
  • For complex recursive logic, consider using Apex actions with explicit termination conditions instead of recursive flow calls.

False Positive Guidance: This rule rarely produces false positives. If you use recursive flow calls, implement the logic in Apex instead, where you can control recursion depth and termination conditions directly.

Description: This rule identifies database operations that run inside a loop such as Get Records, Create Records, Update Records, Delete Records. Database operations in loops are critical performance operations that can quickly consume org governor limits. Each database call counts against per-transaction limits. For example, 150 DML statements and 100 SOQL queries per transaction. When these operations run inside loops, you can easily exceed these limits, especially with larger datasets.

Default Severity: High (2)

Default Tags: Recommended, Performance, Xml

How to Fix:

  • Use collection variables instead of per-record operations.
  • Before the loop, use a single Get Records element with the all records option to load records into a collection.
  • In the loop, process items in the collection without additional queries.
  • After the loop, use bulk Create Records, Update Records, or Delete Records on the full collection by using the IN operator.
  • Modify records in a collection with Assignment elements instead of using individual Update Records elements in the loop.

False Positive Guidance: This rule rarely produces false positives. Database operations in loops require refactoring to a bulk pattern.

Description: This rule flags assignment elements that use the default Copy label created by the platform when a flow element is copy and pasted within Flow Builder. These default labels are placeholders that the developer must update prior to publishing the flow. Labels are an important device for documenting flow elements. Additionally, the developer is responsible for reviewing each field and setting in the copied element to avoid accidentally using unintended fields and settings.

Default Severity: Moderate (3)

Default Tags: Recommended, CodeStyle, Xml

How to Fix:

  • After copying a flow element, review the element label and all fields to verify they have the appropriate label, and then update any that don’t.

False Positive Guidance: This rule rarely has false positives. Remove default labels and replace them with real labels after copying a flow.

Description: This rule detects hardcoded Salesforce record IDs in flows. Hardcoded IDs are org-specific. For example, they differ between sandbox and production and can break when you deploy flows to other orgs or when records are recreated. Hardcoding IDs can lead to deployment failures and broken flows in production.

Default Severity: Moderate (3)

Default Tags: Recommended, BestPractices, Xml

How to Fix:

  • Use Get Records with field criteria instead of an ID. For example, query by name or another unique field such as an external ID.
  • Use the $User global variable for the current user or use Get Records to find a user by Username or Email![alt]( '{"class": "", "title": ""}').
  • Use DeveloperName instead of a hardcoded ID. If you need the ID, query RecordType by DeveloperName and SObjectType.
  • Store configuration in Custom Metadata Types or Custom Settings. Query records by DeveloperName, which is consistent across orgs.
  • Query Group records by DeveloperName or Name instead of using an ID.

False Positive Guidance: This rule rarely has false positives. If you hardcode an ID for a quick test or for a single-org flow with no deployment plans, you can ignore this warning. For production use, avoid hardcoded IDs.

Description: This rule flags flows and flow resources such as elements, variables, and other metadata that don’t have descriptions. Descriptions improve flow maintainability, especially when you collaborate on a team or revisit older logic. Missing descriptions don’t break run-time behavior, but they reduce maintainability and make reviews and troubleshooting more difficult.

Default Severity: Low (4)

Default Tags: CodeStyle, Xml

How to Fix:

  • Use the Flow Description field to explain what the flow does and when it runs.
  • Add a short description that explains the purpose of the step and why it exists.
  • Describe what each variable, formula, and resource stores or calculates and how it’s used in the flow.
  • Keep descriptions clear and concise, and focus on the why rather than repeating what the label already says.

False Positive Guidance: Ignore this warning for simple, short-lived flows for example, quick sandbox experiments. For production flows, adding descriptions is strongly recommended.

Description: This rule flags flows that don’t have fault paths for elements that can fail, such as Get Records, Create Records, Update Records, Delete Records, flow actions, and subflow elements. Without fault handlers, flow exceptions are not caught and throws an error with generic error messages resulting in a poor user experience and limited error logging. Fault handlers help you address errors gracefully, allowing the flow to recover or at least to show meaningful messages to users, and capture error details for troubleshooting or retry logic.

Default Severity: High (2)

Default Tags: BestPractices, Xml

How to Fix:

  • Add fault paths for flow elements that can trigger a fault: DML operations, subflows, and flow actions. Each of these elements must have dedicated error-handling logic.
  • Select an error-handling pattern
    • User-facing flows: Route faults to a Screen element with a clear, user-friendly error message
    • Background flows: Create a record in a custom error log object or another tracking mechanism
    • Critical operations: Send an email or another alert to admins or support
    • Transactional flows: Route to logic that rolls back or adjusts related work, or provides an alternative path
  • Use the $Flow.FaultMessage global variable to capture and display or log detailed error information
  • Consider using a reusable error-handling subflow so you can apply consistent patterns across flows

False Positive Guidance: For low-risk operations where failures are acceptable and don't affect users, you can choose not to add a fault handler.