UMD-compatible Flow metadata engine for Node.js & browsers—20+ rules to catch issues.
đź“Ś Tip: To link directly to a specific rule, use the full GitHub anchor link format. Example:
https://github.com/Flow-Scanner/lightning-flow-scanner-core#unsafe-running-context
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.
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.
AutoLayout - With Canvas Mode set to Auto‑Layout, elements are spaced, connected, and aligned automatically, keeping your Flow neatly organized—saving you time.
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.
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.
DMLStatementInLoop - To prevent exceeding Apex governor limits, consolidate all your database operations—record creation, updates, or deletions—at the conclusion of the flow.
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.
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.
GetRecordAllFields - Following the principle of least privilege (PoLP), avoid using Get Records with “Automatically store all fields” unless necessary.
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.
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.
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.
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.
FlowDescription - Descriptions play a vital role in documentation. We highly recommend including details about where flows are used and their intended purpose.
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.
ProcessBuilder - Salesforce is transitioning away from Workflow Rules and Process Builder in favor of Flow. Begin migrating your organization’s automation to Flow.
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.
SameRecordFieldUpdates - Similar to triggers, before‑save contexts can update the same record via $Record without invoking DML.
SOQLQueryInLoop - To prevent exceeding Apex governor limits, consolidate all SOQL queries at the end of the flow.
TriggerOrder - Guarantee your flow execution order with the Trigger Order property introduced in Spring ’22.
UnconnectedElement - Avoid unconnected elements that are not used by the flow to keep flows efficient and maintainable.
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.
UnusedVariable - To maintain efficiency and manageability, avoid including variables that are never referenced.
It is recommended to set up configuration 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
}
}Using the rules section of your configurations, you can specify the list of rules to be run. Furthermore, you can define the severity and configure expressions of rules. Below is a breakdown of the available attributes of rule configuration:
{
"rules": {
"<RuleName>": {
"severity": "<Severity>",
"expression": "<Expression>"
}
}
}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": {
"severity": "error",
"expression": "===58" // comparison operator
},
"FlowName": {
"severity": "note",
"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>",
"<ResultName>",
...
]
},
...
}
}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:
{
"rules": {
...
},
"exceptions": {
...
},
"betamode": true
}lightning-flow-scanner-core can be used as a dependency in Node.js and browser environments, or as a standalone UMD module.
// Basic
import { parse, scan } from "@flow-scanner/lightning-flow-scanner-core";
parse("flows/*.xml").then(scan);
// Apply available patches
import { parse, scan, fix } from "@flow-scanner/lightning-flow-scanner-core";
parse("flows/*.xml").then(scan).then(fix);
// Get SARIF output
import { parse, scan, exportSarif } from "@flow-scanner/lightning-flow-scanner-core";
parse("flows/*.xml").then(scan).then(exportSarif); //.then((sarif) => save("results.sarif", sarif));
// 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
);Retrieves rule definitions used in the scanner.
Loads Flow XML files into in-memory models.
Runs all enabled rules and returns detailed violations.
Automatically applies available fixes(removing variables and unconnected elements).
Get flattened output of violations only.
Get SARIF output including exact line numbers of violations.
lightning-flow-scanner-core is scanned with Snyk prior to publication on npm.
To install with npm:
npm install @flow-scanner/lightning-flow-scanner-coreThis project optionally uses Volta to manage Node.js versions. Install Volta with:
curl https://get.volta.sh | bashVolta will automatically use the Node.js version defined in
package.json.
-
Clone the repo:
git clone https://github.com/Flow-Scanner/lightning-flow-scanner-core.git
-
Install dependencies:
npm install
-
Build the project:
npm run build
-
Run tests:
npm run test -
Test as local dependency(Optional): To test changes to the core module locally, run:
npm run link
b) Go to the dependent project (e.g. VSX or CLI) and use:
npm link @flow-scanner/lightning-flow-scanner-core
Your local module will now replace any installed version and update on rebuild.
-
Create a standalone UMD Module(Optional):
npm run vite:dist // creates UMD at`dist/lightning-flow-scanner-core.umd.js`.
![@dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=64&v=4){kind=small}
