Event-Driven vs Scheduled Workflow Automation

Something happened, or a time arrived

Event-driven automation evaluates work because a defined change occurred. Scheduled automation evaluates work because a configured time or recurrence became due. The choice is about what makes work eligible, not which approach is more advanced.

An event might indicate that a record was created or a supported business transition occurred. A schedule might check eligible records every business morning. A timer inside an existing process is a third idea: it continues an instance after a wait rather than necessarily starting a new one.

Compare the operating requirements

Make an event useful without making it omnipotent

Define the event’s meaning, source and business identifier. “Record updated” may be too broad if the real requirement is “request became ready for review.” A matching condition can narrow that meaning, but it must handle repeated changes and changes caused by the automation itself.

Decide what evidence shows an occurrence was accepted and what evidence shows its work completed. Those are different checkpoints. If the consumer fails after acceptance, recovery needs the original identity and context. If downstream changes create new events, bound the allowed chain rather than assuming it will terminate.

Define the calendar and missed-occurrence policy

“At 09:00 every weekday” is incomplete without a time zone and a definition of weekday or business day. A fixed UTC offset is not a substitute for a named zone when local clock rules change. IANA’s time-zone database records changes to offsets and daylight-saving rules; schedule implementations need a maintained interpretation of those rules.

• IANA: Time Zone Database

For a local time that does not exist during a clock change, decide whether to skip or move the occurrence. For a local time that occurs twice, decide whether one or two occurrences are intended. These are policy choices to verify in the selected product, not assumptions to hide in the user interface.

A missed-occurrence policy answers what happens after downtime or suspension. Catching up every missed run may be appropriate for distinct accounting periods but dangerous for reminders. Skipping or coalescing may be sensible elsewhere. Bound any catch-up and check whether the underlying record is still eligible before acting.

Both models need duplicate handling and recovery

Use a stable identity for the intended unit of work: an event identifier or a schedule-plus-occurrence identity. A retry should refer to that unit rather than invent a new one. Duplicate detection within one service cannot alone prevent repeated effects at another service; the action contract matters too.

Keep recovery observable. An operator needs to know the expected occurrence, actual attempt, result and available next action. Distinguish delayed eligibility from failed execution. Avoid retrying indefinitely when a record is invalid or a destination has already applied the requested change.

• Read the workflow reliability model

Combine patterns without multiplying work

Illustrative design: a submitted request creates review work through an event; a daily operational check identifies still-open requests that need attention. The daily check should not create a second copy of the original review. Give it a separate purpose, such as identifying an unresolved condition, and define how it recognizes already-handled cases.

A business calendar can refine when periodic work is eligible, while the process itself still owns its state. Document whether a calendar change affects only future occurrences or also previously scheduled work. An explicit rule is easier to operate than an implicit assumption about “the next working day.”

Choose from the business condition

1. If a specific change makes the work necessary, begin with an event.
2. If elapsed calendar time makes work necessary, begin with a schedule.
3. If an existing case must wait before continuing, evaluate a process timer.
4. If both change and elapsed time matter, assign each mechanism a distinct responsibility.
5. For every choice, specify identity, eligibility, delayed-work policy and operational ownership.

WorkflowRight exposes bounded event triggers, scheduled automation, recurrence and business calendars. Its automation and architecture pages are the authority for supported behavior. Do not assume arbitrary event-bus subscriptions, unrestricted event chains, arbitrary scripts or exact real-time execution.

• Supported triggers, schedules and calendar behavior
• Execution and recovery architecture