Salesforce Flow architecture decisions, flow type selection, bulk safety validation, and fault handling standards. Use this skill when designing or reviewing Re
复制下面这句话,粘贴给 Claude Code、Codex、Cursor 等 AI 编程工具,它会读取安装说明并在你确认后完成安装。
请阅读 https://ai.atlankj.com/install/asset/gh-salesforce-flow-design-f6dd507755ce ,按照其中的说明把「salesforce-flow-design」安装到你(当前 AI 工具)中。执行前先告诉我将运行的命令和写入的位置,等我确认。
查看 AI 将读取的安装说明正在读取 GitHub 原文…
内容来自 GitHub 原始文件,由原作者维护。在 GitHub 查看
Apply these checks to every Flow you design, build, or review.
Before designing a Flow, verify that a lighter-weight declarative option cannot solve the problem:
| Requirement | Best tool |
|---|---|
| Calculate a field value with no side effects | Formula field |
| Prevent a bad record save with a user message | Validation rule |
| Sum or count child records on a parent | Roll-up Summary field |
| Complex multi-object logic, callouts, or high volume | Apex (Queueable / Batch) — not Flow |
| Everything else | Flow ✓ |
If you are building a Flow that could be replaced by a formula field or validation rule, ask the user to confirm the requirement is genuinely more complex.
| Use case | Flow type | Key constraint |
|---|---|---|
| Update a field on the same record before it is saved | Before-save Record-Triggered | Cannot send emails, make callouts, or change related records |
| Create/update related records, emails, callouts | After-save Record-Triggered | Runs after commit — avoid recursion traps |
| Guide a user through a multi-step UI process | Screen Flow | Cannot be triggered by a record event automatically |
| Reusable background logic called from another Flow | Autolaunched (Subflow) | Input/output variables define the contract |
Logic invoked from Apex @InvocableMethod | Autolaunched (Invocable) | Must declare input/output variables |
| Time-based batch processing | Scheduled Flow | Runs in batch context — respect governor limits |
| Respond to events (Platform Events / CDC) | Platform Event–Triggered | Runs asynchronously — eventual consistency |
Decision rule: choose before-save when you only need to change the triggering record's own fields. Move to after-save the moment you need to touch related records, send emails, or make callouts.
These patterns are governor limit failures at scale. Check for all of them before the Flow is activated.
Loop element
└── Create Records / Update Records / Delete Records ← ❌ DML inside loop
Fix: collect records inside the loop into a collection variable, then run the DML element outside the loop.
Loop element
└── Get Records ← ❌ SOQL inside loop
Fix: perform the Get Records query before the loop, then loop over the collection variable.
Get Records — collect all records in one query
└── Loop over the collection variable
└── Decision / Assignment (no DML, no Get Records)
└── After the loop: Create/Update/Delete Records — one DML operation
When the goal is reshaping a collection (e.g. mapping field values from one object to another), use the Transform element instead of a Loop + Assignment pattern. Transform is bulk-safe by design and produces cleaner Flow graphs.
Every element that can fail at runtime must have a fault connector. Flows without fault paths surface raw system errors to users.
Fault connector → Log Error (Create Records on a logging object or fire a Platform Event)
→ Screen element with user-friendly message (Screen Flows)
→ Stop / End element (Record-Triggered Flows)
Never connect a fault path back to the same element that faulted — this creates an infinite loop.
Before deploying, verify there are no overlapping automations on the same object and trigger event:
Object + When to Run combinationbefore insert / after update contextOverlapping automations can cause unexpected ordering, recursion, and governor limit failures. Document the automation inventory for the object before activating.
lightning-input and SLDS-compliant components for all user inputs — do not use HTML form elements.Deploy as Draft → Test with 1 record → Test with 200+ records → Activate
ISCHANGED(Status) — ensure the test data actually triggers the condition).| Anti-pattern | Risk | Fix |
|---|---|---|
| DML element inside a Loop | Governor limit exception | Move DML outside the loop |
| Get Records inside a Loop | SOQL governor limit exception | Query before the loop |
| No fault connector on DML/email/callout element | Unhandled exception surfaced to user | Add fault path to every such element |
| Updating the triggering record in an after-save flow with no recursion guard | Infinite trigger loops | Add an entry condition or recursion guard variable |
Looping directly on $Record collection | Incorrect behaviour at scale | Assign to a collection variable first, then loop |
| Process Builder still active alongside a new Flow | Double-execution, unexpected ordering | Deactivate Process Builder before activating the Flow |
| Screen Flow with no End element on all branches | Runtime error or stuck user | Ensure every branch resolves to an End element |