Scheduled Triggers

A scheduled trigger does one thing: it starts your AI Employee on a cadence you choose. Every 15 minutes, every Tuesday at 6pm, the first of the month — you set the pattern, and Ema starts a run each time it comes round.

What the AI Employee does once it starts is entirely up to the workflow, and most scheduled work involves nothing outside Ema at all: summarizing what arrived that week, generating a report, tidying up a table. Fetching data from another system is possible but optional, and covered further down.

For help choosing between this and the other kinds of trigger, see Starting an AI Employee Automatically.

Setting up a schedule

You can ask Autopilot to set a schedule up for you in plain language — "run this every weekday at 8am" — or add one yourself:

1. Open the AI Employee builder and select Start.
2. Find the Schedules section.
3. Click Add.
4. Give the schedule a name, choose how often it should run, and save.

The name is for your benefit — it's how you'll tell schedules apart later, so "Monday morning digest" beats "Schedule 1".

One AI Employee can have as many schedules as you need, each with its own cadence, inputs, and Runs as user. If you give one of your own schedules exactly the same cadence and time zone as another of yours, Ema stops you — that would be a straight duplicate. Two different people can each hold a schedule with identical timing, though, since those count as genuinely separate jobs.

Choosing the recurrence

Pick a pattern from the list rather than writing timing by hand:

Times are chosen on the quarter hour — on the hour, or 15, 30, or 45 minutes past. Monthly schedules offer days 1 to 28 only, because days 29 to 31 don't exist in every month and a schedule that silently skips February isn't much of a schedule.

Custom (cron) is there for patterns the presets can't express — "every weekday but not weekends", "twice a day at odd times". It takes a five-field cron expression. If you haven't written cron before, it's worth asking Autopilot to write it for you, then checking the plain-English summary shown on the schedule's row.

Time zones

Every schedule carries a time zone, and it defaults to the one your own computer is set to. Change it if the schedule should follow somewhere else — a report for a team in Berlin should fire on Berlin's morning, not yours.

Time zones are real named zones (like Europe/Berlin or Asia/Kolkata), not fixed offsets. That matters for daylight saving: a 9am schedule stays at 9am local time through the clocks changing, rather than drifting to 8am or 10am for half the year.

The schedule's row shows the cadence and time zone together, so you can confirm at a glance that "9:00 AM" means the 9am you intended.

The inputs a schedule sends

If your workflow's Start expects inputs, the schedule has to supply them — there's no person there to type them in. You set those values once, on the schedule, and every firing uses them.

Two kinds of value are available:

• A fixed value you type in, used unchanged every time.
• A dynamic value — the date or time of the firing itself. Use the Dynamic value picker beside a field to insert either the firing's date (in the schedule's own time zone) or the exact moment it fired (in UTC).

That second kind is what makes a daily schedule genuinely useful: the workflow can be told which day it's running for, so a "yesterday's summary" report knows what yesterday means.

If a field takes a file, you upload it once when setting the schedule up, and every firing reuses that same file.

Who the runs run as

Every schedule carries a Runs as user, and its runs are performed with that person's access. A schedule can't do anything that person couldn't do themselves.

It defaults to you. Administrators can point a schedule at someone else; everyone else's schedules run as themselves.

If a run pauses for human approval, the pause is assigned to the Runs as person — but anyone with access to the dashboard can act on it, so approvals don't stall just because that person is away.

This is also how you hand a schedule over. If the Runs as person leaves, or loses access to something the workflow depends on, the runs start failing — and the fix is to reassign Runs as, not to rebuild the schedule. Anything long-lived should have a plan for who takes it on.

Optional: fetching external data

Most scheduled workflows don't need this section.

A schedule sends the same fixed inputs every time, but that's no limit on what the workflow does once it's running. Add a Tool and it can call out to another system at run time, exactly as it would on a manual run.

This works well when what you want is a picture of how things stand right now:

