Workflow Trigger

Workflow Trigger supports starting a workflow automatically when another workflow succeeds. Declare the dependency in your workflow definition.

When to use Workflow Trigger

Use Workflow Trigger when:

Many downstream workflows depend on the same upstream workflow (fan-out), and you don't want to edit the upstream each time one is added or removed.
The upstream workflow's runtime varies, making a fixed schedule: on the downstream workflow unreliable.

Defining an Workflow Trigger

Add a trigger: block to the definition of the workflow you want Workflow Trigger to start. The trigger takes effect when you push the project. Push the upstream project first. Its existence is verified when you push the downstream project (otherwise the push fails with Dependent project '{project_name}' not found in trigger config).

post_load.dig (downstream workflow):

trigger:
  attempt>:
  dependent_workflow_name: data_load_wf
  dependent_project_name: data_pipeline

+run_after_load:
  echo>: "data_load_wf finished successfully"

In the example above, the post_load workflow runs whenever the data_load_wf workflow in the data_pipeline project succeeds.

Configuration Parameters

Parameter	Description
`attempt>`	The trigger type. Starts the downstream workflow when the upstream workflow succeeds.
`dependent_workflow_name`	The name of the upstream workflow whose successful completion starts the downstream workflow.
`dependent_project_name`	The name of the project that contains the upstream workflow. Must be a project in the same account.

Example: Fan-out to multiple downstream workflows

One upstream workflow builds a daily aggregate table. Two downstream workflows (an export and a quality check) run after it. Each declares its own dependency, so adding downstream workflows doesn't require editing the upstream.

build_aggregate.dig (aggregate_project, upstream workflow)

timezone: UTC

schedule:
  daily>: 02:00:00

+build_aggregate:
  td>:
  query: "INSERT INTO daily_aggregate SELECT ... FROM events"

export_aggregate.dig (export_project, downstream workflow #1)

trigger:
  attempt>:
  dependent_workflow_name: build_aggregate
  dependent_project_name: aggregate_project

+export_to_s3:
  td_table_export>:
  database: my_db
  table: daily_aggregate
  file_format: csv
  s3_bucket: my-export-bucket
  s3_path_prefix: daily/

check_aggregate.dig (quality_project, downstream workflow #2)

trigger:
  attempt>:
  dependent_workflow_name: build_aggregate
  dependent_project_name: aggregate_project

+row_count_check:
  td>:
  query: "SELECT COUNT(*) AS row_count FROM daily_aggregate"

After you push all three projects, both the export_aggregate and check_aggregate workflows start automatically when the build_aggregate workflow succeeds.

Limitations

See Treasure Workflow Prerequisites and Limitations for the maximum number of downstream workflows that can depend on the same upstream workflow.
Circular dependencies are not allowed. If pushing a project would create a cycle (for example, workflow A triggers B and B triggers A), the push fails with Circular trigger config detected. Resolve the cycle before retrying the push.
Only successful attempts start the downstream; failed, canceled, or killed ones do not.
Currently, only attempt> is supported.

The trigger can silently stop in these cases:

Upstream project is deleted: existing triggers in downstream projects are not removed automatically. Re-creating the upstream project with the same name does not restore the trigger. The new project is treated as a separate project from the deleted one. Re-push the downstream project to recreate the trigger.
Upstream workflow is renamed or removed: the trigger references the upstream by name, so renaming or removing it in the upstream project stops the trigger.
Incorrect dependent_workflow_name: only the upstream project's existence is verified at push time, not the workflow name.

Verify the trigger configuration after any change to either project.

For notifications related to Workflow Trigger, see About Workflow Email Notifications.