Skip to main content

Trigger

Start your workflows with triggers.

Written by Jamie Gaynor

A trigger is what sets a workflow in motion. A workflow doesn't run on its own; something has to start it, and that something is a trigger. It might be a clock reaching a scheduled time, a request arriving at a URL, or an email landing in an inbox.

Triggers start a run

Every run begins with a trigger. When a trigger fires, Tines 3B starts a run at the step the trigger is attached to, and the workflow flows on from there. So a trigger is the entry point: the moment and the doorway through which work enters a workflow. No trigger, no run.

A trigger lives on a step, the one meant to go first. That step becomes the workflow's starting point, and whatever the trigger delivers arrives as that step's input, ready to be read and acted on.

The kinds of trigger

Tines 3B workflows can be started a few different ways:

  • On a schedule. A step can run at set times, described by a schedule, so the workflow fires automatically, hourly, nightly, or whenever you choose.

  • By an incoming request. A step given a URL runs when someone reaches it. This is the broad category behind webpages people open, APIs called by other systems, and webhooks that receive events from services like Slack or Stripe.

  • By email. A step can be given an address, and mail sent to it starts a run, with the message itself handed to the step.

  • By another workflow. One workflow can call another, so finishing one automation can kick off the next.

Different triggers suit different jobs, and picking the right one is really a question of what should set this workflow going.

The trigger shapes the input

Because the trigger is how work enters the workflow, it also decides what the first step receives on its input. A scheduled run starts with nothing in particular to process; a request-triggered step receives the incoming request; an email-triggered step receives the message. The entry step reads that input the same way any step reads its input, then does its work and passes the result along.

Triggers fire on the live version

Note: Triggers only fire on the live, published version of a workflow.

A draft you're still building won't start running on a schedule or answer requests on its own, which keeps work in progress from doing anything real before you're ready. While building, you run the workflow yourself to test it, and it goes live, with its triggers active, only when you publish it.

A workflow can have several triggers

A workflow isn't limited to one trigger. It might expose more than one URL, or pair a schedule with a webhook, or offer several API endpoints at once. Each is its own way in, starting a run at its own entry step. Tines 3B shows a workflow's trigger types together, so you can see at a glance how a given automation can be set off.

Once any trigger fires, the rest is the workflow doing its job: the run moves from the entry step through the steps that follow, carrying data along as it goes.

Did this answer your question?