Choose Call, Start, Event, or Webhook
| Need | Use |
|---|---|
| One child result before continuing | services.workflows.call() |
| Independent child work | services.workflows.start() |
| Notify every interested workflow | services.events.emit() |
| Receive work from another application | <webhook> |
Ownership rule
Call, start, and internal emit require workflows active under the same WOML runtime and state boundary. Webhooks cross application and process boundaries through HTTP.
Coupling rule
A call couples the parent outcome to the child. A start couples only admission. An event couples publishers and subscribers only through an event name and payload schema.
Ask four questions
Choose the primitive by answering:
- Does the caller need one result before continuing?
- Is there exactly one owner of the requested work?
- Should every interested workflow receive the message?
- Is the caller outside the WOML runtime boundary?
One required answer points to call(). Independent work owned by one workflow points to start(). A broadcast fact points to an event. An external application boundary points to a webhook or authenticated event endpoint.
Example decisions
Use call for “calculate this customer's risk and return the score.” Use start for “generate a follow-up report while the order continues.” Use event for “an order was created; every subscriber may react.” Use webhook for “our public API accepted an order request.”
Avoid accidental coupling
Do not use an event when the publisher secretly expects exactly one subscriber. Do not use a synchronous call for work that may wait days for human approval. Do not use a webhook between workflows in the same local runtime merely to imitate a function call.
The simplest correct communication pattern is easier to recover and explain than a clever indirect chain.