Flow Best Practices

Guidelines for building Flows that stay quiet when everything is healthy and loud when something breaks.

Name the Flow for the reader, not the builder

The Flow's name follows it everywhere: the canvas, the Definitions list, and the messages its notifications send. "Notify #data-alerts on payments scan failures" tells a teammate what activated it and why; "Flow 3" makes every message a puzzle. Put the trigger and the outcome in the name.

Filter triggers until silence means health

Every filter you leave empty widens what starts the Flow. Narrow the trigger with the filters it offers, such as source datastores, tags, operation types and status, check rule types, or a minimum anomaly severity, until the Flow only activates on events someone would act on. A channel that only receives real problems keeps the team's trust; a noisy one trains everyone to ignore it.

Alert on failure, not on success

For an Operation Completed trigger feeding a notification, set Operation Status to Failure unless someone genuinely acts on success messages. A quiet channel then carries information, because no news is good news.

Chain operations in one Flow instead of stacking schedules

When operations depend on each other, such as a Sync followed by a Profile and a Scan, chain them as actions behind one trigger instead of giving each its own schedule. Actions run in order, and a downstream action only starts when its parent succeeds, so a failed Sync skips the Profile and Scan instead of measuring stale data. Separate schedules drift apart and keep running after an upstream failure.

Schedule in the business timezone

A schedule runs in UTC by default, and Daylight Saving Time transitions are handled automatically when you pick another timezone. Pick the timezone the business thinks in, so "9:00 AM" stays 9:00 AM local year-round; keep the UTC default only when the audience works in UTC.

Test notifications before publishing

Every notification action offers a Test Notification button that sends a sample message with dummy data. Use it to confirm the channel, the formatting, and the message variables before the Flow goes live, instead of waiting for the first real event to find a typo.

Publish before you leave

Save on a node's panel only stores a draft; nothing is kept until you click Publish. Finish an editing session by publishing, or by clicking Cancel to deliberately discard the draft, rather than leaving unpublished changes to be lost on the next navigation.

Clone the Flow to reuse its actions under another trigger

A Flow has exactly one trigger, so the same chain of actions cannot react to two different events. When you need that, clone the Flow and configure the clone's trigger; the two copies then evolve independently, each with a name that says what starts it.

Deactivate instead of delete

Deleting a Flow permanently removes its execution history and schedules. When a Flow is noisy, seasonal, or under review, deactivate it instead. The configuration and history stay intact, and reactivating restores it exactly as it was.