Answer
Event triggers come in a few practical flavors on IBM i: watching the IFS or a physical file for arrival, polling a data area or flag file, reading a message queue, or receiving an inbound API call from a partner or another system. Each has a different failure mode. File-watch triggers can fire on a partial write if the sending system does not use an atomic rename or a trailer record, so the scheduler needs a way to confirm the file is complete rather than just present. API-driven triggers need a retry and dead-letter strategy for when the calling system is unavailable, not just a single attempt that silently fails.
Buyers should also weigh polling frequency against system load. Checking for a trigger every thirty seconds is different from checking every ten minutes, and aggressive polling across dozens of workflows can create measurable overhead on a busy LPAR. The mapping exercise pays off here too: for each step, ask whether the trigger is a clock, a system event, or a person clicking approve, since human approval gates often get modeled as time delays when they should be modeled as explicit wait-for-event steps with their own escalation if nobody responds.