flow-linter is a static configuration analysis tool that enforces Flow best practices.
Salesforce Flows are a powerful way to automate processes, but without proper guardrails, they can quickly become hard to maintain, error-prone, and inconsistent.
JavaScript has ESLint, Apex has PMD, but what about Flows? flow-linter brings the same rigor of linting and static code analysis—familiar to developers working with JavaScript or Apex—to Salesforce Flows.
Default Rules
Action Calls In Loop
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.
Outdated API Version
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.
Auto Layout
AutoLayout - With Canvas Mode set to Auto‑Layout, elements are spaced, connected, and aligned automatically, keeping your Flow neatly organized—saving you time.
Copy API Name
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.
Cyclomatic Complexity
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.
DML Statement In A Loop
DMLStatementInLoop - To prevent exceeding Apex governor limits, consolidate all your database operations—record creation, updates, or deletions—at the conclusion of the flow.
Duplicate DML Operation
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.
Flow Naming Convention
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.
Get Record All Fields
GetRecordAllFields - Following the principle of least privilege (PoLP), avoid using Get Records with “Automatically store all fields” unless necessary.
Hardcoded Id
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.
Hardcoded Url
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.
Inactive Flow
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.
Missing Fault Path
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.
Missing Flow Description
FlowDescription - Descriptions play a vital role in documentation. We highly recommend including details about where flows are used and their intended purpose.
Missing Null Handler
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.
Process Builder
ProcessBuilder - Salesforce is transitioning away from Workflow Rules and Process Builder in favor of Flow. Begin migrating your organization’s automation to Flow.
Recursive After Update
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.
Same Record Field Updates
SameRecordFieldUpdates - Similar to triggers, before‑save contexts can update the same record via $Record without invoking DML.
SOQL Query In A Loop
SOQLQueryInLoop - To prevent exceeding Apex governor limits, consolidate all SOQL queries at the end of the flow.
Trigger Order
TriggerOrder - Guarantee your flow execution order with the Trigger Order property introduced in Spring ’22.
Unconnected Element
UnconnectedElement - Avoid unconnected elements that are not used by the flow to keep flows efficient and maintainable.
Unsafe Running Context
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.
Unused Variable
UnusedVariable - To maintain efficiency and manageability, avoid including variables that are never referenced.
Core Functions
getRules(ruleNames?: string[]): IRuleDefinition[]
Retrieves rule definitions used in the scanner.
parse(selectedUris: any): Promise<ParsedFlow[]>
Parses metadata from selected Flow files.
scan(parsedFlows: ParsedFlow[], ruleOptions?: IRulesConfig): ScanResult[]
Runs rules against parsed flows and returns scan results.
fix(results: ScanResult[]): ScanResult[]
Attempts to apply automatic fixes where available.
Configurations
Rule Configuration
Advanced rules provide granular control by allowing rules to be intentionally disabled at the rule level, ensuring consistent application across all flows. Additionally, the concept of suppressions is introduced, enabling users to "whitelist" specific components. This mechanism allows for exceptions to be defined, offering flexibility in rule enforcement while maintaining overall governance and compliance.
JSON
{
"rules": {
"<RuleName>": {
"path": "local_path_of_your_js_file", // optional: when defined, this configuration will be used for the engine to recognize your custom rule
"severity": "error",
"expression": ">=58",
"disabled": "true", // optional: when true, rule will not be applied to all flows being scanned
"suppressions": ["LogACall"] // optional: when defined, takes an array of suppressed elements (not based on name but on specific type)
}
}
}
YAML
rules:
MissingFaultPath: # User Defined Rule configuration
path: "local_path_of_your_js_file" # Optional: when defined, this configuration will be used for the engine to recognize your rule
severity: error # Optional: User Defined severity, can be `info`, `warn`, `error`
expression: ">=58" # Optional: User defined expression, only applies if rule is Configurable=true
disabled: "true" # Optional: when true, rule will not be applied to all flows being scanned
suppressions: # Optional: when defined, takes an array of elements to be suppressed, keys can be found on suppressionElements on the rule definition
- LogACall # Optional: when defined, rule engine will look at suppressionElement defined on the rule to match against this list
-
Severity:
- Optional values for severity are "error", "warning", and "note".
- If severity is provided, it overwrites the default severity, which is "error".
-
Expression:
- Expression is used to overwrite standard values in configurable rules.
-
Path:
- If a path is provided, it can either replace an existing rule with a new rule definition or load a custom rule.
- Ensure that the rule name used in the path matches the exported class name of the rule.
Custom Rule Interface
To create custom rules that can be loaded using the path attribute of the rule configurations, they need to adhere to the IRuleInterface. Please refer to the Custom Rule Creation Guide for detailed instructions.
Exception Configuration
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>",
...
]
},
...
}
}
-
FlowName:
- The name of the flow where exceptions apply.
-
RuleName:
- The name of the rule for which exceptions are defined.
-
ResultName:
- The specific result or condition within the rule for which exceptions are specified.
Development Setup
-
Clone the repo:
git clone https://github.com/corekraft/flow-linter-core.git -
Install dependencies:
npm install -
Build the project:
npm run build -
Run tests:
npm run test -
(Optional) Deploy sample flows:
npm run deploy:flows -- -o