Starting an AI Employee Automatically with Triggers

By default, an AI Employee only runs when someone opens it and starts it by hand. Add a trigger when a run shouldn't depend on someone remembering to start it: a recurring report, a reply that has to go out within minutes of a ticket landing, or a backlog that needs picking up as records show up in another system.

Three kinds of trigger are set up in the builder, and they differ in one thing: what starts the run.

• A scheduled trigger runs on a clock you set.
• A webhook trigger runs when another system tells Ema that something happened.
• A poll trigger runs when Ema checks another system and finds something new.

This page helps you pick the right one. Each kind then has a guide of its own.

Which trigger do I need?

Start from what you already know about when the work should happen.

You know when it should run. "Every Monday at 9am." "Every night." "Once an hour." Nothing needs to happen elsewhere first. The time itself is the reason to run. That's a scheduled trigger. What the workflow does once it starts is a separate matter: the first Agent might fetch data from another app, or the whole thing might never leave Ema. Both are ordinary.

Something happens elsewhere and you want to react straight away. A ticket is raised, a form is submitted, a deal closes, and waiting even a few minutes is too slow. This works only if the other system can send messages out when things happen. That's a webhook trigger, and it's the only kind that reacts immediately.

Something happens elsewhere, but that system can't tell you. Plenty of systems have no way to notify you when something changes. Ema can check them on a rhythm instead, and start a separate run for each new thing it finds. That's a poll trigger.

Comparing the three

Scheduled triggers

A scheduled trigger runs your AI Employee on a repeating cadence: every 15 minutes, every Tuesday at 6pm, the first of the month. You pick the pattern from a list of common ones, or write your own timing if you need something unusual. You also choose a time zone, so "9am" means 9am where your team actually is.

Each firing produces one run, using the inputs you saved on the schedule. Those are mostly fixed values, but you can also drop in the date or time of the firing itself, so a daily schedule can tell your workflow which day it's running for. One AI Employee can have several schedules at once (a quick hourly check and a fuller weekly pass, for example), and they don't block each other.

Schedules can also be started by a workflow Agent rather than set up by hand. A workflow-started schedule appears on the same Cron page and in the same metrics as any other schedule, so there is one place to review all of them regardless of how they were created.

Set up a scheduled trigger →

Webhook triggers

A webhook trigger gives you a URL. When another system sends a message to that URL, your AI Employee starts running. There's no clock to wait for and no check to come round. It's the only trigger that reacts the moment something happens, so it's the right choice whenever a delay actually costs something.

The trade-off is that setup is a two-sided job. Ema gives you a URL and a secret; someone with access to the other system has to paste them in and configure it to send. You'll also decide how Ema checks that incoming messages genuinely come from that system, rather than from somebody who guessed your URL.

Set up a webhook trigger →

Poll triggers

A poll trigger is for systems that can't call you. On a rhythm you choose (anywhere from every 5 minutes to once a week), Ema runs a short script that fetches from the other system.

What happens to the results is then up to how you set it up. The usual choice, and the reason most people reach for polling, is one run per item with Ema keeping track of what it has already seen: a batch of forty new records becomes forty runs rather than one run holding a pile of data, and the same record doesn't get handled twice. It also copes with downtime: when a paused trigger is switched back on, it can catch up on what it missed.

Email poll triggers show a Not delivering badge next to the trigger name when the trigger is enabled but its connection is failing. If you see this badge, the trigger is enabled but no emails are being processed. Open the trigger and reconnect the mailbox in Settings, then reselect it.

On a published poll trigger, you can swap the connection used by an integration slot without republishing. Select Change on the slot from the trigger card, pick the new connection, and confirm. The next check runs with the new connection straight away, and the failure count resets. The app itself is part of the published recipe and can only change on the next publish.

Set up a poll trigger →

Slack channel @-mentions

When a Slack channel is connected to an AI Employee with conversation enabled, users can start a conversation by @-mentioning the bot directly in a channel. The AI Employee replies in a thread under that mention, and each top-level mention opens its own conversation. To continue the same conversation, the user @-mentions the bot again inside that thread.

Thread context

A mention inside an existing thread carries the thread's history into the turn. Ema reads the messages posted since the bot's last reply in that thread and passes them to the AI Employee as quoted context, oldest first, alongside the user's request. This means the AI Employee can respond with awareness of what was already said without the user having to repeat it.

The thread read requires the channels:history and groups:history scopes on the connected workspace's bot token. If those scopes are missing, the turn still runs on the tagged text alone. Workspaces connected before these scopes were added need to reconnect to pick them up.

A few details about how context is bounded:

• Only messages posted after the bot's most recent reply are included. Earlier exchanges are already in the session history.
• The context block is capped at 30 messages and 8,000 characters total, with individual messages capped at 2,000 characters. When the limit applies, the newest messages are kept.
• When Slack returns a truncated result (the thread is too long, or the rate limit was hit), only the thread's opening message is shown and the AI Employee is told the rest could not be read.
• The thread context is treated as quoted, untrusted input. Users cannot use it to issue instructions to the AI Employee.
• The session title is taken from the user's request text only; the thread context block is not part of it.

Senders from outside the workspace

A mention from a Slack Connect user in a shared channel, or from a user in a sibling Enterprise Grid workspace sharing an externally shared channel, is silently ignored. Ema cannot verify that their Slack email maps to a workspace account, so no turn is started and no reply is posted.

What doesn't change

A @-mention in the thread of a workflow approval or HITL card is treated as a new conversation turn, not as an answer to the card. Only a plain (non-mention) reply in that thread answers the card.

What every trigger shares

Whichever kind you choose, these things work the same way.

Publish first. A trigger can't start anything until the AI Employee has been published at least once, and it runs your published work rather than your drafts, so saving a draft changes nothing about what fires. See Build your first workflow.

Every run happens as somebody. Nobody is present when a trigger fires, but the run still needs permissions to do its work. So every trigger carries a Runs as user, and the run is checked against that person's access. If they leave, you don't rebuild the trigger: an administrator reassigns Runs as and it carries on.

Turning it off isn't the same as deleting it. Every trigger can be disabled and left in place, keeping its settings and its history. Use that when pausing something temporarily: deleting and rebuilding loses the setup, and for a webhook it means handing the other system a new URL.

Autopilot can set up any of the three. Instead of working through the forms yourself, describe what you want in plain language ("run this every weekday at 8am", "start this whenever a ticket is raised") and Autopilot creates the trigger for you. It can't invent the things only the other system knows, though, such as how that system signs its messages or how to ask it what changed, so on webhook and poll triggers you'll still finish those parts yourself.

Trigger runs are ordinary dashboard rows. Every run has one origin: either a person started it or a trigger did, never both. But a trigger's run isn't filed away anywhere separate. It appears as a regular row on the AI Employee's dashboard, in the same table and the same shape as any other, so there's one place to review everything. Webhook and poll triggers additionally keep a delivery log: a record of every message received or check performed, and what came of it.

Reviewing triggers across your whole workspace. The Triggers tab on the workspace Metrics page lists every trigger in one table, regardless of which AI Employee owns it. Use the time range selector to focus on a specific window, then click any row to open a delivery drawer showing that trigger's run history in place, without leaving the table.

What's next

• Scheduled triggers — recurrence patterns, time zones, and what to check when a schedule doesn't fire.
• Webhook triggers — the URL and secret, verifying senders, testing, and monitoring deliveries.
• Poll triggers — the fetch script, one run per item, intervals, and catching up after downtime.
• Creating a Dashboard AI Employee — the type all three triggers require.
• Triggering AI Employees — the API behind these, plus the other ways a run can start.