@flow-scanner/lightning-flow-scanner-core 6.15.1 → 6.15.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -32,9 +32,11 @@
32
32
  ## Table of contents
33
33
 
34
34
  - **[Default Rules](#default-rules)**
35
+ - [problems](#problems)
36
+ - [suggestions](#suggestions)
37
+ - [layout](#layout)
35
38
  - **[Configuration](#configuration)**
36
39
  - [Configure Rules](#configure-rules)
37
- - [Overwrite Expressions](#overwrite-expressions)
38
40
  - [Define Exceptions](#define-exceptions)
39
41
  - [Exclude Flows](#exclude-flows)
40
42
  - [Scan Modes](#scan-modes)
@@ -53,195 +55,205 @@
53
55
 
54
56
  > Want to code a new rule? → See [How to Write a Rule](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/docs/write-a-rule.md)
55
57
 
56
- <!-- START GENERATED_RULES -->
57
- ### Action Call In A Loop
58
- 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.
59
-
60
- **Rule ID:** `action-call-in-loop`
61
- **Class Name:** _[ActionCallsInLoop](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/ActionCallsInLoop.ts)_
62
- **Severity:** 🟡 *Warning*
63
-
64
- ### DML Statement In A Loop
65
- 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.
66
-
67
- **Rule ID:** `dml-in-loop`
68
- **Class Name:** _[DMLStatementInLoop](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/DMLStatementInLoop.ts)_
69
- **Severity:** 🔴 *Error*
70
-
71
- ### Duplicate DML Operation
72
- 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.
73
-
74
- **Rule ID:** `duplicate-dml`
75
- **Class Name:** _[DuplicateDMLOperation](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/DuplicateDMLOperation.ts)_
76
- **Severity:** 🟡 *Warning*
77
-
78
- ### Excessive Cyclomatic Complexity
79
- 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.
80
-
81
- **Rule ID:** `excessive-cyclomatic-complexity`
82
- **Class Name:** _[CyclomaticComplexity](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/CyclomaticComplexity.ts)_
83
- **Severity:** 🔵 *Note*
84
-
85
- ### Flow Naming Convention
86
- 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.
87
-
88
- **Rule ID:** `invalid-naming-convention`
89
- **Class Name:** _[FlowName](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/FlowName.ts)_
90
- **Severity:** 🔴 *Error*
91
-
92
- ### Get Record All Fields
93
- Avoid using Get Records to retrieve all fields unless necessary. This improves performance, reduces processing time, and limits exposure of unnecessary data.
94
-
95
- **Rule ID:** `get-record-all-fields`
96
- **Class Name:** _[GetRecordAllFields](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/GetRecordAllFields.ts)_
97
- **Severity:** 🟡 *Warning*
98
-
99
- ### Hardcoded Id
100
- 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.
101
-
102
- **Rule ID:** `hardcoded-id`
103
- **Class Name:** _[HardcodedId](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/HardcodedId.ts)_
104
- **Severity:** 🔴 *Error*
105
-
106
- ### Hardcoded Url
107
- 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.
108
-
109
- **Rule ID:** `hardcoded-url`
110
- **Class Name:** _[HardcodedUrl](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/HardcodedUrl.ts)_
111
- **Severity:** 🔴 *Error*
112
-
113
- ### Inactive Flow
114
- 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.
115
-
116
- **Rule ID:** `inactive-flow`
117
- **Class Name:** _[InactiveFlow](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/InactiveFlow.ts)_
118
- **Severity:** 🟡 *Warning*
119
-
120
- ### Invalid API Version
121
- 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.
122
-
123
- **Rule ID:** `invalid-api-version`
124
- **Class Name:** _[APIVersion](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/APIVersion.ts)_
125
- **Severity:** 🟡 *Warning*
126
-
127
- ### Missing Auto Layout
128
- Auto-Layout automatically arranges and aligns Flow elements, keeping the canvas organized and easier to maintain. Enabling it saves time and improves readability.
129
-
130
- **Rule ID:** `missing-auto-layout`
131
- **Class Name:** _[AutoLayout](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/AutoLayout.ts)_
132
- **Severity:** 🔵 *Note*
133
-
134
- ### Missing Fault Path
135
- 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.
136
-
137
- **Rule ID:** `missing-fault-path`
138
- **Class Name:** _[MissingFaultPath](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/MissingFaultPath.ts)_
139
- **Severity:** 🟡 *Warning*
140
-
141
- ### Missing Filter Record Trigger ![Beta](https://img.shields.io/badge/status-beta-yellow)
142
- 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.
143
-
144
- **Rule ID:** `missing-record-trigger-filter`
145
- **Class Name:** _[MissingFilterRecordTrigger](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/MissingFilterRecordTrigger.ts)_
146
- **Severity:** 🟡 *Warning*
147
-
148
- ### Missing Flow Description
149
- Flow descriptions are essential for documentation and maintainability. Include a description for each Flow, explaining its purpose and where it’s used.
150
-
151
- **Rule ID:** `missing-flow-description`
152
- **Class Name:** _[FlowDescription](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/FlowDescription.ts)_
153
- **Severity:** 🔴 *Error*
154
-
155
- ### Missing Metadata Description ![Beta](https://img.shields.io/badge/status-beta-yellow)
156
- Elements and metadata without a description reduce clarity and maintainability. Adding descriptions improves readability and makes your automation easier to understand.
157
-
158
- **Rule ID:** `missing-metadata-description`
159
- **Class Name:** _[MissingMetadataDescription](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/MissingMetadataDescription.ts)_
160
- **Severity:** 🟡 *Warning*
161
-
162
- ### Missing Null Handler
163
- 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.
164
-
165
- **Rule ID:** `missing-null-handler`
166
- **Class Name:** _[MissingNullHandler](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/MissingNullHandler.ts)_
167
- **Severity:** 🟡 *Warning*
168
-
169
- ### Missing Trigger Order
170
- 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.
171
-
172
- **Rule ID:** `unspecified-trigger-order`
173
- **Class Name:** _[TriggerOrder](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/TriggerOrder.ts)_
174
- **Severity:** 🔵 *Note*
175
-
176
- ### Process Builder
177
- 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.
178
-
179
- **Rule ID:** `process-builder-usage`
180
- **Class Name:** _[ProcessBuilder](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/ProcessBuilder.ts)_
181
- **Severity:** 🔴 *Error*
182
-
183
- ### Record ID as String ![Beta](https://img.shields.io/badge/status-beta-yellow)
184
- 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.
185
-
186
- **Rule ID:** `record-id-as-string`
187
- **Class Name:** _[RecordIdAsString](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/RecordIdAsString.ts)_
188
- **Severity:** 🔵 *Note*
189
-
190
- ### Recursive After Update
191
- 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.
192
-
193
- **Rule ID:** `recursive-record-update`
194
- **Class Name:** _[RecursiveAfterUpdate](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/RecursiveAfterUpdate.ts)_
195
- **Severity:** 🟡 *Warning*
196
-
197
- ### Same Record Field Updates
198
- 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
199
-
200
- **Rule ID:** `same-record-field-updates`
201
- **Class Name:** _[SameRecordFieldUpdates](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/SameRecordFieldUpdates.ts)_
202
- **Severity:** 🟡 *Warning*
203
-
204
- ### SOQL Query In A Loop
205
- 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.
206
-
207
- **Rule ID:** `soql-in-loop`
208
- **Class Name:** _[SOQLQueryInLoop](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/SOQLQueryInLoop.ts)_
209
- **Severity:** 🔴 *Error*
210
-
211
- ### Transform Instead of Loop ![Beta](https://img.shields.io/badge/status-beta-yellow)
212
- 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.
213
-
214
- **Rule ID:** `transform-instead-of-loop`
215
- **Class Name:** _[TransformInsteadOfLoop](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/TransformInsteadOfLoop.ts)_
216
- **Severity:** 🔵 *Note*
217
-
218
- ### Unclear API Name
219
- Elements with unclear or duplicated API names, like Copy_X_Of_Element, reduce Flow readability. Make sure to update the API name when copying elements to keep your Flow organized.
220
-
221
- **Rule ID:** `unclear-api-naming`
222
- **Class Name:** _[CopyAPIName](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/CopyAPIName.ts)_
223
- **Severity:** 🟡 *Warning*
224
-
225
- ### Unreachable Element
226
- Unconnected elements never execute and add unnecessary clutter. Remove or connect unused Flow elements to keep Flows clean and efficient.
227
-
228
- **Rule ID:** `unreachable-element`
229
- **Class Name:** _[UnconnectedElement](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/UnconnectedElement.ts)_
230
- **Severity:** 🟡 *Warning*
231
-
232
- ### Unsafe Running Context
233
- 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.
234
-
235
- **Rule ID:** `unsafe-running-context`
236
- **Class Name:** _[UnsafeRunningContext](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/UnsafeRunningContext.ts)_
237
- **Severity:** 🔴 *Error*
238
-
239
- ### Unused Variable
240
- Unused variables are never referenced and add unnecessary clutter. Remove them to keep Flows efficient and easy to maintain.
241
-
242
- **Rule ID:** `unused-variable`
243
- **Class Name:** _[UnusedVariable](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/UnusedVariable.ts)_
244
- **Severity:** 🟡 *Warning*
58
+ <!-- START GENERATED_RULES -->
59
+ ### Problems
60
+
61
+ ### DML Statement In A Loop
62
+ 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.
63
+
64
+ **Rule ID:** `dml-in-loop`
65
+ **Class Name:** _[DMLStatementInLoop](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/DMLStatementInLoop.ts)_
66
+ **Severity:** 🔴 *Error*
67
+
68
+ ### Hardcoded Id
69
+ 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.
70
+
71
+ **Rule ID:** `hardcoded-id`
72
+ **Class Name:** _[HardcodedId](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/HardcodedId.ts)_
73
+ **Severity:** 🔴 *Error*
74
+
75
+ ### Hardcoded Url
76
+ 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.
77
+
78
+ **Rule ID:** `hardcoded-url`
79
+ **Class Name:** _[HardcodedUrl](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/HardcodedUrl.ts)_
80
+ **Severity:** 🔴 *Error*
81
+
82
+ ### Process Builder
83
+ 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.
84
+
85
+ **Rule ID:** `process-builder-usage`
86
+ **Class Name:** _[ProcessBuilder](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/ProcessBuilder.ts)_
87
+ **Severity:** 🔴 *Error*
88
+
89
+ ### SOQL Query In A Loop
90
+ 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.
91
+
92
+ **Rule ID:** `soql-in-loop`
93
+ **Class Name:** _[SOQLQueryInLoop](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/SOQLQueryInLoop.ts)_
94
+ **Severity:** 🔴 *Error*
95
+
96
+ ### Unsafe Running Context
97
+ 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.
98
+
99
+ **Rule ID:** `unsafe-running-context`
100
+ **Class Name:** _[UnsafeRunningContext](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/UnsafeRunningContext.ts)_
101
+ **Severity:** 🔴 *Error*
102
+
103
+ ### Duplicate DML Operation
104
+ 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.
105
+
106
+ **Rule ID:** `duplicate-dml`
107
+ **Class Name:** _[DuplicateDMLOperation](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/DuplicateDMLOperation.ts)_
108
+ **Severity:** 🟡 *Warning*
109
+
110
+ ### Missing Fault Path
111
+ 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.
112
+
113
+ **Rule ID:** `missing-fault-path`
114
+ **Class Name:** _[MissingFaultPath](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/MissingFaultPath.ts)_
115
+ **Severity:** 🟡 *Warning*
116
+
117
+ ### Missing Null Handler
118
+ 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.
119
+
120
+ **Rule ID:** `missing-null-handler`
121
+ **Class Name:** _[MissingNullHandler](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/MissingNullHandler.ts)_
122
+ **Severity:** 🟡 *Warning*
123
+
124
+ ### Recursive After Update
125
+ 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.
126
+
127
+ **Rule ID:** `recursive-record-update`
128
+ **Class Name:** _[RecursiveAfterUpdate](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/RecursiveAfterUpdate.ts)_
129
+ **Severity:** 🟡 *Warning*
130
+
131
+
132
+
133
+ ### Suggestions
134
+
135
+ ### Action Call In A Loop
136
+ 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.
137
+
138
+ **Rule ID:** `action-call-in-loop`
139
+ **Class Name:** _[ActionCallsInLoop](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/ActionCallsInLoop.ts)_
140
+ **Severity:** 🟡 *Warning*
141
+
142
+ ### Get Record All Fields
143
+ Avoid using Get Records to retrieve all fields unless necessary. This improves performance, reduces processing time, and limits exposure of unnecessary data.
144
+
145
+ **Rule ID:** `get-record-all-fields`
146
+ **Class Name:** _[GetRecordAllFields](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/GetRecordAllFields.ts)_
147
+ **Severity:** 🟡 *Warning*
148
+
149
+ ### Inactive Flow
150
+ 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.
151
+
152
+ **Rule ID:** `inactive-flow`
153
+ **Class Name:** _[InactiveFlow](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/InactiveFlow.ts)_
154
+ **Severity:** 🟡 *Warning*
155
+
156
+ ### Invalid API Version
157
+ 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.
158
+
159
+ **Rule ID:** `invalid-api-version`
160
+ **Class Name:** _[APIVersion](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/APIVersion.ts)_
161
+ **Severity:** 🟡 *Warning*
162
+
163
+ ### Missing Filter Record Trigger ![Beta](https://img.shields.io/badge/status-beta-yellow)
164
+ 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.
165
+
166
+ **Rule ID:** `missing-record-trigger-filter`
167
+ **Class Name:** _[MissingFilterRecordTrigger](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/MissingFilterRecordTrigger.ts)_
168
+ **Severity:** 🟡 *Warning*
169
+
170
+ ### Same Record Field Updates
171
+ 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
172
+
173
+ **Rule ID:** `same-record-field-updates`
174
+ **Class Name:** _[SameRecordFieldUpdates](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/SameRecordFieldUpdates.ts)_
175
+ **Severity:** 🟡 *Warning*
176
+
177
+ ### Excessive Cyclomatic Complexity
178
+ 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.
179
+
180
+ **Rule ID:** `excessive-cyclomatic-complexity`
181
+ **Class Name:** _[CyclomaticComplexity](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/CyclomaticComplexity.ts)_
182
+ **Severity:** 🔵 *Note*
183
+
184
+ ### Missing Trigger Order
185
+ 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.
186
+
187
+ **Rule ID:** `unspecified-trigger-order`
188
+ **Class Name:** _[TriggerOrder](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/TriggerOrder.ts)_
189
+ **Severity:** 🔵 *Note*
190
+
191
+ ### Record ID as String ![Beta](https://img.shields.io/badge/status-beta-yellow)
192
+ 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.
193
+
194
+ **Rule ID:** `record-id-as-string`
195
+ **Class Name:** _[RecordIdAsString](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/RecordIdAsString.ts)_
196
+ **Severity:** 🔵 *Note*
197
+
198
+ ### Transform Instead of Loop ![Beta](https://img.shields.io/badge/status-beta-yellow)
199
+ 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.
200
+
201
+ **Rule ID:** `transform-instead-of-loop`
202
+ **Class Name:** _[TransformInsteadOfLoop](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/TransformInsteadOfLoop.ts)_
203
+ **Severity:** 🔵 *Note*
204
+
205
+
206
+
207
+ ### Layout
208
+
209
+ ### Flow Naming Convention
210
+ 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.
211
+
212
+ **Rule ID:** `invalid-naming-convention`
213
+ **Class Name:** _[FlowName](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/FlowName.ts)_
214
+ **Severity:** 🔴 *Error*
215
+
216
+ ### Missing Flow Description
217
+ Flow descriptions are essential for documentation and maintainability. Include a description for each Flow, explaining its purpose and where it's used.
218
+
219
+ **Rule ID:** `missing-flow-description`
220
+ **Class Name:** _[FlowDescription](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/FlowDescription.ts)_
221
+ **Severity:** 🔴 *Error*
222
+
223
+ ### Missing Metadata Description ![Beta](https://img.shields.io/badge/status-beta-yellow)
224
+ Elements and metadata without a description reduce clarity and maintainability. Adding descriptions improves readability and makes your automation easier to understand.
225
+
226
+ **Rule ID:** `missing-metadata-description`
227
+ **Class Name:** _[MissingMetadataDescription](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/MissingMetadataDescription.ts)_
228
+ **Severity:** 🟡 *Warning*
229
+
230
+ ### Unclear API Name
231
+ Elements with unclear or duplicated API names, like Copy_X_Of_Element, reduce Flow readability. Make sure to update the API name when copying elements to keep your Flow organized.
232
+
233
+ **Rule ID:** `unclear-api-naming`
234
+ **Class Name:** _[CopyAPIName](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/CopyAPIName.ts)_
235
+ **Severity:** 🟡 *Warning*
236
+
237
+ ### Unreachable Element
238
+ Unconnected elements never execute and add unnecessary clutter. Remove or connect unused Flow elements to keep Flows clean and efficient.
239
+
240
+ **Rule ID:** `unreachable-element`
241
+ **Class Name:** _[UnconnectedElement](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/UnconnectedElement.ts)_
242
+ **Severity:** 🟡 *Warning*
243
+
244
+ ### Unused Variable
245
+ Unused variables are never referenced and add unnecessary clutter. Remove them to keep Flows efficient and easy to maintain.
246
+
247
+ **Rule ID:** `unused-variable`
248
+ **Class Name:** _[UnusedVariable](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/UnusedVariable.ts)_
249
+ **Severity:** 🟡 *Warning*
250
+
251
+ ### Missing Auto Layout
252
+ Auto-Layout automatically arranges and aligns Flow elements, keeping the canvas organized and easier to maintain. Enabling it saves time and improves readability.
253
+
254
+ **Rule ID:** `missing-auto-layout`
255
+ **Class Name:** _[AutoLayout](https://github.com/Flow-Scanner/lightning-flow-scanner/blob/main/packages/core/src/main/rules/AutoLayout.ts)_
256
+ **Severity:** 🔵 *Note*
245
257
  <!-- END GENERATED_RULES -->
246
258
 
247
259
  ---
@@ -279,12 +291,14 @@ By default, all default rules are executed. You can customize individual rules a
279
291
  "expression": "<Expression>", // Override rule expression
280
292
  "message": "<Message>", // Set custom message
281
293
  "messageUrl": "<URL>", // Set custom documentation URL
282
- "enabled": false // Disable this rule
294
+ "enabled": false, // Disable this rule
283
295
  }
284
296
  }
285
297
  }
286
298
  ```
287
299
 
300
+ #### Configure Severity
301
+
288
302
  When the severity is not provided it will be `warning` by default. Other available values for severity are `error` and `note`. Configure the severity per rule as demonstrated below:
289
303
 
290
304
  ```json
@@ -300,6 +314,25 @@ When the severity is not provided it will be `warning` by default. Other availab
300
314
  }
301
315
  ```
302
316
 
317
+ #### Override Expressions
318
+
319
+ Some rules are configurable and allow overriding their default expressions. You configure these overrides the same way as severity, as shown in the examples below.
320
+
321
+ ```json
322
+ {
323
+ "rules": {
324
+ "invalid-api-version": {
325
+ "expression": "===58" // comparison expression
326
+ },
327
+ "invalid-naming-convention": {
328
+ "expression": "[A-Za-z0-9]" // regular expression
329
+ }
330
+ }
331
+ }
332
+ ```
333
+
334
+ #### Customize Messages
335
+
303
336
  If not provided, `message` shows the standard rule summary and `messageUrl` links to the README; providing either overrides the default behavior.
304
337
 
305
338
  ```json
@@ -313,18 +346,15 @@ If not provided, `message` shows the standard rule summary and `messageUrl` link
313
346
  }
314
347
  ```
315
348
 
316
- ### Overwrite Expressions
349
+ #### Disable Rules
317
350
 
318
- Some rules are configurable and allow overriding their default expressions. You configure these overrides the same way as severity, as shown in the examples below.
351
+ To disable a rule, set `"enabled": false` as shown below:
319
352
 
320
353
  ```json
321
354
  {
322
355
  "rules": {
323
- "invalid-api-version": {
324
- "expression": "===58" // comparison expression
325
- },
326
- "invalid-naming-convention": {
327
- "expression": "[A-Za-z0-9]" // regular expression
356
+ "dml-in-loop": {
357
+ "enabled": false
328
358
  }
329
359
  }
330
360
  }
@@ -1,6 +1,7 @@
1
1
  import { RuleInfo } from "./RuleInfo";
2
2
  import * as core from "../internals/internals";
3
3
  export declare abstract class RuleCommon {
4
+ category?: 'problem' | 'suggestion' | 'layout';
4
5
  description: string;
5
6
  summary: string;
6
7
  docRefs: Array<{
@@ -127,6 +127,7 @@ let RuleCommon = class RuleCommon {
127
127
  return undefined;
128
128
  }
129
129
  constructor(info, optional){
130
+ _define_property(this, "category", void 0);
130
131
  _define_property(this, "description", void 0);
131
132
  _define_property(this, "summary", void 0);
132
133
  _define_property(this, "docRefs", []);
@@ -137,6 +138,7 @@ let RuleCommon = class RuleCommon {
137
138
  _define_property(this, "supportedTypes", void 0);
138
139
  _define_property(this, "uri", void 0);
139
140
  _define_property(this, "ruleId", void 0);
141
+ this.category = info.category;
140
142
  this.ruleId = info.ruleId;
141
143
  this.name = info.name;
142
144
  this.supportedTypes = info.supportedTypes;
@@ -27,6 +27,11 @@ export declare class RuleInfo {
27
27
  * This property is being displayed on sf cli and on vsce
28
28
  */
29
29
  label: string;
30
+ /**
31
+ * The category for the rule.
32
+ * 'problem' | 'suggestion' | 'layout'
33
+ */
34
+ category: 'problem' | 'suggestion' | 'layout';
30
35
  /**
31
36
  * Stable public identifier used for config, suppression, and reporting.
32
37
  */
@@ -37,6 +37,10 @@ let RuleInfo = class RuleInfo {
37
37
  * This property is being displayed on sf cli and on vsce
38
38
  */ _define_property(this, "label", void 0);
39
39
  /**
40
+ * The category for the rule.
41
+ * 'problem' | 'suggestion' | 'layout'
42
+ */ _define_property(this, "category", void 0);
43
+ /**
40
44
  * Stable public identifier used for config, suppression, and reporting.
41
45
  */ _define_property(this, "ruleId", void 0);
42
46
  /**
@@ -114,6 +114,7 @@ let APIVersion = class APIVersion extends _RuleCommon.RuleCommon {
114
114
  constructor(){
115
115
  super({
116
116
  ruleId: "invalid-api-version",
117
+ category: "suggestion",
117
118
  name: "APIVersion",
118
119
  label: "Invalid API Version",
119
120
  description: "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.",
@@ -20,6 +20,7 @@ let ActionCallsInLoop = class ActionCallsInLoop extends _LoopRuleCommon.LoopRule
20
20
  constructor(){
21
21
  super({
22
22
  ruleId: "action-call-in-loop",
23
+ category: "suggestion",
23
24
  description: "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.",
24
25
  summary: "Action calls inside loop risk governor limits",
25
26
  docRefs: [
@@ -66,6 +66,7 @@ let AutoLayout = class AutoLayout extends _RuleCommon.RuleCommon {
66
66
  constructor(){
67
67
  super({
68
68
  ruleId: "missing-auto-layout",
69
+ category: "layout",
69
70
  name: "AutoLayout",
70
71
  label: "Missing Auto Layout",
71
72
  description: "Auto-Layout automatically arranges and aligns Flow elements, keeping the canvas organized and easier to maintain. Enabling it saves time and improves readability.",
@@ -60,6 +60,7 @@ let CopyAPIName = class CopyAPIName extends _RuleCommon.RuleCommon {
60
60
  constructor(){
61
61
  super({
62
62
  ruleId: "unclear-api-naming",
63
+ category: "layout",
63
64
  name: "CopyAPIName",
64
65
  label: "Unclear API Name",
65
66
  description: "Elements with unclear or duplicated API names, like Copy_X_Of_Element, reduce Flow readability. Make sure to update the API name when copying elements to keep your Flow organized.",
@@ -88,6 +88,7 @@ let CyclomaticComplexity = class CyclomaticComplexity extends _RuleCommon.RuleCo
88
88
  constructor(){
89
89
  super({
90
90
  ruleId: "excessive-cyclomatic-complexity",
91
+ category: "suggestion",
91
92
  name: "CyclomaticComplexity",
92
93
  label: "Excessive Cyclomatic Complexity",
93
94
  description: "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.",
@@ -21,6 +21,7 @@ let DMLStatementInLoop = class DMLStatementInLoop extends _LoopRuleCommon.LoopRu
21
21
  constructor(){
22
22
  super({
23
23
  ruleId: "dml-in-loop",
24
+ category: "problem",
24
25
  description: "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.",
25
26
  summary: "DML operations inside loop risk governor limits",
26
27
  docRefs: [
@@ -95,6 +95,7 @@ let DuplicateDMLOperation = class DuplicateDMLOperation extends _RuleCommon.Rule
95
95
  constructor(){
96
96
  super({
97
97
  ruleId: "duplicate-dml",
98
+ category: "problem",
98
99
  name: "DuplicateDMLOperation",
99
100
  label: "Duplicate DML Operation",
100
101
  description: "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.",
@@ -64,6 +64,7 @@ let FlowDescription = class FlowDescription extends _RuleCommon.RuleCommon {
64
64
  constructor(){
65
65
  super({
66
66
  ruleId: "missing-flow-description",
67
+ category: "layout",
67
68
  description: "Flow descriptions are essential for documentation and maintainability. Include a description for each Flow, explaining its purpose and where it's used.",
68
69
  summary: "Flow descriptions improve documentation and maintainability",
69
70
  docRefs: [],
@@ -67,6 +67,7 @@ let FlowName = class FlowName extends _RuleCommon.RuleCommon {
67
67
  constructor(){
68
68
  super({
69
69
  ruleId: "invalid-naming-convention",
70
+ category: "layout",
70
71
  description: "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.",
71
72
  summary: "Consistent naming improves Flow discoverability and maintainability",
72
73
  docRefs: [
@@ -69,6 +69,7 @@ let GetRecordAllFields = class GetRecordAllFields extends _RuleCommon.RuleCommon
69
69
  constructor(){
70
70
  super({
71
71
  ruleId: "get-record-all-fields",
72
+ category: "suggestion",
72
73
  description: "Avoid using Get Records to retrieve all fields unless necessary. This improves performance, reduces processing time, and limits exposure of unnecessary data.",
73
74
  summary: "Retrieving all fields harms performance and security",
74
75
  docRefs: [
@@ -60,6 +60,7 @@ let HardcodedId = class HardcodedId extends _RuleCommon.RuleCommon {
60
60
  super({
61
61
  ruleId: "hardcoded-id",
62
62
  name: "HardcodedId",
63
+ category: "problem",
63
64
  label: "Hardcoded Id",
64
65
  description: "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.",
65
66
  summary: "Hardcoded IDs break portability across environments",
@@ -19,6 +19,7 @@ let HardcodedUrl = class HardcodedUrl extends _RuleCommon.RuleCommon {
19
19
  constructor(){
20
20
  super({
21
21
  ruleId: "hardcoded-url",
22
+ category: "problem",
22
23
  description: "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.",
23
24
  summary: "Hardcoded URLs break across different environments",
24
25
  docRefs: [
@@ -63,6 +63,7 @@ let InactiveFlow = class InactiveFlow extends _RuleCommon.RuleCommon {
63
63
  constructor(){
64
64
  super({
65
65
  ruleId: "inactive-flow",
66
+ category: "suggestion",
66
67
  name: "InactiveFlow",
67
68
  label: "Inactive Flow",
68
69
  description: "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.",
@@ -127,6 +127,7 @@ let MissingFaultPath = class MissingFaultPath extends _RuleCommon.RuleCommon {
127
127
  constructor(){
128
128
  super({
129
129
  ruleId: "missing-fault-path",
130
+ category: "problem",
130
131
  description: "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.",
131
132
  summary: "Fault Paths enable graceful error handling",
132
133
  docRefs: [
@@ -66,6 +66,7 @@ let MissingMetadataDescription = class MissingMetadataDescription extends _RuleC
66
66
  constructor(){
67
67
  super({
68
68
  ruleId: "missing-metadata-description",
69
+ category: "layout",
69
70
  description: "Elements and metadata without a description reduce clarity and maintainability. Adding descriptions improves readability and makes your automation easier to understand.",
70
71
  summary: "Element descriptions improve clarity and maintainability",
71
72
  docRefs: [],
@@ -138,6 +138,7 @@ let MissingNullHandler = class MissingNullHandler extends _RuleCommon.RuleCommon
138
138
  constructor(){
139
139
  super({
140
140
  ruleId: "missing-null-handler",
141
+ category: "problem",
141
142
  description: "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.",
142
143
  summary: "Null checks prevent failures from missing records",
143
144
  docRefs: [],
@@ -78,6 +78,7 @@ let MissingRecordTriggerFilter = class MissingRecordTriggerFilter extends _RuleC
78
78
  constructor(){
79
79
  super({
80
80
  ruleId: "missing-record-trigger-filter",
81
+ category: "suggestion",
81
82
  name: "MissingRecordTriggerFilter",
82
83
  label: "Missing Filter Record Trigger",
83
84
  description: "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.",
@@ -60,6 +60,7 @@ let ProcessBuilder = class ProcessBuilder extends _RuleCommon.RuleCommon {
60
60
  constructor(){
61
61
  super({
62
62
  ruleId: "process-builder-usage",
63
+ category: "problem",
63
64
  name: "ProcessBuilder",
64
65
  label: "Process Builder",
65
66
  description: "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.",
@@ -74,6 +74,7 @@ let RecordIdAsString = class RecordIdAsString extends _RuleCommon.RuleCommon {
74
74
  constructor(){
75
75
  super({
76
76
  ruleId: "record-id-as-string",
77
+ category: "suggestion",
77
78
  name: "RecordIdAsString",
78
79
  label: "Record ID as String",
79
80
  description: "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.",
@@ -105,6 +105,7 @@ let RecursiveAfterUpdate = class RecursiveAfterUpdate extends _RuleCommon.RuleCo
105
105
  constructor(){
106
106
  super({
107
107
  ruleId: "recursive-record-update",
108
+ category: "problem",
108
109
  description: "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.",
109
110
  summary: "After-save updates to same record trigger recursion",
110
111
  docRefs: [
@@ -19,6 +19,7 @@ let SOQLQueryInLoop = class SOQLQueryInLoop extends _LoopRuleCommon.LoopRuleComm
19
19
  constructor(){
20
20
  super({
21
21
  ruleId: "soql-in-loop",
22
+ category: "problem",
22
23
  description: "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.",
23
24
  summary: "SOQL queries inside loop risk governor limits",
24
25
  docRefs: [
@@ -87,6 +87,7 @@ let SameRecordFieldUpdates = class SameRecordFieldUpdates extends _RuleCommon.Ru
87
87
  constructor(){
88
88
  super({
89
89
  ruleId: "same-record-field-updates",
90
+ category: "suggestion",
90
91
  name: "SameRecordFieldUpdates",
91
92
  label: "Same Record Field Updates",
92
93
  description: "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",
@@ -77,6 +77,7 @@ let TransformInsteadOfLoop = class TransformInsteadOfLoop extends _RuleCommon.Ru
77
77
  constructor(){
78
78
  super({
79
79
  ruleId: "transform-instead-of-loop",
80
+ category: "suggestion",
80
81
  name: "TransformInsteadOfLoop",
81
82
  label: "Transform Instead of Loop",
82
83
  description: "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.",
@@ -69,6 +69,7 @@ let TriggerOrder = class TriggerOrder extends _RuleCommon.RuleCommon {
69
69
  constructor(){
70
70
  super({
71
71
  ruleId: "unspecified-trigger-order",
72
+ category: "suggestion",
72
73
  name: "TriggerOrder",
73
74
  label: "Missing Trigger Order",
74
75
  description: "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.",
@@ -62,6 +62,7 @@ let UnconnectedElement = class UnconnectedElement extends _RuleCommon.RuleCommon
62
62
  constructor(){
63
63
  super({
64
64
  ruleId: "unreachable-element",
65
+ category: "layout",
65
66
  description: "Unconnected elements never execute and add unnecessary clutter. Remove or connect unused Flow elements to keep Flows clean and efficient.",
66
67
  summary: "Unconnected elements add clutter without executing",
67
68
  docRefs: [],
@@ -68,6 +68,7 @@ let UnsafeRunningContext = class UnsafeRunningContext extends _RuleCommon.RuleCo
68
68
  constructor(){
69
69
  super({
70
70
  ruleId: "unsafe-running-context",
71
+ category: "problem",
71
72
  name: "UnsafeRunningContext",
72
73
  label: "Unsafe Running Context",
73
74
  description: "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.",
@@ -80,6 +80,7 @@ let UnusedVariable = class UnusedVariable extends _RuleCommon.RuleCommon {
80
80
  constructor(){
81
81
  super({
82
82
  ruleId: "unused-variable",
83
+ category: "layout",
83
84
  name: "UnusedVariable",
84
85
  label: "Unused Variable",
85
86
  description: "Unused variables are never referenced and add unnecessary clutter. Remove them to keep Flows efficient and easy to maintain.",
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "@flow-scanner/lightning-flow-scanner-core",
3
3
  "description": "A lightweight engine for Flow metadata in Node.js, and browser environments. Assess and enhance Salesforce Flow automations for best practices, security, governor limits, and performance issues.",
4
- "version": "6.15.1",
4
+ "version": "6.15.2",
5
5
  "main": "index.js",
6
6
  "exports": {
7
7
  ".": {