Workflow Communication Overview

Workflows remain separate durable run instances. They communicate through calls, starts, or events rather than importing one runnable .woml file into another.

Three patterns

• services.workflows.call() starts one workflow and waits for its result.
• services.workflows.start() starts one workflow and immediately returns its run ID.
• services.events.emit() publishes one fact to every exact-name subscriber.

All target workflows must be active in the same runtime and durable state authority. External applications use webhooks or the authenticated event endpoint.

Why runnable workflows are not imports

A runnable workflow owns identity, triggers, policies, history, cancellation, and an independent result. Importing it like a code component would blur those ownership boundaries.

WOML therefore keeps two concepts separate: modules and reusable definitions share implementation inside one run, while workflow communication creates or addresses another durable run.

Follow a parent and child

Imagine process-order needs risk analysis. calculate-risk remains a call-only workflow with no trigger. Activate both files together, then let the parent choose:

• call() when order processing cannot continue without the score.
• start() when risk analysis or follow-up may continue independently.
• emit() when every interested workflow should hear that an order was created.

Every child receives the passed object as its complete context.payload. It does not inherit the parent's context.steps automatically.

Shared runtime authority

Calls, starts, and direct event emission resolve targets through the active workflow set and durable state boundary. Running related files in unrelated state databases creates separate systems that cannot discover one another through local workflow services.

Use woml run parent.woml child.woml or activate a directory so deployment validation can verify target IDs before admission opens.