Time, waits, and time events
Ormuz uses time in two different ways: a node Wait may suspend an existing instance until a deadline, while some platform events are emitted when a business object reaches a time-based condition and can start new instances.
Two uses of time not to confuse
| Need | Primitive | Effect |
|---|---|---|
| Resume the same process later | Wait | The current instance enters waiting, then resumes at the same node. |
| React to a business due date | Time event + launcher | The platform emits an event; a subscribed process may start a new instance. |
When the need is driven by a known deadline or platform time event, the process can remain declarative. Your integration does not need an external loop solely to know when to resume or start handling.
Suspend an instance with Wait
The node Wait accepts either a duration or an absolute date and time. When the deadline is in the future, the instance enters waiting and resumes when the deadline is reached. A zero duration or already-past date completes immediately without creating a durable wait.
Wait preserves the same instance: execution context remains that of the process already started.
Durations may be expressed in seconds, minutes, hours, or days. The maximum product bound is 366 jours for one wait; a value beyond it is rejected rather than silently transformed.
Use Wait when logical continuation belongs to the same instance. If the need is “start a new process when an invoice becomes overdue”, prefer the corresponding time event.
Trigger from a business time event
Some platform objects expose events whose condition depends on time and business state, for example invoice.overdue, invoice.due_date_stage_reached, receivable.overdue or supplier_invoice.overdue.
The event expresses a business condition that became true. A launcher can use it as the trigger of an independent process.
These events do not simply mean “the date has passed”. The platform applies the associated business contract. For example, an invoice should not keep producing an overdue event when its balance is no longer due.
The event catalog documents the conditions and data specific to each event: Platform event catalog.
Deduplication and rearming
A time event is not re-emitted at every check while the same business episode remains active. The platform remembers that a condition already triggered its event and avoids duplicates for that event/resource combination.
When the resource becomes ineligible again, this memory may be rearmed. If it later enters a new eligible episode, the event may then be emitted again. This distinguishes a genuine second overdue episode from a technical repetition of the first.
A due-date schedule may define several thresholds, for example D−3, D, D+7, and D+30. Each threshold is a distinct business occurrence: reaching D+7 does not replay D, and changing configuration invalidates thresholds no longer part of the active schedule.
Choose the right model
- Wait in a journey: use
Waitto resume the same instance after a delay or at a precise date. - Reminder tied to an object: use a platform time event and launcher when the deadline belongs to the business object's lifecycle.
- Operation retry: configure the process retry policy rather than manually adding a
Waitaround a failing node. - Business schedule: prefer threshold events when they exist rather than duplicating date calculations across several processes.
See Errors, retries, and idempotency for error-resume policy.
Observe a wait or trigger
An instance suspended on Wait appears in waiting status with the relevant node. When it resumes, the graph preserves this step in its history. For a time event, the event remains inspectable like other platform events and the new instance indicates its trigger source.
This distinction helps diagnosis: if a reminder did not happen, first check whether the business event was emitted; if an existing instance did not resume, inspect the Wait node and its deadline.
See Observability.