| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Overview
| Excerpt | ||
|---|---|---|
| ||
Define the milestones and key stages in your workflow |
States act like milestones in your workflow – key stages of your process where something has to happen.
States are always implemented with the
macro. There must be at least one state in every workflow.
State names are case sensitive. There are also a number of reserved characters that cannot be used in a workflow state name such as = # @ { | [.
Example
Let's assume we've got a really simple content production process where content is edited, then it goes through a review, and if the review is approved the content is published.
| Code Block | ||||
|---|---|---|---|---|
| ||||
{workflow:name=Three states}
{state:Editing}
{state}
{state:Review}
{state}
{state:Publish}
{state}
{workflow} |
Transitions
States can handle several common Transitions directly, namely:
submit– a direct transition to one stateupdated– an automatic transition which occurs when content is editedapprovedandrejected– transitions triggered by completion of Reviews
expired – expired– triggered when a state expires – see Expiry Dates
completed – completed– triggered when the last remaining task is completed – see Tasks
For approved, rejected and submit transitions Workflow Parameter can also be required to be entered.
See: Transitions
Reviews
You can add Reviews to states. When the workflow enters the state, the
workflow popup will display options for
Reviewers must decide whether to approve or reject the content, and once they are in agreement the state will transition to the approved or rejected state as applicable.
See: Reviews
Require parameter
A state can be configured to require the setting of one or more workflow parameter values. The value must be set before a transition into the state can occur. The workflow popup will display a warning for the transition in any state that has this state as a destination.
The Reviewed state in the markup below would require the setting of the value of the workflow parameter pagefield1 before a transition can occur into the Reviewed state.
| Code Block |
|---|
{workflowparamter:pagefield1|edit=true}
{workflowparameter}
{state:Draft|submit=Reviewed}
{state}
{state:Reviewed|requiredparams=pagefield1}
{state} |
In our example, the transition option is to a single state from the Draft state to the Reviewed state
the Submit
button displays a warning icon.
Choosing
the Submit
button opens a text box to enter the value of the required workflow parameter.
The required parameters for entering a state will only be prompted if a user is performing a workflow action such as approving/rejecting content or making state selection. If a state is transition is actioned by a trigger, like a page update, the required parameter check for the destination state will not be carried out.
| Info |
|---|
Once a parameter value has been set in a workflow it will not be prompted for again unless the saved value is removed. |
Required parameters can be added to a state using the state editor in workflow builder.
Workflow parameters added to the workflow will be available as options to the dropdown menu.
Tasks
Tasks can be created automatically when a workflow enters a state, and states can automatically transition when tasks are completed.
In the example, a task to Check links is created when entering the Review state, and when that task is completed a transition will occur to the Publish state.
| Code Block | ||||
|---|---|---|---|---|
| ||||
{workflow:name=Tasks}
{state:Editing}
{state}
{state:Review|completed=Publish}
{task:Check links}
{state}
{state:Publish}
{state}
{workflow} |
See: Tasks
Note that tasks cannot be created this way in the initial state (the Editing state in our example).
For the task to be created, the state must be transitioned to from another state; it must be entered. When a workflow is first applied to content, the initial state is not entered and thus any tasks it contains won't be created.
Publishing
States can be designated as a "final", Published state for the content.
When using this feature, called Same-space publishing, View-only users will only see the most recently published version of content.
See: Publishing
Expiry dates
States can be given expiry dates. There are many uses for this, but one of the most interesting is to trigger periodical reviews of published content:
It's a really simple way to ensure that documentation doesn't go stale.
See: Expiry Dates, State expiry date
Notifications
By default, page watchers will only be notified if a state expires.
Additional notifications can be added if desired – see Notifications.
Macros
| Filter by label (Content by label) | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Events
State transitions and expiry generate
events, for example
statechangedpagestatechangednewsstatechangedstateexpired
Events can be used in workflow triggers to set one or more actions.
App configuration
Setting | Where | Notes |
|---|---|---|
State's Task Behaviour | Should incomplete tasks be carried over to the next state during transitions? | |
State Expired Notification | Should page watchers receive a notification when a state expires? |
Examples
| Filter by label (Content by label) | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
See also
{state} macro