Answer
The difference matters because a clock does not prove that a dependency finished. A 2:00 AM start may be predictable, but it can still run too early when an upstream file is late. An event trigger can wait for the real condition, but it needs timeout, retry, duplicate protection, and a clear failure owner.
Map each workflow step to the condition that truly makes it safe to run. Then define what happens when that condition never arrives, arrives twice, arrives incomplete, or arrives after the business deadline. The scheduler should make those exceptions visible instead of turning them into silent delays.
Choose the trigger that matches the real dependency
The strongest workflow may use a clock for the outer business window and an event for each dependency inside it. This table shows what the scheduler must prove before either trigger can be trusted.
| Trigger | Choose it when | Failure to design for | Control to require |
|---|---|---|---|
| Clock or business calendar | The work is safe at a known time, day, period end, or holiday rule. | The schedule starts even though an upstream dependency is late or incomplete. | Calendar exceptions, dependency check, late-start rule, missed-window alert, and restart history. |
| File arrival | A complete IFS file, physical file update, or partner delivery is the real starting condition. | A partial write looks complete, the same file arrives twice, or nothing arrives. | Stable-size or trailer check, duplicate key, timeout, quarantine, and named escalation. |
| API response | Another system confirms that data or approval is ready through an API call. | The call times out, repeats, returns an error, or succeeds after the caller gives up. | Idempotency, retry limits, response logging, dead-letter handling, and status reconciliation. |
| Upstream job or system state | A job, queue, message, data area, subsystem, or cross-platform process must reach a known state first. | Polling adds load, the state changes briefly, or success hides incomplete business data. | State definition, polling interval, persistence check, timeout, and proof of downstream readiness. |
| Human approval | A person must review an exception, amount, release, or business decision before work continues. | The request waits forever, reaches the wrong approver, or proceeds without evidence. | Named role, delegation, reminder, escalation, expiry, decision history, and safe cancellation. |
| Hybrid trigger | A workflow has a business window but should run only when its real dependencies are ready. | One control says run while another says wait, leaving ownership unclear. | Precedence rule, shared status, one failure owner, retry boundary, and a final deadline action. |