• Monday morning pipeline report — every Monday at 8am, fetch all open deals and summarize them.
• Nightly stock check — every night, read current inventory levels and flag anything running low.
• Weekly ticket digest — every Friday, pull the week's closed tickets and write up the themes.

What those have in common: the schedule decides when, the Tool fetches whatever is there at that moment, and one run handles the lot. Nothing has to remember what happened last week.

Where a schedule starts working against you is when you want to act on each new thing individually — reply to every new ticket, process each new application. Your workflow would have to work out for itself which records it hasn't seen before, keep track of the ones it has already handled, and cope when one fetch returns forty records and there's a single run to deal with all forty. A poll trigger does that part for you.

Use a schedule when the timing is the point, and a poll trigger when the individual items are.

Publishing

A schedule can be created on an unpublished AI Employee, but it can't be enabled until you've published at least once. The Schedules section says so directly:

Schedules can be created now, but enabling needs a published version. Scheduled runs always use the latest published version.

That last part matters more than it looks. Schedules follow your published work, not your drafts: publish an improvement and the next firing picks it up automatically, while edits left as a draft change nothing. If a schedule seems to be behaving like an older version of your workflow, check whether your changes were actually published.

When a firing is skipped

If the previous run from a schedule is still going when the next firing is due, Ema normally skips that firing rather than starting a second, overlapping run.

Skipping is per schedule, not per AI Employee. Two schedules on the same AI Employee never block each other — a slow weekly run won't stop the hourly one.

A skipped firing isn't silent: it's recorded on the dashboard along with the reason, so a schedule quietly falling behind is visible rather than invisible. If you see skips regularly, the runs are taking longer than the gap between firings, and the cadence needs to be wider.

Testing it

You don't have to wait for the clock. Open the schedule's row menu and choose Test run to fire it once, immediately, using that schedule's own inputs and Runs as user. The run appears on the dashboard marked as a test, so it's easy to tell apart from real firings.

This is the fastest way to confirm the inputs are right before leaving a schedule to run overnight.

Monitoring scheduled runs

• On the schedule itself — each row shows its cadence and time zone, and, once it's switched on, its Next run time. A schedule that's off doesn't show one, which is why a brand-new schedule looks blank there.
• Across the Workspace — the Cron Scheduler page lists every schedule in the Workspace with its AI Employee, cadence, status, next and last run, and how many runs it produced in the last 30 days. It also shows each schedule's Runs as user, under a column headed Owner. It's the quickest way to see everything at once.
• The runs themselves — runs a schedule produced appear as regular rows on the AI Employee's dashboard, the same as any other run. See Launching and Monitoring.

Turning it off, and deleting

The switch on a schedule's row turns it off while keeping everything else — cadence, inputs, Runs as user, and history all stay put, ready to switch back on. That's what you want for a pause.

Deleting is different: the schedule stops firing and leaves the list for good, though runs it already produced stay on the dashboard. You'll be asked to confirm first.

It didn't fire — what to check

Work down this list in order; the first two account for most cases.

1. Is it switched on? New schedules are created switched off. Check the switch on its row.
2. Has the AI Employee been published? Enabling needs a published version, and firings use the latest published one.
3. Does the row show "Needs attention"? Its saved inputs no longer match what the workflow requires. Hover for the reason, then edit the schedule.
4. Is the previous run still going? A firing is skipped when the last one hasn't finished. Look for skipped entries on the dashboard.
5. Is the time zone what you assumed? Check the zone on the row, not just the time — 9am in the wrong zone is the most common cause of "it ran, but not when I expected".
6. Are you expecting it more often than every 15 minutes? That's the floor. Use a webhook or poll trigger instead.

If it fired but failed, the run is on the dashboard with its error — open it there. A firing that couldn't run at all, because nothing was published or the workflow was broken, is also recorded, and can be re-run once you've fixed the cause.

What's next

• Starting an AI Employee Automatically — choosing between the three kinds of trigger.
• Poll triggers — when you need one run per new item instead of one run per firing.
• Build your first workflow — publishing, and the save / test / publish model.
• Launching and Monitoring — where runs and their history live.