Flow Triggers¶

The trigger defines when a Flow starts. Every Flow has exactly one trigger node, always present on the canvas; you choose its type and conditions in the Trigger Settings panel, where the other types fold away once one is chosen, and you can reconfigure it at any time. See Configure a Trigger for the steps.

Each type reacts to a different event. The Filter Conditions it accepts narrow down which events start the Flow and are listed with each type below; every filter's effect is described in the Configure a Trigger field reference. Match all (the default) starts the Flow only when every filter matches, and Match any when at least one does; each filter's operator, such as is not any of, decides how it matches. See How filters combine. When a trigger has filters applied, its node shows the filter icon on the canvas; hover over it to see the applied conditions.

Trigger Types¶

Trigger Type	Starts the Flow	Filter Conditions
Schedule	On a defined schedule, using simple intervals or cron expressions.
Operation Completed	Once, when a matching operation finishes.
Anomalous Table or File Detected	Once for each table or file where a scan detects anomalies.
Anomaly Detected	For each open anomaly that is detected.
Anomaly Status Changed	When an anomaly's status changes to a selected status.
Manual	Only when a user executes the Flow.

Datastores and who can edit

On an Operation Completed, Anomalous Table or File Detected, Anomaly Detected, or Anomaly Status Changed trigger, the Datastores filter also decides who can manage the Flow. The picked datastores become related datastores, and leaving the filter empty makes the Flow reach every datastore, which needs the Editor team permission on all of them. Unless you are an Admin or hold that permission on every datastore, the filter is required and lists only the datastores you edit. See Flow Permissions.

Schedule¶

The Schedule trigger runs a Flow automatically at a defined interval (hourly, daily, weekly, monthly, or a custom cron expression). A scheduled Flow is useful for automating routine tasks, periodic scans, exports, or notifications.

Timezone-aware scheduling

UTC is the default for new and existing schedules. Picking another timezone is supported, with Daylight Saving Time handled automatically, and the selection is shown as an abbreviation on the schedule card, such as Current Schedule (EST).

When the Flow already has a schedule, the panel shows it under Current Schedule with the timezone abbreviation; turn on Define a new schedule to replace it. Deactivating the Flow keeps its schedule; see the FAQ for details.

Schedule Configuration offers:

Timezone: Pick the timezone before configuring the interval. UTC is selected by default; type to search by city, region, or abbreviation. The selection applies to every tab below, and a banner shows the current time in that timezone.
Hourly: Runs every N hours at a specified minute. For example, Every 1 hour(s) on minute 0 runs at the top of every hour.
Daily: Runs every N days at a specific time of day in the selected timezone.
Weekly: Runs on the selected days of the week at a set time in the selected timezone.
Monthly: Runs once a month on a specific day at a set time in the selected timezone.
Advanced: Accepts a Custom Cron Schedule for precise control. The field label shows the selected timezone's abbreviation, and the cron fields are interpreted in that timezone.

A cron expression has five fields: minute (0-59), hour (0-23), day of the month (1-31), month (1-12), and day of the week (0-6, Sunday to Saturday). The day of the week accepts only * or day numbers separated by commas: a range such as 1-5, a step such as */2, or a day name such as MON is rejected when you save. For example:

0 0 * * * runs at midnight every day.
0 12 * * 1,2,3,4,5 runs at 12:00 PM from Monday to Friday.
30 14 1 * * runs at 2:30 PM on the first day of every month.
0 22 * * 6 runs at 10:00 PM every Saturday.

Daylight Saving Time

When you pick a timezone that observes DST (such as America/New_York or Europe/London), the schedule automatically shifts with each transition. A job set to run at 9:00 AM in America/New_York runs at 9:00 AM local time year-round, regardless of whether the zone is in EST or EDT at the time. No reconfiguration is required.

Operation Completed¶

Starts the Flow whenever a matching operation completes on a datastore: a Sync, Profile, Scan, Export, Materialize, or Global Export. For example, a team can be notified whenever a Sync operation completes, so they can proceed with the Profile operation on the datastore, or whenever an Export or Materialize fails, so a missing output is noticed before anything downstream reads it.

A Global Export writes to an enrichment datastore, so that is the datastore the Datastores filter matches for it. An operation that the platform gives up on after its limit of automatic restarts counts as a failed operation and starts the Flow too. See the Runs FAQ.

Filters available: Datastore Tags, Datastores, Operation Types, and Operation Status.

Anomalous Table or File Detected¶

Starts the Flow once for each table or file where a scan detects anomalies. The event carries the number of anomalies found and the scan target, which is useful for assessing the overall health of a particular datastore.

Filters available: Tables / Files Tags, Datastores, and Check Rule Types.

Anomaly Detected¶

Starts the Flow for each open anomaly that is detected. The event carries the anomaly type and the datastore where it was found.

Only open anomalies trigger this Flow

Anomalies recorded as duplicates or resolved by the scan do not trigger this Flow.

Filters available: Anomaly's Tags, Datastores, Check Rule Types, and Anomaly Impact.

Anomaly Status Changed¶

Starts the Flow when an anomaly's status changes to a selected status. The event carries the anomaly, its previous and new status, and context such as the affected asset and datastore. This is useful for automating actions on anomaly lifecycle events, for example when an anomaly is resolved or acknowledged.

Filters available: Anomaly's Tags, Datastores, Anomaly Statuses, and Anomaly Impact.

Manual¶

Starts the Flow only when a user executes it. It doesn't depend on any automatic conditions or detections, giving the user full control. See Execute a Flow.