Trigger
- Standard term
A trigger is whatever starts an agent or automated workflow running, such as a schedule, an incoming email, a file change, a crossed threshold, a request from another system, or a button press.
A trigger works one of two ways. A schedule starts the run at set times, whether or not anything changed. An event trigger starts the run as soon as something happens, which it hears about from the other service, such as your email provider announcing a new message.
Where you’ll meet it
You set up an agent that adds a field trip to the family calendar whenever the school emails about one. This week the museum trip shows up three times, because the school's system sent the same email three times.
What to do
Change what starts the agent. Instead of a run per school email, have it run each evening on that day's school emails and add each trip once. The three copies then land in one run together. Run it on this week's emails and check that the museum trip appears once.
Easy to mix up
| Trigger | Action |
|---|---|
| From the clock or the outside world, such as the school's email | From the agent's own instructions, like the step that adds the trip |
Check yourself
You want an agent to remind you when a client hasn't answered your proposal within a week. Which of these can start that run?
Go deeperSchedules are written as compact codes, and event notices can arrive twice
Developers write schedules as cron expressions, a compact code such as “0 18 * * 0” for every Sunday at 6 p.m. Event triggers usually arrive as webhooks, messages one service sends another when something happens, or as items dropped into a queue for the agent to pick up.
Many event systems deliver each event at least once, which sometimes means twice, and not always in order. A run that a repeat could harm needs an idempotency key, a marker that lets it recognize work already done. The event's ID catches a repeated delivery, but a sender that repeats the news in a fresh message, as the school's system did, gives it a new ID.