Any questions? Need any help?

Click the Support button in the bottom right corner.

Page tree
Skip to end of metadata
Go to start of metadata

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 variablePurposeCan be emptySupports custom stylingMinimum plugin version

Contains a single state, eg: READY FOR REVIEW or APPROVED

Users & GroupsContains a set of Confluence users and/or groups(tick)
TextContains text(tick)
NumberContains a number

Confluence Page IDContains the reference to a Confluence page(tick)

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:

Workflow tree

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 nodePurposeExamples
ConditionCan restrict access to the node's children, according to a given condition
  • If current user...
  • If variable...
Data manipulationCan manipulate variables
  • Set
  • Add
  • Subtract
User interactionCan interact with the current user
  • Show action
  • Show data
  • Ask for data
Confluence integration

Can interact with Confluence itself

  • On page updated
  • Sync to page labels
  • Set/clear page restrictions

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:

  • Some data widgets may only be shown to specific users
  • Some manipulation of variables may only be done under specific conditions
  • Some Confluence operations (eg: setting page restrictions) may only be done in specific workflow states

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 PROGRESSThe page is not ready for prime time yet.
READY FOR REVIEWThe page is ready for reviewers to read it.
REJECTEDThe page has been reviewed but rejected.
APPROVEDThe page has been reviewed and approved.
PUBLISHEDThe 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:

Workflow overview

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.

New variables

  • "allowedReviewers" is a variable of type "Users & Groups" that contains the list of users who are allowed to review a Confluence page.
  • "reviewedBy" is a variable of type "Users & Groups" that initially contains nothing.
  • "reviewNotes" is a variable of type "Text" that initially contains nothing.

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...

On this page:

Any questions? Need any help?
Click the Support button in the bottom right corner.

Try STRAD Workflows today...
Download it from the Atlassian Marketplace