Salesforce Flow Design

# Salesforce Flow Design and Validation

Apply these checks to every Flow you design, build, or review.

## Step 1 — Confirm Flow Is the Right Tool

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.

## Step 2 — Select the Correct Flow Type

| 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.

## Step 3 — Bulk Safety Checklist

These patterns are governor limit failures at scale. Check for all of them before the Flow is activated.

### DML in Loops — Automatic Fail

```
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.

### Get Records in Loops — Automatic Fail

```
Loop element
  └── Get Records  ← ❌ SOQL inside loop
```

Fix: perform the Get Records query **before** the loop, then loop over the collection variable.

### Correct Bulk Pattern

```
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
```

### Transform vs Loop
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.

## Step 4 — Fault Path Requirements

Every element that can fail at runtime must have a fault connector. Flows without fault paths surface raw system errors to users.

### Elements That Require Fault Connectors
- Create Records
- Update Records
- Delete Records
- Get Records (when accessing a required record that might not exist)
- Send Email
- HTTP Callout / External Service action
- Apex action (invocable)
- Subflow (if the subflow can throw a fault)

### Fault Handler Pattern
```
Fault connector → Log Error (Create Record