Overview

5 recipes to make your work flow in JIRA

No Comments

Atlassian JIRA is a great tool to build workflows for every kind of use case whether in Software Development, IT or for business processes like onboarding, travel approvals, marketing or the like.

As an Atlassian Solution Partner we implement sophisticated custom workflows for our clients. In one of our larger projects we developed a solution to handle offers and orders between two companies. Other client projects involved the use of JIRA Service Desk to streamline collaboration between support and software teams. 

In this blog post we are going to quickly review the basic workflow building blocks for custom workflows in JIRA and deep dive into 5 recipes to show possibilities and use cases for advanced workflows in JIRA:

  1. Dual control principle for approvals
  2. Seamless collaboration between support and development teams
  3. Collect results from sub-tasks in the parent issue
  4. Close sub-tasks when an issue is cancelled
  5. Allow everybody to delete issues

Out of the box JIRA has just a few basic workflow functions, most of the advanced functions come from add-ons. Therefore the following recipes are also a showcase for our home-grown add-on “Workflow Essentials for JIRA” but it is also possible to achieve the same functionality with other add-ons, scripts or even your self-made JIRA add-on.

Lets start with the basics.

A basic JIRA workflow

A good introduction to building custom workflows can also be found in the article “How do I build the workflow I want?” in the Atlassian documentation.

Every JIRA workflow consists of the following 2 basic elements:

  • Statuses: they represent where the issue is in the workflow. For example “open”, “in progress” or “done”.
  • Transitions between statuses: these are connections between statuses. For example “start progress”, a connection from status “open” to “in progress”. Transitions can have an optional transition screen that shows up when the user executes the transition.
Simple JIRA workflow

A simple workflow in JIRA with 3 status.

 

A workflow transition can use several workflow functions. Workflow functions can be of the following type:

  • Conditions: These functions control whether a transition is available, meaning whether the button shows or not. For example the “start progress” transition uses a condition to make the button only visible for users in the role “Developers”
  • Validators: These functions are similar to conditions but can provide feedback to the user instead of simply hiding the transition button. For example the “start progress” condition could require a field value and would show an error message to the user if the field is empty.
  • Post functions: With these functions you can automate tasks during or at the end of the transition. For example a system post function can re-index an issue or you could use a post function to copy a value from the parent issue to the sub task issue.

Additionally you can define workflow properties, e.g. to make an issue not editable by a certain group in a specific workflow status or to customize the transition button name and appearance order. See here for details.

JIRA build-in examples:Add-on examples:
Conditions

  • Only reporter condition
  • Only assignee condition

Validators

  • Permission Validator

Post functions

  • Assign to current user
  • Set or clear resolution
 

 

 

Now that we have reviewed some of the basics to create custom workflows in JIRA, let’s have a look at 5 use cases. All these recipes apply to JIRA Server only. The JIRA cloud version has limited functionality for add-ons in the workflow space, for example it is not possible by the time of writing to create additional validators.

#1 Dual control principle for approvals

The requirement in this recipe is that two individual users must approve an issue before it can proceed further.

An approval workflow with two approval levels

Ingredients:

Directions:

  • Create the basic workflow as shown in the picture.
  • On the transition “Approve(1)”, add the post function “Update/Set custom field value” to set the field “Approver 1” to the current user.
  • On the transition “Approve(2)”, place the validator “User (not) in custom field” and configure it to verify that the current user is not in the custom field “Approver 1”. This way you ensure that two different users must approve the issue.
  • And voilà, basic four-eyes approval set up.
  • In addition I recommend you create another custom field and also store “Approver 2” so you can show immediately the approvers for each issue. Furthermore, when the issue is re-opened, clear the values in the fields.

#2 Seamless collaboration between support and development teams

The goal of this recipe is that your support team can request a bugfix from a dev team on-click and get notified when the bug is closed. It’s an automated alternative to create JIRA issues manually with the “create linked issue” dialog.

