Most agents start when a customer writes in. A flow can also start without a customer: another system calls a URL, a clock ticks, or something happens in a connected app. These are called ways in, and one flow can have several.
These runs are headless
A run started this way has no customer on the other end. Nothing is delivered to a channel, and the output is kept on the run record. You see it in Analyze → Runs. A flow with only these triggers cannot use a Handover step.
For developers sending the requests, see Inbound triggers.
Add a way in
Select the Trigger card (Start this flow when) to open its panel. The Ways in row lists the current ones. Select Add and choose:
| Way in | When it runs |
|---|---|
| Customer message | A customer writes in — a live conversation. |
| Webhook | An external system calls a public URL. |
| Schedule | On a clock you choose. |
| When something happens in an app | New items appear in a connected app, such as Gmail. |
Each shows a status: Live, Paused, Not live, Finished or, for an app trigger that hit an error, Stopped.
Webhook
A webhook gives your flow a POST address. Anyone holding it can start the flow, so treat it as a secret.
- 1URL
- 2Signing
- Copy the delivery URL and give it to the sending system. A delivery is answered straight away with a
202and the run's id, and the flow runs in the background. - Signature — add a secret and Natiq expects each request to carry a signature in a named header. The secret is shown once; store it where the sender signs requests. Rotate issues a new secret and a new URL token. Add secret does the same, so after either, update the sender with both the new URL and the secret. Remove stops requiring signatures and the URL keeps working unsigned. Requests with a missing or wrong signature are rejected with a
401and are not recorded as runs, so they never show in Runs. - Sample payload — a JSON object used to pre-fill matching question steps. Autofill from flow adds a blank key for each question's variable.
- Try it out gives a ready cURL request, and a second one to fetch a run's result with its id.
- Pause stops it answering and Resume brings it back. Delete webhook removes the URL for good.
A webhook accepts calls once a published flow includes it. If you add one to an agent that is already live, publish again; until then calls are refused. Calls that are missing variables the flow always needs are refused too.
Schedule
Choose a cadence with the chips:
| Chip | Setting |
|---|---|
| Minutes | Every 1–59 minutes. |
| Hourly | At the top of every hour. |
| Daily | Every day at a time you pick. |
| Weekly | A day of the week and time. |
| Monthly | A day of the month, 1 to 28, and a time. |
| Cron | A six-field expression, seconds first. |
| Once | One chosen moment. |
Set the Timezone the cadence is read in (it isn't shown for Once). The panel shows the next runs so you can check the cadence does what you meant. A schedule can carry a static payload that every run can read. Pause and Resume control it; a one-time schedule shows Finished after it fires.
A schedule added before the flow has been published is held as Waiting on a publish and created when you publish; Publish now does it from the panel.
App events
Pick When something happens in an app, choose the app and the event, for example a new email. Then connect the account, set filters, and choose how often to check; five minutes is the shortest. A flow can have one app trigger. Items that arrive while it is removed or paused are not replayed.
If the connection breaks the status reads Needs reconnect; reconnect it from the panel.
Permissions
Editing the flow needs builder.bots:write. Testing a draft and running a knowledge crawl need builder.bots:trigger. Putting something on a clock is its own permission, builder.bots:schedule, so a builder can edit a flow without being able to decide it runs on a schedule.