Detect unsafe contexts, queries in loops, hardcoded IDs, and more to optimize Salesforce Flows
📌Tip: To link directly to a specific rule, use the full GitHub anchor link format. Example:
https://flow-scanner.github.io/lightning-flow-scanner/#unsafe-running-context
Want to help improve this project? See our Contributing Guidelines
These rules detect anti-patterns and unsafe practices in your Flows that could break functionality, compromise security, or cause deployment failures.
Executing DML operations (insert, update, delete) inside a loop is a high-risk anti-pattern that frequently causes governor limit exceptions. All database operations should be collected and executed once, outside the loop.
Rule ID: dml-in-loop
Class Name: DMLStatementInLoop
Severity: 🔴 Error
Avoid hard-coding record IDs, as they are unique to a specific org and will not work in other environments. Instead, store IDs in variables—such as merge-field URL parameters or a Get Records element—to make the Flow portable, maintainable, and flexible.
Rule ID: hardcoded-id
Class Name: HardcodedId
Severity: 🔴 Error
Avoid hardcoding secrets, API keys, tokens, or credentials in Flows. These should be stored securely in Named Credentials, Custom Settings, Custom Metadata, or external secret management systems.
Rule ID: hardcoded-secret
Class Name: HardcodedSecret
Severity: 🔴 Error
Avoid hard-coding URLs, as they may change between environments or over time. Instead, store URLs in variables or custom settings to make the Flow adaptable, maintainable, and environment-independent.
Rule ID: hardcoded-url
Class Name: HardcodedUrl
Severity: 🔴 Error
Process Builder is retired. Continuing to use it increases maintenance overhead and risks future compatibility issues. Migrating automation to Flow reduces risk and improves maintainability.
Rule ID: process-builder-usage
Class Name: ProcessBuilder
Severity: 🔴 Error
Running SOQL queries inside a loop can rapidly exceed query limits and severely degrade performance. Queries should be executed once, with results reused throughout the loop.
Rule ID: soql-in-loop
Class Name: SOQLQueryInLoop
Severity: 🔴 Error
Flows configured to run in System Mode without Sharing grant access to all data, bypassing user permissions. Avoid this setting to prevent security risks and protect sensitive data.
Rule ID: unsafe-running-context
Class Name: UnsafeRunningContext
Severity: 🔴 Error
When a Flow performs database operations across multiple screens, users navigating backward can cause the same actions to run multiple times. To prevent unintended changes, either restrict backward navigation or redesign the Flow so database operations execute in a single, forward-moving step.
Rule ID: duplicate-dml
Class Name: DuplicateDMLOperation
Severity: 🟡 Warning
Elements that can fail should include a Fault Path to handle errors gracefully. Without it, failures show generic errors to users. Fault Paths improve reliability and user experience.
Rule ID: missing-fault-path
Class Name: MissingFaultPath
Severity: 🟡 Warning
Get Records operations return null when no data is found. Without handling these null values, Flows can fail or produce unintended results. Adding a null check improves reliability and ensures the Flow behaves as expected.
Rule ID: missing-null-handler
Class Name: MissingNullHandler
Severity: 🟡 Warning
After-save Flows that update the same record can trigger recursion, causing unintended behavior or performance issues. Avoid updating the triggering record in after-save Flows; use before-save Flows instead to prevent recursion.
Rule ID: recursive-record-update
Class Name: RecursiveAfterUpdate
Severity: 🟡 Warning
These rules highlight areas where Flows can be improved. Following them increases reliability and long-term maintainability.
Repeatedly invoking Apex actions inside a loop can exhaust governor limits and lead to performance issues. Where possible, bulkify your logic by moving the action call outside the loop and passing a collection variable instead.
Rule ID: action-call-in-loop
Class Name: ActionCallsInLoop
Severity: 🟡 Warning
Avoid using Get Records to retrieve all fields unless necessary. This improves performance, reduces processing time, and limits exposure of unnecessary data.
Rule ID: get-record-all-fields
Class Name: GetRecordAllFields
Severity: 🟡 Warning
Inactive Flows should be deleted or archived to reduce risk. Even when inactive, they can cause unintended record changes during testing or be activated as subflows. Keeping only active, relevant Flows improves safety and maintainability.
Rule ID: inactive-flow
Class Name: InactiveFlow
Severity: 🟡 Warning
Flows running on outdated API versions may behave inconsistently when newer platform features or components are used. From API version 50.0 onward, the API Version attribute explicitly controls Flow runtime behavior. Keeping Flows aligned with a supported API version helps prevent compatibility issues and ensures predictable execution.
Rule ID: invalid-api-version
Class Name: APIVersion
Severity: 🟡 Warning
| Option | Type | Default | Description |
|---|---|---|---|
| expression | expression | >= 50 |
Comparison expression for API version (e.g., >= 58, < 50, === 60) |
Record-triggered Flows without filters on changed fields or entry conditions execute on every record change. Adding filters ensures the Flow runs only when needed, improving performance.
Rule ID: missing-record-trigger-filter
Class Name: MissingFilterRecordTrigger
Severity: 🟡 Warning
Before-save Flows can safely update the triggering record directly via $Record, applying changes efficiently without extra DML operations. Using before-save updates improves performance
Rule ID: same-record-field-updates
Class Name: SameRecordFieldUpdates
Severity: 🟡 Warning
Flows with deeply nested loops and decisions are hard to understand. Unlike cyclomatic complexity which counts paths, cognitive complexity penalizes nesting depth. Consider extracting nested logic into subflows.
Rule ID: cognitive-complexity
Class Name: CognitiveComplexity
Severity: 🔵 Note
| Option | Type | Default | Description |
|---|---|---|---|
| threshold | number | 15 |
Maximum cognitive complexity score before triggering a violation |
High numbers of loops and decision elements increase a Flow's cyclomatic complexity. To maintain simplicity and readability, consider using subflows or splitting a Flow into smaller, ordered Flows.
Rule ID: excessive-cyclomatic-complexity
Class Name: CyclomaticComplexity
Severity: 🔵 Note
| Option | Type | Default | Description |
|---|---|---|---|
| threshold | number | 25 |
Maximum cyclomatic complexity score before triggering a violation |
Record-triggered Flows without a specified Trigger Order may execute in an unpredictable sequence. Setting a Trigger Order ensures your Flows run in the intended order.
Rule ID: unspecified-trigger-order
Class Name: TriggerOrder
Severity: 🔵 Note
Flows that use a String variable for a record ID instead of receiving the full record introduce unnecessary complexity and additional Get Records queries. Using the complete record simplifies the Flow and improves performance.
Rule ID: record-id-as-string
Class Name: RecordIdAsString
Severity: 🔵 Note
Loop elements that perform direct Assignments on each item can slow down Flows. Using Transform elements allows bulk operations on collections, improving performance and reducing complexity.
Rule ID: transform-instead-of-loop
Class Name: TransformInsteadOfLoop
Severity: 🔵 Note
Focused on naming, documentation, and organization, these rules ensure Flows remain clear, easy to understand, and maintainable as automations grow.
Using clear and consistent Flow names improves readability, discoverability, and maintainability. A good naming convention helps team members quickly understand a Flow's purpose—for example, including a domain and brief description like Service_OrderFulfillment. Adopt a naming pattern that aligns with your organization's standards.
Rule ID: invalid-naming-convention
Class Name: FlowName
Severity: 🔴 Error
| Option | Type | Default | Description |
|---|---|---|---|
| expression | expression | [A-Za-z0-9]+_[A-Za-z0-9]+ |
Regex pattern for valid Flow names |
Flow descriptions are essential for documentation and maintainability. Include a description for each Flow, explaining its purpose and where it's used.
Rule ID: missing-flow-description
Class Name: FlowDescription
Severity: 🔴 Error
Elements and metadata without a description reduce clarity and maintainability. Adding descriptions improves readability and makes your automation easier to understand.
Rule ID: missing-metadata-description
**Class Name
$ claude mcp add lightning-flow-scanner \
-- python -m otcore.mcp_server <graph>