Workflow that allows to create bug tickets automatically on transition

Ingredients:

Directions:

  • Create the basic workflow as shown in the picture.
  • On the transition “Needs Bugfix”, place the “create and link issues post function” and configure it in such a way that it creates a bug ticket in the appropriate development project.
  • On the “done” transition place the validator “linked issue status” and verify that the linked bug ticket(s) are closed before allowing the support ticket to transition to “done”.
  • If you use JIRA Service Desk for your support team, use an automation rule to transition the support ticket back in progress when all linked bugs are closed.
  • And voilà, the support person gets notified when the bug is solved.
  • Alternatively, if you don’t use JIRA Service Desk, you could use the “transition linked issue” post function in order to transition the issue back in progress.

#3 Collect results from sub-tasks in the parent issue

Sometimes you wanna split up work for a task into different independent sub-tasks to be done by specialized roles in your company. For example when you onboard new employees, one sub-task might require a new phone number/contract and an active directory account for the user. The results, the new phone number and the active directory user account could be collected in the parent issue. If necessary, all issues could have different access rights.

Ingredients:

Directions:

  • Create 2 sub-task types 1) “User Account”, 2) “Phone Contract” and associate the custom fields to the corresponding type.
  • Create a simple workflow with “Open” -> “Close” and associate it with both sub-task types.
  • When a sub-task is closed the value “LDAP Account” or “Phone Number” should be copied to the parent.
  • Use the post function “copy from sub-task to parent” to copy the fields “LDAP Account” and “Phone Number” to the parent issue. That function will cover both sub-tasks and copy the fields from the individual sub-task’s when a value is provided.
  • And voilà, that’s basically it.
  • Additionally you could use the same workflow for the main task, because the post function will not fail when there is no parent issue and will simply be skipped. 

#4 Close sub-tasks when an issue is cancelled

When an issue is cancelled / aborted, then often a manual process needs to take place to close any related sub-tasks. Or even worse the sub-tasks stay in progress and lead to inconsistent data in your JIRA. This recipe is for auto-cancelling all sub-tasks when the parent issue is cancelled.

Ingredients:

Directions:

  • Use any workflow you want for this use case with a final status “closed”.
  • Add a global transition “cancel” to status “closed”.
  • Place the “transition linked issue” post function on the transition “close” and configure it in such a way that it will execute “cancel” for any “jira_subtask_related (outward)” issues.
  • Use the “update issue field” function to set the issue’s resolution to “cancelled”.
  • And voilà, all sub-tasks will be closed with the correct resolution when you cancel the parent issue.
  • Tip: Use the Quick Subtasks for JIRA Add-On to create multiple sub-tasks at once or even automatically on transitions

#5 Allow everybody to delete issues

While some JIRA admins might just have thrown their hands up in horror, when allowing everybody to delete issues, you can rest assured: this recipe will use a special global transition “delete” instead of JIRA’s delete function and thus provide some sort of admin trash. At the same time your users can get rid of issues they don’t want in their view anymore. (Thanks to Manuel Moya for this recipe!)

Workflow with a global “delete” transition

Ingredients:

Directions

  • Create the basic workflow as shown in the picture.
  • Create a global transition “delete” and place the “set security level” post function on it.
  • Set the security level to “deleted issue”. Choose to skip any permissions in order to make sure the security level will be set regardless if the user has the permission to do that.
  • And voilà, when the user executes the transition, the issue will be removed. The administrators will still be able to restore them and eventually schedule a task to periodically remove them from the system.

Summary

We have seen the basic building blocks of JIRA workflows and how workflow functions such as “update/set custom field”, “transition linked issues” or “validate user in custom field” can help you to implement advanced workflows quickly. 

Thank you for reading, I hope you got some new ideas and inspiration. Feel free to comment below and share your custom workflow ideas with us.

Comment

Your email address will not be published. Required fields are marked *