Jira Cloud Workflows Customization

Get ready to explore the most important aspect of Jira issues – Workflow Customization & Management. Here is a complete guide on Jira Cloud Workflow customization with pictorial representations:

This tutorial plays a key role in the Jira Cloud Administration Series. As every Jira project contains issues that users work on, it contains transitions through different stages. This is called a workflow, which we will see more about it in this article.

Normally, users work on issues that contain workflow and it consists of status and transitions that each issue will go through. As an example, here we will look at how to create a workflow and assign it only to the Story issue.

Jira Cloud Workflows Customization: Detailed Guide

Create a New Workflow

To create a workflow, go to Settings -> Issues -> Workflows

Click on Add Workflow -> Create new

Provide a name and click on Add.

Click on Add status. If the status exists, use them else it will ask to create a new status. Add transitions as well.

Add a new status called Cancelled and a transition from In Progress to Cancelled.

To apply this workflow to the Story issue type, go to Project settings -> Workflows.

Select Add Workflow -> Add Existing.

Select the workflow just created.

Click Next.

Select the Story issue and click on Finish

Click on Publish.

Click on Associate to ensure compatibility of existing issues with the new workflow.

Final view.

New and any existing Story issues will use this workflow.

As a Jira Administrator in the workflow transition, we can add the below aspects:

• Conditions
• Validator
• Trigger
• Post function
• Properties

In the next section, we will look at some examples of this.

Suggested Read =>> JIRA Administration and User Management Tutorial

Workflow Example 1: Close Parent Issue Only if Sub-tasks are Closed

A Condition in Jira workflow controls whether or not a user can execute a transition.

So, let’s add a condition for the Done transition in the Story workflow. Click on the Done transition and select Conditions.

Click on Add condition.

Select the Sub-task Blocking Condition radio button. Click on Add.

Select the sub-task status of Done to allow for parent issues to transition.

Recommended Reading =>> Most Frequently Asked JIRA Interview Questions and Answers

Click on Add once selected.

Click on the Publish Draft.

To test the condition in the example below, you can see that the Story issue cannot transition to Done status unless the Sub-task is in the Done state.

Once the sub-task status is in Done state, then the Story can be transitioned to Done status.

Workflow Example 2: Users in Groups Can Perform Certain Transitions

We will add a Jira workflow condition to ensure that only users in groups can perform certain transitions.

Open the workflow, select the transition for the Done status and add a condition.

Select the User in group option and click on Add.

Select the group and click on Add.

Publish Draft

As any other user other than the one in the group, the DONE option will not be seen.

Workflow Example 3: Make a Custom Field Mandatory During the Transition

A Jira validator checks that any input made during the transition is valid.

This example will focus on the transition to the Cancelled status. When the user transitions to the Cancelled status, the field ‘Cancel Reason’ should pop up.

Open the workflow and click on the transition to the Cancelled status. Click on Validators.

Click on Add validator.

Select the field that requires a validator and click on Add.

Select the fields to be made mandatory during the transition. Click on Add.

Publish Draft

Test the validator. Change the status to Cancelled and you will see a failed message below mentioning that the Cancel Reason filed value is a must.

Workflow Example 4: Display a Screen During the Transition

During a transition, the need is to pop up a screen during the transition. We will see during the transition to Cancelled status, a screen should come up for users to enter a reason for Cancel.

Go to Settings -> Screens and add a screen.

Click Add and update the screen with only one field.

Open the workflow and double-click on the transition for the Cancelled status.

Select the screen just created.

Click on Save.

Publish the Draft and test the scenario.

Click on the transition to Cancelled status.

The Cancel screen comes up.

Also Read => Overview of Jira Download, Installation and Setup

Workflow Example 5: Update the Assignee Field on the Transition to Done

Post Function helps to perform additional processing. In this example, we will add a Post Function to automatically update the Assignee field on the transition to Done status.

Click on the transition to Done and select Post Functions.

Click on Add Post Function.

Select the radio button Update Issue Field and click on Add.

