A practical field guide from Automation Ace.
The short answer
Every automation starts in one of three ways: event-driven (it runs when something happens, like a webhook), scheduled (it runs on a clock, like a nightly cron job or polling trigger), or request-response (a caller asks and waits for an answer, like an API endpoint). Choose event-driven for speed, scheduled for batches and sources without events, and request-response when someone needs an immediate result. Robust systems often combine them.
This builds on push vs pull automation and polling vs instant triggers. Part of the automation architecture playbook.
The three patterns
| Pattern | How it starts | Examples of triggers | Typical latency | Example workflows |
|---|---|---|---|---|
| Event-driven | Something happens and the source notifies you | Webhook, instant trigger, message on a queue, incoming email | Seconds | New order → fulfillment; payment failed → dunning |
| Scheduled | A clock fires at set times | Cron, Schedule by Zapier, polling | Minutes to days | Nightly sync, weekly report, daily reminders |
| Request-response | A caller asks and waits for an answer | HTTP API endpoint, function URL, Sub-Zap call | Milliseconds to seconds | Quote calculator, form validation, chatbot tool call |
Event-driven automations
The source pushes an event the moment something happens. Fast and efficient, but events can arrive twice, out of order, or not at all. Design for idempotency and reconciliation. See receiving webhooks and what webhooks can do that APIs can't.
Scheduled automations
A clock starts the run: every 15 minutes, nightly, or the first of the month. Predictable and simple, ideal for batches and for sources without events, but slower and potentially wasteful when nothing has changed. Track a cursor so each run processes only new data. See Cron Triggers and custom Zap schedules.
Request-response automations
A caller sends a request and waits: a form validates an address, a chatbot calls a tool, a Zap calls a function and uses the result. Keep these fast; callers time out. If work takes longer, accept the request, return an ID, and process asynchronously. See building API endpoints with Workers and timeout errors.
Decision table
| If the workflow needs to... | Use |
|---|---|
| React to something within seconds | Event-driven |
| Source has no webhooks or events | Scheduled (polling) |
| Process batches or aggregates (reports, digests) | Scheduled |
| Caller needs an immediate result | Request-response |
| Work takes longer than the caller can wait | Request-response to accept, then event-driven or durable workflow to process |
| Missed events would be costly | Event-driven plus a scheduled reconciliation |
| Strict ordering matters | Event-driven into a queue, processed sequentially |
| Low volume, timing not critical | Scheduled is simplest |
Combining patterns
- Event + scheduled reconciliation: webhooks for speed, a nightly check for anything missed. See the hybrid pattern.
- Request + async processing: an endpoint accepts work, then a queue or durable workflow processes it.
- Scheduled + event fan-out: a nightly job finds due items and emits one event per item for parallel processing.
Where each pattern lives in common tools
- Zapier: instant triggers and Catch Hooks (event), polling triggers and Schedule by Zapier (scheduled), Sub-Zaps and webhooks with responses (request-response).
- Serverless: fetch handlers (request-response or event), cron triggers (scheduled), queues (event). See serverless functions compared.
- Durable engines: start on events or schedules, and wait on events mid-run. See long-running automations.
Record the chosen pattern in the trigger section of your requirements doc.
Frequently asked questions
What are the three basic automation patterns?
Event-driven (runs when something happens, such as a webhook), scheduled (runs on a clock, such as cron or polling), and request-response (a caller asks and waits for an immediate answer, such as an API endpoint).
When should I use a scheduled automation instead of an event-driven one?
When the source has no webhooks or events, when you process batches or reports, or when timing is not critical and simplicity matters most.
What is a request-response automation?
An automation that a caller invokes and waits on for a result, such as an API endpoint used by a form, chatbot, or Zap. It must respond quickly, so longer work should be handed off asynchronously.
Can I combine automation patterns?
Yes. Common combinations include event-driven processing with scheduled reconciliation, request-response intake with asynchronous processing, and scheduled jobs that fan out events per item.
Disclaimer: Templates and checklists are starting points; adapt them to your process, policies, and tools. Product features, limits, and pricing mentioned here change over time, so confirm current details in each vendor's documentation. This article may include links to apps, products, or services; some links may be affiliate links, which means Automation Ace may earn a commission at no extra cost to you.