Any questions? Need any help?
Click the Support button in the bottom right corner.
- This line was added.
- This line was removed.
- Formatting was changed.
If you prefer, you can just read the basics and then see the A real-life workflow example, or if you feel confident enough, try one of the workflow examples that ship with STRAD Workflows. By looking at the examples, you will see that the answer to a problem is often surprisingly simple.
In STRAD Workflows, you can create and edit workflows by using the workflow editor. At present, you need to be a Confluence administrator in order to edit workflows.
Under the crux, a workflow consists of two things:
- A list of variables that defines the state of the workflow
- A workflow tree that defines the behavior of the workflow
Once you define a workflow, you can then bind it to the Confluence pages (or blog posts) you want the workflow to act on.
Variables are at the core of workflows. Each variable contains a value. There are several types of variables, each of which fits a particular purpose.
|Type of variable||Purpose||Can be empty||Supports custom styling||Minimum plugin version|
Contains a single state, eg:
|Users & Groups||Contains a set of Confluence users and/or groups||-|
|Number||Contains a number||-|
|Confluence Page ID||Contains the reference to a Confluence page||1.4.2|
When a workflow is bound to a page (or to a blog post), an instance of that workflow is created. All variables defined in the workflow are put inside the instance, with their defined initial values.
In other words: if a workflow is bound to several pages, each page (or blog post) will have its own copy of that workflow.
The "Enumeration" variable type supports custom styling for its values, as illustrated below:
The workflow tree defines what the workflow engine must do, and under which conditions. It consists of any number of nodes. Whenever needed, the workflow engine will evaluate the whole tree and execute the appropriate nodes.
Keep in mind that it is a tree, therefore a node can have children, and each of these children can have its own children, and so on.
There are several types of nodes:
|Type of node||Purpose||Examples|
|Condition||Can restrict access to the node's children, according to a given condition|
|Data manipulation||Can manipulate variables|
|User interaction||Can interact with the current user|
Can interact with Confluence itself
For a comprehensive list of all workflow node types, see: List of workflow node types
Condition nodes can be used anywhere in the workflow tree, and they can be nested. For example:
Editing the workflow tree
Here are the most common actions for editing a workflow tree:
- create a node by clicking the "New node" button, or by dragging it into the free
- move a node by clicking on it, and then dragging it to a different location within the tree
- duplicate a node by clicking on the "Copy node" button
- delete a node by clicking on the "Delete node" button
- edit a node by clicking on it, then changing its properties in the "Node properties" area
How to design a workflow
Page approval example
Let's assume that we want a Confluence page to go through several steps before it can be published.
For this purpose, let's define a variable named "state", as an Enumeration whose values correspond to the state the page is in:
|WORK IN PROGRESS||The page is not ready for prime time yet.|
|READY FOR REVIEW||The page is ready for reviewers to read it.|
|REJECTED||The page has been reviewed but rejected.|
|APPROVED||The page has been reviewed and approved.|
|PUBLISHED||The approved page has been published by its author.|
When creating the "state" variable, we give it an initial value of "WORK IN PROGRESS". As a result, this workflow will automatically begin as "WORK IN PROGRESS".
Once we've created the variable, we can define the workflow tree as follows:
The first line tells the workflow engine to display the value of "state" to every user that visits the page.
The following lines are conditions on the value of "state". Each condition restricts access to its children, so that the children are evaluated if (and only if) the condition is fulfilled. In the screenshot above, the children are collapsed.
Now, let's expand some children of the "WORK IN PROGRESS" condition, in order to see more:
Workflow with expanded "WORK IN PROGRESS" node
Here we go:
- When the state is "WORK IN PROGRESS", the workflow engine sets restrictions on the page, so that no one (except for the page author) can view the page.
- If the current user (the user who is viewing the page) is the page author, he/she will see an action button labeled "Submit for review". If he/she clicks the button, the workflow engine will advance the state to "READY FOR REVIEW".
Now let's look at the next state: "READY FOR REVIEW".
Workflow with expanded "READY FOR REVIEW" node
In this state, the page restrictions are relaxed so that reviewers can also view the page.
Then we see that the page author will see an action named "Revert to draft". We haven't expanded that node in the screenshot.
If the current user is found in "allowedReviewers", he/she will see an action named "Approve". This action is not just a button: it has dependencies. In this particular case, the user can enter some review notes before clicking the "Approve" button.
When the "Approve" button is clicked:
- The review notes are stored into the "reviewNotes" variable
- The "state" variable is set to "APPROVED"
- The "reviewedBy" variable is set to the current user
The "Reject" action is similar to the "Approve" action, so we haven't expanded it.
The page has been approved by the reviewer, therefore we advance to the next state.
And so on...
Next section: Binding and connecting your workflows
On this page: