Oh workflow, oh workflow, wherefore art thou workflow? This is probably the least understood part of JIRA. For example, here are just a few of the questions I get nearly weekly here:
No, Seriously…I get asked thse alot….
|What is a workflow?|
Why do I need it?
What can it do for me?
What can’t it do?
|Which one do I pick?|
What are my options?
Why can’t this be easy?
Needless to say, there needs to be some clarification on this subject matter – hence why it the first blog post I’m writing is about this.
What is a workflow
The workflow – to put it simply is the steps, or statuses that an issue travels through. You can often see them displayed as such below.
These two are examples of a Simple and Complex workflows, respectively. We’ll go into detail about what makes each what it is in a moment. In this representation, each status is represented by a candy bar – with the issue’s current status being filled in. The circle in each is meant to signify the issue creation, and the arrows represent transitions between issues. Please note that the first transition – from the circle to the destination, happens automatically when we are creating an issue.
You can also note that each status has a color. These are standard in JIRA – and we have no ability to change them. Blue is meant to signify a start or backlog status, Yellow meant to signify an “In Progress” state, and Green meant to signify the end or termination state.
As shown above, there are two basic parts fo the workflow: Status and Transition. Statuses are the boring part – they are what they are. It’s meant to signify what “state” the issue is in. For complex workflows, I like to make the status show what it’s waiting on, hence why they tend to be something like “Pending X” or “Waiting on X”. The transition is where the action is, however. During transitions, you can have it automate certain actions – like reassigning the issue or updating fields. We’ll go into further detail about this in another section.
Simple vs Complex
As stated, workflows can be classified into two general categories: Simple and complex.
A simple workflow is just that. It only has three to four generic statuses, and each can be transitioned to from any other status (Marked with the “All” transitions above). The purpose of these is to support teams who do a variety of tasks throughout the day. The thought is your team will define the steps to completion using sub-tasking, and each sub-task will travel through these generic steps. This also allows you to show parallel work – something a complex workflows cannot do. In general, this is my advice for most teams.
A complex workflow is in many ways the opposite. It has single status-to-status transitions, and more nuanced statuses. This is great for highly regulated tasks, such as the requisition flow shown above.
In general, I advise the use of simplified workflows when possible. They are much more adaptable should you decide to change how your team works. With a complex workflow – any such changes will require you to work with a JIRA Admin to change the workflow appropriately. However, for workflows that need tight controls, a complex workflow may be required.
Conditions, validators, and post functions
The Transition is said to be where the action happens within the workflow. That is because there are three parts to the transition – the Conditions, the Validators, and post functions. There is also the ability to display a screen to gather information relevant to the given transition.
Conditions tell the system when and to whom to display the transition button to. If you cannot see the transition button, it is likely because some condition isn’t satisfied. While a useful guardrail to prevent people from transitioning an issue who aren’t supposed to – it’s often confusing because you don’t get an error text – you just don’t have a button.
A Validator is similar to a condition in that it evaluate whether a transition can occur, but it happens during the transition. It is useful to make sure people have filled out information appropriately – and is often paired with a pop-up screen (but doesn’t have to be). Validators are often more useful as they do return error messages – making them ideal to make sure fields are filled out correctly.
The Post Functions run after the Transition occurs, and allows you to change fields within the function. This is often how “Automatic Reassignments” are done within JIRA – by attaching the appropriate post function to the correct transition. It should be noted that certain post functions have to occur for JIRA to work properly – and therefore a JIRA Admin is required if you want to make any changes to post functions.
Within every transition – there is a order that the operations occur:
Order of Operations
|1) Conditions evaluated to see if user can use/see transition|
2) Transition button is pressed
3) Screen is popped up (if set to)
4) Validators are checked
5) Issue is transitioned
6) Post functions are run
Now – the biggest request I get is to have JIRA make decisions in the workflow based of the issue of fields. This is technically possible using conditions – it is not advised. The reason why is this will lead to what’s called a “Spaghetti Workflow”, which is often confusing for end users, causes admin headaches when changes need to be made, and a in general leads to a lack of adoption.
Termination – Resolution vs Status
If there is one thing I consider a cardinal sin within JIRA, it’s this:
This is an issue I see a lot, where teams will want to have multiple termination states to describe how it was closed. This is not how JIRA is meant to be used. The idea is to assign a resolution describing how it was closed, and have a single termination state to show that it is closed. JIRA, in fact, will not consider an issue closed until it has a resolution. So when you are coming up with a workflow – please keep this in mind.