Select the value and click on Add.

Move the step to the last.

Publish the Draft and test the post function. In the below bug issue, the Assignee is Unassigned.

Transition the bug to Done status.

The Assignee field is populated.

Recommended Reading => Guide to Creating Jira Dashboard Quickly

Workflow Example 6: Workflow Transition and Status Properties

Jira workflow properties help to add restrictions to status and transitions using key-value pairs. We will look at an example for both.

The workflow properties for transition can be found @ Workflow properties | Administering Jira applications Data Center and Server 8.22 | Atlassian Documentation and for status @ Use workflow properties | Atlassian Support

Scenario #1: Open an issue in the old view. Click on 3 DOTS and select See the old view

If you look at the Status sequence, the Done status is first, and Cancelled is second.

If we need to reverse the same, then open the workflow and open the properties for both Cancelled and Done transitions in different tabs.

Enter the property as shown below and add a value such as 10 for Cancelled transition.

Click on Add.

Similarly, for the Done transition, add the same property and value of 20. The value is high since the sequence has to be reversed.

Publish the Draft workflow and look at the old view.

Scenario #2: Once the issue is transitioned to Done status, then the issue should not be editable.

Open the workflow and select the properties for the Done status.

Enter the below property key and value of false. Click on Add.

Publish the draft.

Transition an issue to Done status

You will not see any Edit button in the old view or be able to edit in the new view.

Scenario #3: Only a specific user can edit the issue once the status is Done.

Open the workflow and click on the properties of the Done status

Click on Add.

Publish Draft.

Scenario #4: Disable adding attachments

Let’s add the property to disable adding attachments to all statuses other than In Progress status.

Click Add.

For the Story in the In Progress status, the attachment is enabled.

In the Done status, the attach option is not seen.

Add this property to all statuses on Story, where work logs normally should not be added. If you want to additionally disable deleting only own or all attachments, use one of the following properties.

Scenario #5: Disable adding comments

Scenario #6: Property to restrict editing permissions to only selected roles or groups

Make issues editable to a specific group in Done status only.

Here, the property value 10002 is the role ID of the Administrator role and can be found out from the URL when you click on Edit for that role.

The role ID in the URL is at the end, which is 10002

https://vniranjandemo.atlassian.net/secure/project/EditProjectRole!default.jspa?id=10002

Publish the Draft after adding the properties to test the scenario.

Scenario #7: Property to restrict editing permissions to only Administrators and Developer roles in Done status.

In this example, we need to add a property to restrict editing permissions to only Administrators and Developer roles in Done status.

Scenario 8: Restrict the Edit permission to a specific user group in the Done status only

In this example, restrict the edit to specific user group in the Done status.

Property key: jira.permission.edit.group

Property value: jira-administrators

Groups can be found from Directory which is part of User Management. Only Site admins or Org owners have access to the same.

Scenario #9: Restrict edit permission to only Developer role for all Sub-tasks

Scenario #10: Restrict adding comments to a specific role in Done status

In this example, we need to restrict adding comments to a specific role (Administrators) in the Done status only.

Scenario #10: Restrict adding comments to a specific group in Done status

In this example, we need to restrict adding comments to a specific group (Administrators) in the Done status only.

Property key: jira.permission.comment.group

Property value: jira-administrators

Groups can be found from Directory, which is part of User Management. Only Site admins or Org owners have access to the same.

Publish Draft after adding the properties to test the scenario.

Scenario #11: Restrict changes to Assignee field

In this example, when a task is In Progress status no one can change the Assignee.

Scenario #12: Restrict changes to Assignee field only to a specific role

In this example, when the task is In Progress status, only the Administrator role can change the Assignee.

Also Read => Overview of Jira Download, Installation and Setup

Conclusion

In this part of the series, we look at the most important aspect of Jira issues, which are workflows and its customization in various scenarios.

In the next part, we will look at more automation to avoid most of the manual activities, which will help every developer be more productive and also integrate with GitHub and Confluence Cloud.

PREV Tutorial | NEXT Tutorial