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 code a new rule? → See How to Write a Rule
ActionCallsInLoop – To prevent exceeding Apex governor limits, it is advisable to consolidate and bulkify your apex calls, utilizing a single action call containing a collection variable at the end of the loop.
Severity: 🔴 Error
APIVersion – Introducing newer API components may lead to unexpected issues with older versions of Flows, as they might not align with the underlying mechanics. Starting from API version 50.0, the Api Version attribute has been readily available on the Flow Object. To ensure smooth operation and reduce discrepancies between API versions, it is strongly advised to regularly update and maintain them.
Severity: 🟡 Warning
AutoLayout – With Canvas Mode set to Auto-Layout, elements are spaced, connected, and aligned automatically, keeping your Flow neatly organized—saving you time.
Severity: 🔵 Note
CopyAPIName – Maintaining multiple elements with a similar name, like Copy_X_Of_Element, can diminish the overall readability of your Flow. When copying and pasting these elements, remember to update the API name of the newly created copy.
Severity: 🟡 Warning
CyclomaticComplexity – The number of loops and decision rules, plus the number of decisions. Use a combination of 1) subflows and 2) breaking flows into multiple concise trigger-ordered flows to reduce cyclomatic complexity within a single flow, ensuring maintainability and simplicity.
Severity: 🔵 Note
DMLStatementInLoop – To prevent exceeding Apex governor limits, consolidate all your database operations—record creation, updates, or deletions—at the conclusion of the flow.
Severity: 🔴 Error
DuplicateDMLOperation – When a flow executes database changes or actions between two screens, prevent users from navigating backward between screens; otherwise, duplicate database operations may be performed.
Severity: 🟡 Warning
FlowName – The readability of a flow is paramount. Establishing a naming convention significantly enhances findability, searchability, and overall consistency. Include at least a domain and a brief description of the flow’s actions, for example Service_OrderFulfillment.
Severity: 🔴 Error
GetRecordAllFields – Following the principle of least privilege (PoLP), avoid using Get Records with “Automatically store all fields” unless necessary.
Severity: 🟡 Warning
HardcodedId – Avoid hard-coding IDs because they are org specific. Instead, pass them into variables at the start of the flow—via merge-field URL parameters or a Get Records element.
Severity: 🔴 Error
HardcodedUrl – Avoid hard-coding URLs because they are environment specific. Use an $API formula (preferred) or environment-specific sources like custom labels, metadata, or settings.
Severity: 🔴 Error
InactiveFlow – Like cleaning out your closet: deleting unused flows is essential. Inactive flows can still cause trouble—such as accidentally deleting records during testing, or being activated as subflows.
Severity: 🟡 Warning
MissingFaultPath – A flow may fail to execute an operation as intended. By default, the flow displays an error to the user and emails the creator. Customize this behavior by incorporating a Fault Path.
Severity: 🟡 Warning
MissingFilterRecordTrigger – Record-triggered flows that lack filters on changed fields or entry conditions can lead to unnecessary executions on every record change. This may degrade system performance, hit governor limits faster, and increase resource consumption in high-volume orgs. Severity: 🟡 Warning
FlowDescription – Descriptions play a vital role in documentation. It is highly recommended to include details about where a flow is used and its intended purpose.
Severity: 🔴 Error
MissingMetadataDescription – Flags Flow elements (Get Records, Assignments, Decisions, Actions, etc.) and metadata components (Variables, Formulas, Constants, Text Templates) that lack a description. Adding concise descriptions greatly improves readability, maintainability, and helps AI tools understand your automation intent.
Severity: 🔴 Error
MissingNullHandler – When a Get Records operation finds no data, it returns null. Validate data by using a Decision element to check for a non-null result.
Severity: 🟡 Warning
ProcessBuilder – Salesforce is transitioning away from Workflow Rules and Process Builder in favor of Flow. Begin migrating your organization’s automation to Flow.
Severity: 🟡 Warning
RecordIdAsString – Detects flows using a String variable named recordId as input when they could receive the entire record object instead. Since recent Salesforce releases, record pages and quick actions can pass the complete record, eliminating the need for an additional Get Records query and improving performance.
Severity: 🔵 Note
RecursiveAfterUpdate – After-update flows are meant for modifying other records. Using them on the same record can cause recursion. Consider before-save flows for same-record updates.
Severity: 🟡 Warning
SameRecordFieldUpdates – Similar to triggers, before-save contexts can update the same record via $Record without invoking DML.
Severity: 🟡 Warning
SOQLQueryInLoop – To prevent exceeding Apex governor limits, consolidate all SOQL queries at the end of the flow.
Severity: 🔴 Error
TransformInsteadOfLoop – Detects Loop elements that directly connect to Assignment elements. Transform elements handle collection manipulation in bulk operations, providing significant performance improvements over iterative loop-assignment patterns.
Severity: 🔵 Note
TriggerOrder – Guarantee your flow execution order with the Trigger Order property introduced in Spring ’22.
Severity: 🔵 Note
UnconnectedElement – Avoid unconnected elements that are not used by the flow to keep flows efficient and maintainable.
Severity: 🟡 Warning
UnsafeRunningContext – This flow is configured to run in System Mode without Sharing, granting all users permission to view and edit all data. This can lead to unsafe data access.
Severity: 🔴 Error
UnusedVariable – To maintain efficiency and manageability, avoid including variables that are never referenced.
Severity: 🟡 Warning
It is recommend to configure and define:
- The rules to be executed.
- The severity of violating any specific rule.
- Rule properties such as REGEX expressions.
- Any known exceptions that should be ignored during scanning.
{ "rules": { // Your rules here }, "exceptions": { // Your exceptions here } }Most Lightning Flow Scanner distributions automatically resolve configurations from .flow-scanner.yml, .flow-scanner.json, or package.json → flowScanner.
By default, all default rules are executed. You can customize individual rules and override the rules to be executed without having to specify every rule. Below is a breakdown of the available attributes of rule configuration:
{ "rules": { "<RuleName>": { "severity": "<Severity>", // Override severity level "expression": "<Expression>", // Override rule expression "enabled": "false" // Disable this rule } } }When the severity is not provided it will be warning by default. Other available values for severity are error and note. Define the severity per rule as shown below:
{ "rules": { "FlowDescription": { "severity": "error" }, "UnusedVariable": { "severity": "note" } } }Some rules have additional attributes to configure, such as the expression, that will overwrite default values. These can be configured in the same way as severity as shown in the following example.
{ "rules": { "APIVersion": { "expression": "===58" // comparison operator }, "FlowName": { "expression": "[A-Za-z0-9]" // regular expression } } }Specifying exceptions allows you to exclude specific scenarios from rule enforcement. Exceptions can be specified at the flow, rule, or result level to provide fine-grained control. Below is a breakdown of the available attributes of exception configuration:
{ "exceptions": { "<FlowName>": { "<RuleName>": [ "<ResultName>", // Suppress a result "*", // Wildcard to suppress all results ... ] }, ... } }Example
{ "exceptions": { "MyFlow": { "HardcodedId": ["Old_Lookup_1"] "MissingNullHandler": ["*"], } } }New rules are introduced in Beta mode before being added to the default ruleset. To include current Beta rules, enable the optional betamode parameter in your configuration:
{ "betaMode": true }By default, Lightning Flow Scanner runs all default rules and merges any custom configurations you provide. This means you can override specific rules without having to list every rule to be executed. If instead, you want to run only the rules you explicitly specify, use "ruleMode": "isolated":
{ "ruleMode": "isolated" }| Distribution | Best for | Install / Use |
|---|---|---|
| Salesforce CLI Plugin | Local development, scratch orgs, CI/CD | sf plugins install lightning-flow-scanner |
| VS Code Extension | Real-time scanning inside VS Code | code --install-extension ForceConfigControl.lightning-flow-scanner-vsx |
| Salesforce App (Managed Package) | Run scans directly inside a Salesforce org | sf package install --package 04tgK0000007M73QAE |
| Core Library (Node.js + Browser) | Custom tools, scripts, extensions, web apps | npm install -g @flow-scanner/lightning-flow-scanner-core |
Privacy: Zero user data collected. All processing is client-side. → See our Security Policy.
Ready-to-use CI/CD templates and a native GitHub Action.
| Platform | Template Type | Link |
|---|---|---|
| Azure DevOps | Full Project Scan | azure-pipelines-flow-FullScan.yml |
| Azure DevOps | Change-Based Scan | azure-pipelines-flow-changedFiles.yml |
| GitHub Action | Native PR checks | GitHub Marketplace |
| Copado Plugin | Copado CI/CD pipelines | Copado Marketplace |
GitHub Action Snippet:
- name: Lightning Flow Scan id: flowscanner uses: Flow-Scanner/lightning-flow-scanner@main - name: Upload SARIF to Code Scanning uses: github/codeql-action/upload-sarif@v3 with: sarif_file: ${{ steps.flowscanner.outputs.sarifPath }}To see the full example, see scan-flows.yml.
Use lightning-flow-scanner in the Salesforce CLI:
sf flow:scan # scan flows in current directory sf flow:fix -d src/force-app # fix flows in force-app directory sf flow:scan --sarif > report.sarif # get results as SARIF file sf flow scan --csv > results.csv # get results as CSV fileUse our side bar or the Command Palette and type flowscanner to see all available commands:
Configure Flow Scanner- Set up rules in.flow-scanner.ymlScan Flows- Analyze a directory or selected flow filesFix Flows- Automatically apply available fixesFlow Scanner Documentation- Open the rules reference guide
Use lightning-flow-scanner-core as a Node.js/browser dependency:
// Basic import { parse, scan } from "@flow-scanner/lightning-flow-scanner-core"; parse("flows/*.xml").then(scan); // Get SARIF output import { parse, scan, exportSarif } from "@flow-scanner/lightning-flow-scanner-core"; parse("flows/*.xml").then(scan).then(exportSarif); // Browser Usage (Tooling API) const { Flow, scan } = window.lightningflowscanner; const metadataRes = await conn.tooling.query(`SELECT Id, FullName, Metadata FROM Flow`); const results = scan( metadataRes.records.map((r) => ({ uri: `/services/data/v60.0/tooling/sobjects/Flow/${r.Id}`, flow: new Flow(r.FullName, r.Metadata), })) //, optionsForScan );This project optionally uses Volta to guarantee the exact same Node.js and tool versions for every contributor.
MacOs/Linux:
curl https://get.volta.sh | bashWindows:
winget install Volta.VoltaVolta will automatically install and lock the tool versions defined in
package.json.
-
Clone the repository
git clone https://github.com/Flow-Scanner/lightning-flow-scanner.git
-
Install dependencies:
pnpm install
-
Compile:
pnpm run build
To compile just the core package::
pnpm build:core
-
Run tests:
pnpm testOr to test a new version of the core:
pnpm test:core
-
Linking the core module locally(Optional):
To link the module, run:
pnpm link --global @flow-scanner/lightning-flow-scanner-core
You can now do Ad-Hoc Testing with node:
node -i -e "import('@flow-scanner/lightning-flow-scanner-core').then(m => { Object.assign(global, m.default ? m.default : m); console.log('✅ Core loaded! Try: await parse(...), scan(...), etc.'); })"Or test in a dependent project with
npm link @flow-scanner/lightning-flow-scanner-core -
Deploy Demo Flows (Optional):
cd example-flows && sf project deploy start
Navigate to the Demo Readme for full details
-
Create a standalone UMD Module(Optional):
pnpm dist
This creates UMD at
dist/lightning-flow-scanner-core.umd.js.
Want to help improve Lightning Flow Scanner? See our Contributing Guidelines