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.

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

1. Tell your assistant what should start the flow, in ordinary words: "start the claims flow when something lands in the claims inbox".
2. Read the plan it gives you. It names the source and what it will treat as an event before anything is connected.
3. 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.
4. Put any password or key into the secure field it opens, never into the conversation itself.
5. 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.
6. 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.
7. Check the flow's row on the Library tab of Automations > Flows (/manage/flows). The trigger is listed there with a switch, and the source appears on the Providers tab, switched on.

Checking it works

Open the flow's row and press the test button beside the trigger. That fires it as though the real event had happened.

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 counts how often it has fired, when it last fired and when it fires next. 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 Automations > Scheduled (/cron), read only, 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 at the top 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.