Publish an Event

Events broadcast a fact without coupling the publisher to a single workflow result.

return services.events.emit("customer.updated", {
  customerId: context.payload.customerId
}, { name: "publish-customer-update" });

Every active exact-name <event> subscriber validates and admits independently. Publication may therefore be fully accepted, partially accepted, or rejected. Use a stable operation name so retries preserve managed effect identity.

Events are fast local communication, but they are not a request-response call. Use Call a Workflow when the publisher needs one answer.

Design events as facts

Good event names describe something that already happened: order.created, customer.verified, or report.generated. Avoid command-like names such as please-send-email; commands usually target one owner and fit a workflow call or start better.

Publish and inspect the result

const publication = await services.events.emit(
  "customer.updated",
  {
    customerId: context.payload.customerId,
    changedFields: ["email"]
  },
  { name: "publish-customer-updated" }
);

return {
  publicationId: publication.publicationId,
  accepted: publication.accepted,
  rejected: publication.rejected
};

No subscribers is a successful no-op. With several subscribers, each schema and admission policy settles independently, so publication may be accepted, partial, or rejected.

The payload must be a top-level JSON object no larger than 1 MiB. The runtime limits lineage depth and rejects cycles to prevent uncontrolled event recursion.

Keep subscribers independent

A publisher should not depend on subscriber order or completion. If one exact downstream outcome is required, call that workflow directly. Events provide fan-out and loose coupling, not a distributed return value.