Lifecycle events
React to workflow changes with the right runtime model: upcoming Cloud events and webhooks, or self-hosted handlers and dispatchers.
Use lifecycle events when something should happen after content changes, but that work should not be hidden inside the editor's save button.
Lifecycle events are records of workflow changes: a draft was saved, a document moved through review, or published content changed. They let the rest of your system react after the content operation has a durable event record.
The runtime matters here. In Dyrected Cloud, think in terms of managed content events and webhook destinations, but treat that Cloud surface as coming soon. In self-hosted Dyrected, you can register TypeScript handlers and run the dispatcher inside your own application today.
The events
Four events fire on workflow-enabled collections:
| Event | Fires when |
|---|---|
revision.created | A working draft is saved. |
workflow.transitioned | Any transition runs, such as submit, publish, reject, or a custom transition. |
entry.published | A transition moves a document into a published state and updates the public snapshot. |
entry.unpublished | A transition marked unpublish removes the document from the public snapshot. |
workflow.transitioned is the broad event. entry.published and entry.unpublished are the narrow events for changes that affect the live site.
Cloud events and webhooks are coming soon
Use the Cloud model when Dyrected hosts the content backend for your site. Cloud events and webhooks are the intended path for content-scoped side effects:
- revalidate a frontend route
- notify a team when a document is ready
- send a signed webhook to another system
- update a search index
- trigger content automation after publish
Keep the boundary tight: Cloud events are for content lifecycle work, not arbitrary application backend hosting. Checkout, customer sessions, product activity, and transactional workflows should stay in your application or the external systems that own them.
Because this Cloud surface is still coming soon, do not build a production Cloud integration that depends on hosted event delivery yet.
Which one to reach for
- Use Cloud events or webhooks for Cloud content reactions once that surface is public.
- Use self-hosted handlers when you need arbitrary TypeScript inside your own server runtime.
- Use
beforeTransitionhooks when logic must block or allow the transition. - Use
afterTransitionhooks for quick same-request reactions that can safely fail without retry.
For the workflow model itself, start with Editorial workflows.
Custom workflows
A WorkflowConfig is a plain state machine — build your own when your process has different states, roles, or rules than the built-in publishing flow, with copy-paste recipes for approval chains, scheduling, and translation.
Overview
Watch a document render on your real site as you edit it — draft data streams into a preview pane beside the form, and editors can click the page to jump to the field behind it.