Multiple workflows can be very useful in case you have concurrent processes.
For example, an object may be published, but require translation.
You can track the review state in the main workflow and the translation state in another.
If you index the state variable for the second workflow in the catalog
(the state variable is always available on the indexable object wrapper
you only need to add an index with the appropriate name to
you can search for all objects pending translation, for example using a Collection.
Workflows are mapped to types via the
There is a default workflow, indicated by the string
Some types have no workflow, which means that they hold no state information and typically inherit permissions from their parent.
It is also possible for types to have multiple workflows. You can list multiple workflows by separating their names by commas.
This is called a workflow chain.
In Plone, the workflow chain of an object is looked up by multi-adapting the object and the workflow to the
The adapter factory should return a tuple of string workflow names (
IWorkflowChain is a specialisation of
IReadSequence, i.e. a tuple).
The default looks at the mappings in the
but it is possible to override the mapping, e.g. by using a custom adapter registered for some marker interface,
which in turn could be provided by a type-specific behavior.
Multiple workflows applied in a single chain co-exist in time.
Typically, you need each workflow in the chain to have a different state variable name.
portal_workflow API (in particular,
doActionFor(), which is used to change the state of an object) also assumes the transition ids are unique.
If you have two workflows in the chain and both currently have a
submit action available,
only the first workflow will be transitioned if you do
Plone will show all available transitions from all workflows in the current object’s chain in the
so you do not need to create any custom UI for this.
Plone always assumes the state variable is called
review_state (which is also the variable indexed in
Therefore, the state of a secondary workflow won’t show up unless you build some custom UI (User Interface).
In terms of security, remember that the role-to-permission (and group-to-local-role) mappings are event-driven and are set after each transition.
If you have two concurrent workflows that manage the same permissions, the settings from the last transition invoked will apply.
If they manage different permissions (or there is a partial overlap) then only the permissions managed by the most-recently-invoked workflow will change, leaving the settings for other permissions untouched.