In this guide, we’ll explore the power of workflows in Jira. We’ll cover Jira workflow best practices as well as some practical examples. We’ll also discuss exactly why you would want to create a new Jira workflow, customized to your team’s processes, and how you would go about doing so.
With Jira you can really make the system work to your needs, precisely suiting your team’s processes and requirements. You can make it yours. And the way to do that is by building these workflow schemes.
Note: Read more about Jira in the Intuitive Jira Guide.
So without further ado, let’s get into workflows for Jira.
What are Jira Workflows?
Workflows in Jira model your organizational processes and allow you to progress tasks in the system.
In an extremely basic workflow, that might mean:
- Creating an Issue, to reflect a new task. This will have a “To Do” status.
- Marking it as “in progress” once work is begun.
- Then, when the task is finished, you can mark it as being “Done”. And you’ve already gone from one end of the workflow to the other.
Jira has its own built-in workflows. These include:
- Task management: The simplest possible workflow, to get tasks done as soon as possible.
- Project management: A slightly more complex workflow, which includes an “In Progress” status to better mark work on the task.
- Process management: A workflow structure that comes with multiple statuses and resolutions reflecting the complexity of business and development processes.
All these workflows are now available in Jira Work Management as well. JWM is a new and improved Jira product for non-technical teams.
However, it might be a better choice to create your own custom Jira workflow.
Why Create a New Jira Workflow
Creating a new Jira workflow allows you to adapt the system to exactly how your team works.
While you might use Jira’s standard workflow to be able to simply move an Issue from “Open,” to “In Progress” to “Complete,” things are often more complicated in the real world.
For example, if work needs to be approved then you may need to add additional statuses to reflect “Awaiting Approval,” “Review In Progress” and “Review Complete”.
Another reason to customize workflows is the diversity of teams. All kinds of teams use Jira – from customer support to HR to developers. Separate teams might also naturally benefit from having their own work patterns and requirements built into Jira.
Just make sure not to overdo it when creating unique workflows, though, as this will limit interoperability as well as creating other issues – as explained in our blogpost on the worst (common) advice for Jira.
So, when considering customization, it’s important to think about precisely what you’re doing and why.
And clear communication is essential. If you can use existing elements and features provided by Jira with minimal hassle, then it is the simplest way to get ahead.
But if it means that the system simply doesn’t reflect the way that you work, then it might be essential to deploy customization. And you could see a big productivity boost as a result.
The role of Jira workflows for teams
Jira enables users to seamlessly log tasks and information.
There’s no need to drop a colleague an email to let them know that a task has become available for them. It’s all tracked and logged automatically through workflows.
This way you’ll be mapping how tasks are processed and dealt with while wiping out redundancy.
Of course, if you’re using Jira for other purposes, such as a CV database, then workflows might be even more useful. They allow you to move Issues around the system exactly as you need.
Benefits and drawbacks to changing workflows
Creating Jira workflows to match the way you work comes with the benefit of making Jira far more useful for you and your team.
This will allow you to ensure that everything is correctly logged on the system, hence offering new insights into exactly how your processes function.
The drawbacks however are:
- If you do want to deploy customization, then your admin will need to build and maintain the changes. That requires time and resources. Overdoing it is probably not a good idea.
- They’ll also have to ensure that the instance continues to function correctly (including with apps and other integrations). This can be quite challenging if you add too many customizations.
- A third drawback of over-customization is the communication disconnect between teams. If many teams start using different workflows and naming conventions, then it might become pretty confusing when these teams have to start collaborating or when members migrate to new teams.
The challenges of getting people to use Jira workflows in a structured manner
When it comes to workflows, one of the biggest challenges is ensuring that users work in a structured manner and make proper use of the system.
That might mean that once an individual starts working on an Issue, for example, then they need to mark it as being “In Progress”.
If they don’t make status changes as they go, then Jira won’t correctly indicate the team’s actual Issue flow. And there won’t be a record that the Jira user is working on the item at the time.
This then has a knock-on effect in the form of a partial record of the team’s activities. So Jira will be far less useful than it should be.
The solution is to ensure that everyone on the team makes a habit of updating issue statuses whenever required. This way workflows will be used as intended and the system will be up to date.
Of course, part of the effectiveness of these workflows is in ensuring that there is a clear and intuitive workflow in place that Jira users can understand.
Additionally, to ensure teams are progressing through the workflows in Jira correctly, it’s definitely a good idea to audit the process on a regular basis.
Note: You might also need to integrate multiple Jira workflows or map a Jira workflow to another platform like Azure DevOps or ServiceNow to align teams more efficiently without having them move from their familiar platform.
The Elements of Jira Workflows
There are four basic building blocks for a Jira workflow – statuses, transitions, assignees, and resolutions. That answers the question of who is doing what, where they’re doing it and what needs to happen next.
The workflow status
An Issue can only have one status at a time. It might be something like “In Progress” or “Complete”.
However, when looking at new statuses, it’s worth considering whether a status represents an activity or a stage.
For example, the status “Under Review” might represent a stage, which is actually composed of several different actions.
It may be tempting to split these actions out and make statuses out of them, too. But doing so will inevitably create a much more complex workflow, which is less transferable between teams and departments.
The Issue Assignee
This represents who the issue is assigned to and who is responsible for it. And it often changes between different statuses. When the task is complete the assignee name can be removed.
There are multiple approaches to assigning issues in Jira, which we discussed in our post Handing over issues to a new Jira assignee (the pitfalls and best practices)
The Transitions in a Workflow
A transition is a one-way or two-way connection that joins two statuses. Between the status “In Progress” and “Under Review” the transition might be “Submit for Review.”
There may be conditions for who can make a transition and when.
For example, only a project admin might be allowed to move an issue past the “Under Review” status.
Transitions can also be defined so as to notify specific parties when changes are made.
Ultimately, transitions lead towards a resolution.
Resolving an issue in a Jira workflow
The resolution is the final issue state – such as “Fixed,” “Complete” or “Won’t Fix.”
If you ever want to reopen closed items, you’ll need to ensure that you have already resolved them. If you don’t then the now-active issue will confusingly appear to be complete and its name will have a line through it.
How to Create a New Jira Workflow
When you create a project using a template a default workflow is already attached. Most of the projects in Jira Cloud have out-of-the-box Jira Simplified Workflows. These are sufficient if you want to track fewer issue statuses in only 1 project.
Jira also comes up with Advanced Workflows for tracking several issues under different projects.
To create a new Jira workflow you can either copy these default workflows or you can start from scratch.
A note of caution, the default workflows include various restrictions, such as not being able to edit resolved issues. That may mean that it’s actually easier to start with a clean slate.
To get down to work, you’ll need Jira Administrator permissions. From the menu, go to “Settings,” select “Issues,” then “Workflows” and then “Add Workflow” in the top right. You’re now ready to name your new workflow and to start mapping it out.
This workflow designer tool allows you to edit the layout of your workflow and the progress path of statuses and transitions.
There are various entities to consider when creating a Jira workflow. They include:
- Status – where the issue is (for example, “In Progress” or “Under Review”)
- Resolution – why the issue is no longer in flight (for example, because it’s completed)
- Conditions – control who can action a transition
- Validators – only allow transitions to occur when specific information is provided
- Post Functions – make additional changes to issues, alongside transitions (for example, removing a resolution when an issue is reopened)
- Triggers – automatically activating transitions when specific events take place. For example, moving an Issue from “In Progress” to “Under Review” when code is submitted for review
- Workflow properties – setting certain properties for transitions. For example, only displaying resolutions that are relevant to the specific issue type
- Workflow schemes – determining the associations between a workflow and issue type
Jira apps for Workflows
Jira add-ons can also assist in customizing workflows in order to get the precise effects that you want.
For example, you might want to prevent a Jira subtask from being reopened if the issue that it belongs to is resolved. or you might want to create an undo button so status changes can be reversed.
To achieve this, you could either build what you need yourself, or you could use an off-the-shelf app, such as JMWE or Jira Workflow Toolbox.
JSU Automation Suite for Jira Workflows
This powerful app can turbo-charge your processes by making it quick and easy to automate workflows, with no coding necessary. The suite enables you to automate repetitive tasks, connect different workflows, and link issues and transitions together. Further functionality allows you to update and clear issue fields and to set up follow-on transitions – meaning there’s a lot you can do with it.
JSU Automation Suite for Jira Workflows in the Atlassian Marketplace.
Jira Misc Workflow Extensions (JMWE)
This app allows you to easily configure workflows without the need to code. You have the option of additional automation of workflows with a simple scripting code. It also has event-based automation triggered by field/ issue changes. It also supports JQL-based scheduled actions.
Jira Misc Workflow Extensions (JMWE) in the Atlassian Marketplace.
Jira Workflow Toolbox
It allows you to extend workflows with powerful post functions and uses conditional logic support to meet advanced requirements and dependencies when creating, transitioning, and updating issues and fields.
It has an intuitively guided configuration with built-in examples, auto-complete, and in-app function reference in one place with the issue’s core data.
Jira Workflow Toolbox in the Atlassian Marketplace.
Jira Workflow Examples
The diagram above illustrates the different ways that workflows can function depending on what is needed.
That might mean simply moving a task from one state to another, or it might mean moving tasks between several individuals with multiple resolution states.
You can see iDalko’s support workflow below:
This Jira workflow allows for transitions in several directions. Which direction you go in depends on what is required.
The HR workflow below, meanwhile, sets extremely granular steps for onboarding a new employee:
In this case, the workflow has a number of statuses marking tasks leading up to a new hire’s arrival.
This is a workflow used for managing an opportunity backlog.
- New opportunities get raised and assigned to the project lead.
- The portfolio management team decides if this opportunity should be picked up (and refined) or rejected.
- Opportunities under review are detailed out, estimating the cost to develop and the value it brings.
- Optionally the opportunity can be documented on Confluence, allowing for free-form discussions and requirements gathering.
- Once all required details are collected, opportunities are progressed into the status “to be decided”.
- At this point, a formal decision can be taken to include the opportunity in a development plan. Of course, the opportunity might be costly to develop (and be rejected) or put “on hold” if the circumstances are not favorable to start its development.
- The “to be delivered” queue is used by R&D to select the opportunities that will be included in future releases.
- The ranking of the opportunities is therefore very important as R&D will focus on the top-ranked ones.
- R&D will translate the opportunities into epics/stories in the release projects.
- The status of the opportunity is progressed into ‘Under development’, and the opportunity is linked with the related epics and stories.
- Once the product is delivered (i.e. available for installation on customer premises), the opportunity is closed.
The image below illustrates the default Jira workflow. Which allows for transitions in multiple directions from all statuses.
This Jira workflow builds in a great deal of flexibility with how the issue can be moved forward.
Best Practices for Testing Workflows in Jira
Testing your new workflow is essential. And it comes in several distinct stages, starting with the planning phase.
Design phase of the new workflow
Before building the new workflow, you need to test all the different use cases that are imagined.
For example, how will urgent items move through the system? What information do you need? And how is this captured?
Asking questions and getting the detail now will save a great deal of time later.
Validation phase of the new workflow
This is a dry run of the live workflow implemented once it has been built.
To validate the work, you’ll need to gather representatives of the different stakeholders who will use the workflow (for example, from each department).
Unlike testing at the design phase, validation requires you to manually run through every step in the workflow.
It also requires you to run through all possible statuses and escalations. This way, you’ll ensure that they will function as intended.
You can collect and collate feedback as you go.
Of course, it’s far better to discover problems now rather than later. And playing games with the Jira workflow can be a fun way to see how it fits together.
At this stage, a lot of time will be saved by having a clear, easy-to-access set of video tutorials and workshop sessions to provide on-the-job training.
Before launch, documentations explaining the functionality and what is intended could be a second-best option.
Production phase of the new workflow
Launch day has come and gone and your new workflow is now live on the system.
Is the job finished? Not quite.
What you’ll still have to do is:
– Define and track process deviations: If users aren’t following Jira workflows as intended, you need to identify the fact and find out why. How you go about this will depend on the environment and precisely what users are doing. For example, if developers are deploying code changes without updating issues, it indicates there may be a process deviation taking place.
– Review: Once you’ve discovered any issues, you’ll want to find out exactly why the disconnect is occurring. Is the Jira user unaware of the correct process or is the workflow unclear?
Note: Changing workflows for large numbers of people may require a lot of training, but it’s worth making sure you reach everyone.
This may mean:
- Passing information from team leads down to their teams,
- Holding inter-department/ inter-team meetings,
- Creating blog items,
- Or managing a company Wiki detailing your Jira workflow functionality.
– Discuss the impact: Workflow changes are likely to be a big deal for the organization. It can hence be useful to connect with team leaders to review changes. This can be done quarterly or bi-annually. You’ll have to ensure that new workflows function correctly, and are being used. And you’ll have to discuss further changes. Admins may also allow teams to experiment with workflows to determine precisely what is needed.
Common Mistakes to Avoid when Creating Workflows in Jira
Jira workflow customization is a complex process. This means it’s easy to make mistakes.
So here are a few things to keep in mind while still at the planning stages.
This is the kind of structure that you want to avoid – where there is far more detail than is needed for an effective workflow.
Creating new Jira issue statuses by duplicating existing workflow
Frequently creating issue statuses from existing workflows can be tempting. But it must be avoided.
Workflows at their best must reflect to become a “standard” so they can be reused and be as simple and effective as possible. So it’s always better to start from scratch.
Also, if you let project admins extensively customize on their own without coordination, then you may find that different teams will start moving in different directions.
Customizing your Jira workflows too far
As you customize your Jira workflows, they’ll evolve and become increasingly different.
If that continues, then they’ll eventually become different species and they won’t be able to interbreed…
So you won’t be able to move projects or issues between teams or instances which can become a big problem.
The solution to this is to ensure that customization is consistent across the organization, or at least within each department, thereby minimizing compatibility issues.
To make sure that everyone stays on the same page, it’s wise to limit admin access. And it’s also a good idea to ensure that customization is approved and managed with the big picture in mind.
Customizing workflows in Jira without involving the stakeholders
Perhaps the most annoying discovery that an admin can make is to find that new workflow statuses aren’t actually used.
To make sure you don’t set out on unnecessary work, spend time talking to users and stakeholders. Then map out workflows.
Doing so will ensure that the users’ requirements are understood and reflected in the specification of the workflow and the processes described in it are actually needed. As the saying goes, less haste, more speed.
In this guide, we have covered:
- What workflows are – a system for progressing tasks in Jira
- Why you would want to create a custom workflow – to better match your business processes
- The various elements of workflows – statuses, assignees, transitions, and resolutions
- How to test your workflow – from design to validation to deployment
- A few examples of Jira workflows
- And common mistakes people make when creating workflows, including the issues of creating duplicate statuses, customizing too far, and creating new workflows that aren’t required
Having read this guide, you should have a clear idea of the pros and cons of creating custom Jira workflows and of exactly what a new Jira workflow can do for you.
Jira is an immensely powerful platform and with a little work and planning, you can ensure that it’s set up to be exactly right for you. As a result, you’ll be able to unlock a huge boost in productivity.