database steps—not on roots, not on transforms. When a database is triggered, the platform refreshes its ancestor closure: every step that contributes to that database.
Trigger types
Triggers are configured from the database step’s inspector. A single database can carry one schedule trigger plus the implicit manual one.
Cascade
Triggers aren’t the only way runs start. When an upstream database is refreshed, every downstream pipeline that reads from it cascades automatically. This is configuration-free—wire thedata_read step to the upstream database and the dependency is tracked from then on.
Cascades are debounced and idempotent: rapid upstream refreshes coalesce into a single downstream run, and unchanged refreshes are skipped (see Runs for cascade events).
Schedule mechanics
Schedules run in the platform’s worker, not in your browser. Each fire creates a Run scoped to the triggered database’s ancestor closure. Schedules continue to fire even if a previous run is still in progress; if you don’t want overlap, set the interval longer than the run takes.Disabling a trigger
You can pause a trigger from the database step inspector. A paused trigger stays configured but does not fire until you resume it. Cascade is paused by suppressing the downstreamdata_read or the database itself.