Building a flow is part design exercise, part configuration. Pick the trigger type first, sketch the element sequence on paper, then build it in Flow Builder. Test with the Debug pane in sandbox, handle fault paths explicitly, and deploy with proper versioning. The flow that ships to production is almost never the first version you build.
- Decide the flow type
Record-Triggered for save-event automation. Screen Flow for user-facing wizards. Scheduled Flow for nightly or hourly batch operations. Platform Event-Triggered for inbound integrations. Autolaunched for background logic called from other flows or Apex. The flow type is permanent for a given flow, so confirm the choice before opening Flow Builder.
- Sketch the element sequence
Draw the flow on paper or in a diagram tool. List every Get, Decision, Assignment, Create, Update, and Loop with rough names. This sketch catches design issues before you build them in the canvas, where rework is more tedious.
- Open Flow Builder and configure the start element
Setup > Flows > New Flow. Pick the type and configure the trigger conditions. For Record-Triggered Flow, choose the object, the trigger event (create, update, both), and the entry criteria. Set the optimization mode (Fast Field Updates for same-record updates, Actions and Related Records for everything else).
- Build the elements on the canvas
Drag elements from the toolbox onto the canvas, connect them with arrows, and configure each element's properties. Use Decision for branching, Assignment for variable writes, Get/Create/Update/Delete Records for DML. Use Loops sparingly and avoid DML inside them.
- Add fault paths and error handling
For every DML element and every Apex action, drag a Fault path to a logging or notification element. Without explicit fault handling, errors fail the flow with an unfriendly message and no traceability.
- Debug in sandbox with the Debug pane
Click Debug in Flow Builder, supply input variables, and step through the execution. Watch the variable values at each element. Verify that the flow takes the expected path for every scenario, including edge cases like empty inputs and missing related records.
- Activate, deploy, and monitor
Activate the flow in sandbox and run integration tests. Deploy through change set, metadata API, or SFDX. In production, activate the new version while keeping the previous version available for rollback. Monitor via Setup > Paused and Waiting Flow Interviews for stuck instances and the debug logs for runtime errors.
The flow type (Record-Triggered, Screen, Scheduled, etc.) and trigger event. Permanent for a given flow API name.
Used by Apex, other flows, and integrations to invoke this flow. Avoid renaming after dependencies exist.
Each flow has multiple versions. Only one version is active at a time, and the active version is what runs in production.
- DML inside a Loop element produces per-record DML and hits governor limits fast on bulk operations. Collect records inside the loop, then do the DML outside it.
- Fault paths are optional but rarely should be. Without them, errors fail the flow with an unfriendly message and no logged trace, making production issues hard to diagnose.
- Record-Triggered Flow with the wrong optimization mode (Fast Field Updates vs. Actions and Related Records) silently changes behavior. Same-record field updates work in either mode; everything else needs Actions and Related Records.
- Multiple flows on the same object can compound CPU and DML cost during bulk operations. Consolidate into one record-triggered flow per object with internal branching where possible.
- Flow version activation does not migrate paused interviews. Existing interviews stay on the version they started on, so behavior changes only apply to new triggers.