Set up a trigger
You have a flow that does the right thing when you press Run. This guide gives it a start of its own, so it goes when the moment comes rather than when you remember: on a schedule, when a message arrives, when something outside changes, or when another system calls in.
Flows are early access, so give a newly triggered flow a few supervised runs before you leave it to itself.
Before you start
You need a flow with an accepted build. Until one has been compiled and accepted there is nothing for a trigger to start, and the flow's row says as much. Write your first flow gets you that far.
If the flow should start on an incoming message, connect that channel first: connect Telegram, WhatsApp, Slack or email.
If it should watch a service you use, have your login ready. Your assistant can tell you where to click, but it cannot sign in as you.
Pick the kind of start
| What sets it off | What that means |
|---|---|
| A time | "Every weekday at seven." Player One runs on your installation's own clock, so say your timezone with the time. |
| A message arriving | A message or an email on a channel you have already connected. Narrow it to one conversation or one sender, so a busy channel does not start a run every time somebody says hello. |
| Something outside changing | A mailbox, a feed or a page somewhere else. Player One looks every so often and starts the flow when there is genuinely something new. |
| Another system calling in | Some services can push an event to your installation the moment it happens, and a flow can start from it. It needs your installation to have a public address and inbound webhooks switched on; ask your assistant to check, and it mints the address to give the other system. The addresses are listed on Admin > Webhooks (/admin/webhooks). |
If all you want is one message rather than a whole process, ask for a watcher instead: lighter, and no flow needed. Scheduled tasks and watchers explains the difference.
Connect the source
- Tell your assistant what should start the flow, in ordinary words: "start the claims flow when something lands in the claims inbox".
- Read the plan it gives you. It names the source and what it will treat as an event before anything is connected. For a flow that starts on an incoming message it also asks one thing that is easy to skip: should Player One still reply to those messages itself, or does this flow answer them instead? Name the messages it covers, such as "emails to support@ from my suppliers", and answer plainly, because the answer decides whether your customers hear from the flow or from your assistant.
- Do the part only you can do. Your assistant gives you the clicks: sign in, paste an address into the other service's settings, or choose the mailbox.
- Put any password or key into the secure field it opens, never into the conversation itself.
- Fire one real event when it asks: send a message, submit a test form, save a file. It captures that event, so the connection is built around what your source really sends.
- Approve it. Your assistant shows you what it captured and what happens next time, and nothing goes live until you say yes in plain words.
- Check the flow on Dashboard > Flows (
/manage/flows). Its row on the Library tab says what starts it. Click the flow's name and the trigger is listed on its page with a switch, and the source appears on the Providers tab, switched on.
Checking it works
Open the flow's page and press Test fire beside the trigger. That fires it as though the real event had happened. A flow that runs inside its chat cannot be started by a trigger, so its test button is greyed out.
Then look at the Runs tab. A new run should be there within moments, and opening it draws the process as a map with the current step lit up, so you can watch it move.
After that, leave it for a real event. The trigger's own line carries a tag, On, Draft or Off, and counts how often it has fired, when it last fired and when it fires next. A Draft trigger is staged: it starts nothing until it is turned on. Opening a source on the Providers tab shows what it has received lately and what came of each one, the record to check when you want proof.
A flow that starts on a schedule also appears on Dashboard > Scheduled (/cron), read only, in a Flow triggers panel beside your scheduled tasks. You switch it on and off from the Flows page.
If something goes wrong
It did not fire. Check the switch, then the build: a trigger cannot start a flow whose latest changes have not been compiled and accepted. If the trigger itself has a problem, its line on the row says what it is. For a message trigger, confirm the channel is still connected and the sender is one you have allowed. Then ask your assistant, which can follow the path from source to run and tell you where it stopped.
It fired too often. Switch that trigger off first, or use Disable all triggers in the ... menu of the Library tab to stop every trigger at once. The flows themselves are untouched, so you can switch them back on one at a time. Then ask why: usually the source sends more than you expected, or the trigger is drawn too wide and wants narrowing to one sender or folder.
Approval was blocked. Player One refuses to activate a source that is not ready and says what is missing, most often a captured sample event or a detail the connection needs. Fix that and approve again; nothing was switched on in the meantime.
Where next
Flows explains what a flow is and what the Flows page holds. Make it repeat sets triggers beside the simpler ways of taking a routine off your hands.
Two worked examples run on triggers: inbox triage with your approval and a nightly check that opens a job.