Flow Examples
Real scenarios showing how a trigger and a chain of actions combine into a working automation. Pick a tab to see scenarios grouped by the trigger that starts them.
Refreshing an orders warehouse every night
Context. An e-commerce team lands its operational data in an orders_warehouse datastore that analysts query every morning, so the copy has to be refreshed and validated before 6:00 AM. Instead of asking someone to babysit the refresh, they create a Flow named "Nightly orders refresh and scan" with a Schedule trigger set to 0 2 * * * in the America/Chicago timezone, and chain three Operation actions: a Sync, then a Profile, then a Scan of the datastore.
What happens. At 2:00 AM Chicago time the schedule activates the trigger. The Sync pulls the night's new containers and fields; when it succeeds, the Profile refreshes the metadata analysts rely on, and when that succeeds, the Scan asserts the quality checks. One night the source database goes down for maintenance that ran late: the Sync fails, and the Profile and Scan show as Skipped in the execution instead of measuring yesterday's stale copy.
Why it works. A downstream action only starts when its parent succeeds, so one schedule replaces three separate ones that could drift apart, and a broken night surfaces as a single failed execution instead of a morning of misleading dashboards. The timezone-aware schedule keeps the 2:00 AM slot stable through Daylight Saving Time.
Alerting the on-call channel when a scan fails
Context. A data platform team runs scheduled scans on a payments datastore that feeds the finance close. A scan that silently stops running is worse than a failing check, because nobody notices until the numbers are wrong. They create a Flow with an Operation Completed trigger, filtered to that datastore, Operation Types = Scan, and Operation Status = Failure, with a single Slack notification action pointed at the #data-alerts channel.
What happens. During a credential change, the platform loses access to the datastore and the 6:00 AM scan fails. The completion matches the trigger's filters, the Flow runs, and #data-alerts receives a message naming the datastore, the operation's result, and its logs. The engineer on call fixes the connection before the finance team opens its first report.
Why it works. The Failure filter keeps the channel silent on every healthy scan, so a message there always means action, and the message variables carry enough context to start investigating without opening the platform first. Success messages would have trained the team to mute the channel.
Turning severe product anomalies into tickets
Context. A retailer's product_catalog datastore feeds the storefront, so a duplicated SKU or a null price is revenue lost within hours. The team wants every higher-severity anomaly investigated in Jira, where their triage already lives. They create a Flow with an Anomaly Detected trigger filtered to that datastore and a minimum Anomaly Severity (Min), and chain two actions: Create Ticket in the Jira integration, then a Slack notification to the merchandising channel.
What happens. An overnight scan catches a batch import that wrote null prices into part of the catalog. For the anomaly at or above the severity threshold, the Flow runs once: a Jira ticket is created carrying the anomaly's context, and the channel is notified. Lower-severity anomalies, and anomalies recorded as duplicates or resolved by the scan, do not start the Flow.
Why it works. The severity filter turns a noisy stream of findings into a short list worth a ticket each, and pairing the ticket with the notification puts the same event where the team plans work and where it talks. Team members still review the failed checks and business context before deciding how to fix the import.
See Also
-
Best Practices
Guidelines for building Flows that stay quiet when healthy and loud when something breaks.
-
Permissions
The user roles behind viewing, building, executing, and deleting Flows.
-
How It Works
The canvas, Flow settings, chaining rules, and the publish lifecycle behind every edit.
-
Triggers
The six trigger types, schedule configuration, and the filter conditions each type supports.
-
Actions
The five action categories, the chaining rules between them, and where each is documented.
-
Executions
The Definitions and Executions tabs, execution states, and the read-only execution graph.