Events and Workflow Services

These managed capabilities connect separately running workflows.

Service	Behavior
`services.events.emit()`	Broadcast a named event to all active subscribers.
`services.workflows.call()`	Start one workflow and wait for its JSON result.
`services.workflows.start()`	Start one workflow and immediately return its run ID.

Every operation should receive a stable name option when one step performs external effects. The runtime records admission and outcomes without copying complete payloads into operational inspection.

Read Workflow Communication Overview for design guidance.

Use explicit operation names

JavaScript

const child = await services.workflows.start(
  "send-follow-up",
  { customerId: context.payload.customerId },
  { name: "start-customer-follow-up" }
);

const publication = await services.events.emit(
  "customer.processed",
  { customerId: context.payload.customerId },
  { name: "publish-customer-processed" }
);

return {
  childRunId: child.runId,
  publicationId: publication.publicationId
};

Stable names identify logical effects within one step and remain constant across retries. Use distinct names when a script performs several workflow operations.

The target workflows must be active under the same durable state authority. These services do not discover arbitrary WOML processes across unrelated state databases or machines.

Calls and starts pass only the supplied payload. Events fan out only to exact-name subscribers. No operation copies a parent's complete context into another workflow implicitly.