The workflow functionality passes a Content item version through a series of stages.
For example, an editorial workflow can pass a Content item from draft stage through design and proofreading.
You can define different workflows in configuration. Workflows are permission-aware.
Each workflow consists of stages and transitions between them.
The following configuration defines a workflow where you can pass a draft
to proofreading, and then to final approval.
The workflow is defined in the
config/packages/ezplatform.yaml configuration file.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
Each stage in the workflow has an identifier and can be assigned a label and a color (lines 17-19).
Each transition also has an identifier.
It must state between which stages it transitions, or be marked as
of a different transition.
Transitions can also have labels, colors, and icons (lines 34-36).
If you don't define a custom color for a transition, a default setting
will be used (
You can require that a reviewer has to be selected when content is sent through a transition (lines 37-38). The user will then not have the option to send the Content item without selecting a reviewer:
If a User does not have the permissions to view or edit the Content item, you cannot select them as a reviewer.
You can view all configured workflows in the Admin Panel by selecting Workflow.
Publishing content with workflow¶
You can automatically publish a Content item once it goes through a specific transition.
To do so, configure the
publish action for the transition:
1 2 3 4 5 6 7 8 9 10 11
When an editor selects a reviewer in the Back Office, your configuration can send a notification to the reviewer:
1 2 3 4 5 6 7 8 9
The notification is displayed in the user menu:
You can limit access to workflows at stage and transition level.
workflow/change_stage Policy to grant a User permission to change
stages in a specific workflow.
This Policy can be limited with the Workflow Transition Limitation to only allow sending content in the allowed transition.
For example, using the example above, a
WorkflowTransitionLimitation set to
will allow the Technical team to send content to proofreading after they
are done with technical review.
You can also use the Workflow Stage Limitation
together with the
content/publish Policy to limit
the ability to edit content in specific stages.
For example, you can use it to only allow Technical team to edit content
Workflow makes use of the Symfony Workflow Component, but special Ibexa DXP treatment is covered in the Workflow service.
The service implements the following methods:
start- places a Content item in a workflow
apply- performs a transition
can- checks if a transition is possible
can are the same as in Symfony Workflow, but
the implementation in Workflow Service extends them, for example
by providing messages.
You can also use the following methods to read information about workflow from the database:
loadWorkflowMetadataForContent- reads all workflow information about a Content item (as
loadWorkflowMetadataOriginatedByUser- reads all workflow actions performed by the provided user (as
loadAllWorkflowMetadata- reads all workflow information from the system
\EzSystems\EzPlatformWorkflow\Value\WorkflowMetadata object contains all
information about a workflow, such as ID, name, transitions and current stage.
\EzSystems\EzPlatformWorkflow\Value\WorkflowMetadata::$workflow gives you direct
access to native Symfony Workflow object.