Triggers
A trigger is how work reaches a Workflow without anyone asking. Every enabled trigger creates a Work item and runs the Workflow on it.
Audience: builders
Add a trigger
Open the Workflow's Starts section
Open the Project in Build and select the Workflow under Automations. Starts is the first section on the page.
Pick a source
Slack, Teams, Email, Schedule, OneDrive, SharePoint, Google Drive, or Webhook.
Name it
The name is what you will see in the trigger list and on the Work items it produces. For a schedule, the cadence speaks for itself and is used instead.
Fill in what the source needs
A channel, a mailbox, a folder, a cadence. See the table below.
Save
Add trigger creates it. A trigger can be enabled or disabled without deleting it, so you can stop work arriving while you change the Workflow.
What each source needs
| Source | What you choose | Notes |
|---|---|---|
| Slack | A chat or channel | Public channel, private channel, direct message, or group message |
| Teams | A chat or channel | |
| A mailbox | See Bound email | |
| Schedule | A cadence | Interval, daily, weekly, monthly by date, or monthly by weekday, plus a time of day |
| OneDrive, SharePoint, Google Drive | A folder or document library | Optionally include subfolders. Fires when a file lands |
| Webhook | Nothing to choose | You get a URL to post to |
All of these except Schedule and Webhook run on an integration your administrator has connected. If the source you want is not in the list, the integration is not connected yet.
Telling the Workflow what to do with each item
Every source except Webhook offers an optional instruction field, worded for what it watches:
- How to handle each email
- How to handle each message
- How to handle each file
- What to do on each run
This is guidance for turning one inbound thing into work, and it is the right place for the small distinctions that would otherwise clutter the Workflow. "Ignore out-of-office replies." "Only process files whose name starts with REMIT."
It is optional. Leave it empty and the Workflow handles everything the trigger delivers.
Webhook payloads
A webhook trigger receives whatever you post to it. Rather than making the Workflow dig through the envelope, you point at the parts you want with JMESPath expressions:
| Field | What it picks out | Example |
|---|---|---|
| Payload | The body the Workflow should treat as its input | body.data |
| Title | What to call the resulting Work item | body.subject |
| Metadata | Extra context to keep on the Work item | body.meta |
| Work item key | A stable identifier for deduplication | body.id |
All four are optional.
Set a Work item key if the sender retries. Retries carrying the same key deduplicate into one Work item rather than creating a duplicate for every delivery attempt.
After a trigger fires
Each firing produces a Work item on the Workflow's Work items tab, carrying its input, its result, and the trigger that started it. The trigger's own firing history is available from the trigger, which is where to look when you expect work that never arrived.
Add triggers last. A Workflow is live in its Project as soon as your change is applied. Get the Workflow right by running it by hand first, then connect a trigger and let work start arriving on its own.