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, and the Workflow's inputs if it needs any | Interval, daily, weekly, monthly by date, or monthly by weekday, plus a time of day. See Inputs on a schedule |
| 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.
Inputs on a schedule
A Workflow with required inputs needs them on every tick, so a schedule asks how to supply them.
- Provide them yourself. The same form Run workflow uses, filled in once. The values are checked against the Workflow's input contract before the trigger saves, so a schedule cannot be created that its Workflow would reject.
- Let an agent prepare them. Write what the run needs in plain language, and an agent produces the inputs on each tick. Use this when the values depend on the day, such as a date range or a queue to read.
A Workflow with no required inputs does not ask.
When a schedule stops itself
Turning a trigger off is your decision and needs no follow-up. A schedule can also stop on its own, and that is different: it means the work is not arriving and something has to be fixed.
When the platform cannot start a schedule's run after repeated attempts, or can no longer work out when to run it next, it stops the schedule and marks the row Stopped rather than leaving it looking switched off. The row says why in one sentence, such as "We stopped this schedule after too many failed attempts to start its run." Technical details underneath holds the scheduler's own words for whoever is diagnosing it. Turn the schedule back on to try again.
Manage triggers from a conversation
You can ask a Project conversation which triggers are live and have it pause or resume one, without opening this page. The conversation reports back what it changed, and the change lands in the Audit trail like any other.
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.