A trigger is the event, schedule or signal that starts a run of an automated workflow. It defines when automation begins and supplies the initial data payload, such as the new record, the received message or the current time, that the following conditions and actions work with.
In automation fundamentals, the trigger is the entry point of every workflow: without one, a workflow is only a definition that never executes. Choosing the right trigger type determines how quickly automation reacts, how much load it creates, and how reliably it handles every relevant event exactly once.
How a trigger starts an automated workflow
A trigger works by watching a source for a defined occurrence and creating a new workflow run when that occurrence happens. Each run receives a trigger payload, which typically includes an event identifier, a timestamp and the relevant data, for example the fields of a new form submission.
After the trigger fires, the workflow usually evaluates conditions that decide whether to continue, then executes one or more actions. The trigger itself should stay narrow and fast; filtering and business logic belong in the following steps, where they are visible and testable.
| Building block | Role | Example |
|---|---|---|
| Trigger | Starts the run and supplies data | New invoice uploaded |
| Condition | Decides whether or which path continues | Amount above 10,000 |
| Action | Performs a step | Request manager approval |
| Workflow state | Tracks progress of the run | Waiting for approval |
Types of triggers
Triggers fall into a few recognizable families that differ in how the automation learns about an event. Most automation platforms, integration tools and RPA products support several of them.
| Trigger type | How it detects events | Typical latency | Typical use |
|---|---|---|---|
| Webhook (push) | Source sends an HTTP request | Seconds or less | SaaS events, payment notices |
| Polling | Automation checks the source periodically | One interval, often 1 to 15 minutes | Systems without push support |
| Schedule | Clock or cron expression | Fixed times | Nightly reports, periodic syncs |
| Message or queue | New message on a queue or event bus | Near real time | Decoupled system integration |
| Database change | Insert, update or delete detected | Near real time | Data synchronization |
| File or email | New file or message arrives | Seconds to minutes | Document intake |
| Manual | User clicks a button or form | Immediate | On-demand processes, testing |
Schedules are often written as cron expressions, a five-field notation for minute, hour, day of month, month and day of week. The expression “0 6 * * 1-5”, for example, means 06:00 on weekdays, evaluated in the time zone configured for the scheduler.
Webhook versus polling triggers
The most frequent design choice is between push-based webhooks and pull-based polling. Webhooks react faster and create less load, while polling is simpler to set up and recovers more easily from outages, because the automation can always ask again.
| Aspect | Webhook trigger | Polling trigger |
|---|---|---|
| Reaction speed | Near real time | Limited by polling interval |
| Load on source | Only when events occur | Constant, even with no events |
| Setup | Needs a reachable endpoint and registration | Needs only read access |
| Missed events | Possible if endpoint is down | Recoverable with a cursor |
| Security | Requires signature verification | Uses normal authentication |
| Ordering | Events may arrive out of order | Ordered by query, if designed so |
Robust integrations often combine both: a webhook provides speed, and a periodic reconciliation poll catches any events that the webhook delivery missed.
Designing reliable triggers
Most delivery mechanisms guarantee at-least-once delivery, which means the same event may arrive twice. A reliable workflow therefore treats the trigger as a possibly repeated signal and makes its actions idempotent, so that processing a duplicate has no additional effect.
| Concern | Recommended practice | Reason |
|---|---|---|
| Duplicate deliveries | Deduplicate by event ID | Prevents double actions |
| Webhook authenticity | Verify signatures and timestamps | Blocks forged or replayed requests |
| Slow processing | Acknowledge fast, process asynchronously | Avoids sender timeouts and retries |
| Event bursts | Queue and rate-limit runs | Protects downstream systems |
| Polling gaps | Store a cursor or last timestamp | Resumes without losing events |
| Schedules across regions | Set explicit time zones | Avoids daylight saving surprises |
Every trigger should also be observable: logs should record each received event, its identifier and the resulting run, so that operators can answer whether a missing outcome was caused by the trigger or by a later step.
Common trigger mistakes
Trigger problems tend to be silent, because a workflow that never starts produces no error. The following mistakes are among the most frequent:
- Infinite loops: an action updates the same record that fires the trigger, starting the workflow again and again.
- Overly broad triggers: firing on every update instead of a specific field change floods the system with runs.
- Expired credentials or webhook registrations: the trigger stops receiving events without visible failure.
- Assuming order: processing events as if they arrive in sequence corrupts state when they do not.
- Missing backfill: a trigger enabled today does not process records created before it existed.
The simple explanation
A trigger is the starting signal for an automated task. It answers the question of when the automation should begin.
Think of a motion sensor that switches on a hallway light. The movement is the trigger, and the light turning on is the action. In software, a trigger might be a new email, a submitted form or a set time each morning, and it sets off a chain of steps without anyone pressing a button.
How it is used in practice
An online shop wants every new order to reach its warehouse system and its accounting software within a minute. Its order platform can send webhooks, so the team registers a webhook trigger for the order-created event and verifies each request’s signature.
The workflow acknowledges each webhook immediately and places the event on a queue. It stores processed order IDs to skip duplicates, then creates the shipment and the invoice. A reconciliation poll every 30 minutes compares recent orders with processed ones and starts runs for any that were missed.
During a short outage of the workflow service, several webhooks fail, but the reconciliation poll recovers every missing order within the next cycle. No order is shipped twice, because the duplicate check blocks repeated deliveries.