> Source: https://builder.ema.ai/v2/builder-guides/automatic-ai-employee-triggers > Title: Starting an AI Employee Automatically with Triggers # 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. > [WARNING] > **Triggers need a Dashboard AI Employee.** All three kinds work on Dashboard AI Employees only — Chat and Voice AI Employees cannot be started this way. If yours isn't a Dashboard AI Employee, start with [Creating a Dashboard AI Employee](/builder/v2/builder-guides/dashboard-ai-employee). ## 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**. > [TIP] > Not sure whether the other system can send webhooks? Look in its settings for "Webhooks", "Outgoing webhooks", or "Notifications". If there's nothing like that, a poll trigger is your answer. ## Comparing the three Scheduled Webhook Poll **What starts it** A clock you set The other system, sending to Ema Ema checking the other system **How fast it reacts** At the next scheduled time — 15 minutes apart at the closest Immediately At the next check — 5 minutes apart at the closest **Runs it produces** One per firing, using the inputs you saved on the schedule One per message received One per item, if you set it up that way **Keeps track of what's new** No — your workflow does that itself The sending system decides what to send Yes, if you choose to **Can fetch external data** Yes, using Tools Yes Yes **Needs from the other system** Nothing It must be able to send outgoing webhooks An API Ema can read **Set up before you begin** Nothing Admin access to the sending system, and its signing documentation A working connection to the app, already set up in Integrations ## 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. [Set up a scheduled trigger →](/builder/v2/builder-guides/triggers-scheduled) ## 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 →](/builder/v2/builder-guides/triggers-webhook) ## 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. [Set up a poll trigger →](/builder/v2/builder-guides/triggers-poll) ## 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](/builder/v2/builder-guides/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](/builder/v2/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. ## What's next - [Scheduled triggers](/builder/v2/builder-guides/triggers-scheduled) — recurrence patterns, time zones, and what to check when a schedule doesn't fire. - [Webhook triggers](/builder/v2/builder-guides/triggers-webhook) — the URL and secret, verifying senders, testing, and monitoring deliveries. - [Poll triggers](/builder/v2/builder-guides/triggers-poll) — the fetch script, one run per item, intervals, and catching up after downtime. - [Creating a Dashboard AI Employee](/builder/v2/builder-guides/dashboard-ai-employee) — the type all three triggers require. - [Triggering AI Employees](/builder/v2/api-reference/triggers) — the API behind these, plus the other ways a run can start.