Next-gen workflow transition rules inspiration

[#1]

It’s easy for common actions to seep into the day and take up more time than expected. Enter workflow rules, a handy process that helps take your workflow from manual to automated, from clunky to streamlined.

In this series, we'll spotlight one rule every week for 5 weeks. We want to share with you how you can setup each rule, and more importantly we want you to hear or to learn how you use this rule (or could use this rule) to improve your workflow.

Please note more advanced rules can be created using https://www.atlassian.com/software/jira/features/automation which we will not cover here

The quickest way to access the rules is through the Manage Workflow option in the meatball on your Board.

On the workflow editor, you can statuses and transitions to your workflow - and in particular you can also add workflow transition rules.

Please note that currently all issue types follow the same workflow, and the ability to have unique workflows for each issue type will be available soon.

To add a workflow transition rule:

1. From your board, select More (···) > Manage workflow.

2. Select a transition, represented by a lozenge that connects statuses in the workflow editor.

3. The transition settings will pop from the rightside of the screen. Select Add rule (+).

Assign an issue to someone

The Assign an issue to someone rule allows you to update an issue’s assignee as it is being moved between two statuses.

There are 4 main options to select from in the Assign to field…

• Assign to the current user

• Assign to the issue’s reporter

• Assign to a specific user

• Clear the Assignee field

Here are some examples of how these selections can be used.

Assign to the current user

It’s Monday morning, the coffee’s hot and the team are starting to tackle their sprint. Eoin picks up his first issue on the board - which is a bug raised by Jen. Eoin moves the bug from To Do to In Progress. Without needing to open the issue view, the bug is automatically assigned to Eoin which means he’s already off getting s**t done.

Assign to the issue’s reporter

Once Eoin has fixed the bug and it's ready for Jen to review, he moves it from In Progress to In Review. Again without needing to open the issue view, the bug is automatically assigned to Jen as she was the person that reported the bug. Eoin is already checking what the next piece of work to pick up is.

Assign to a specific user

Jen has reviewed Eoins impeccable work and she is happy with the fix. She moves the bug from In Review to Done, and the bug is automatically assigned to Harry who is the dedicated release manager. Harry bundles work together to be deployed to production in the next release.

Clear the Assignee field

Eoin is temporarily pulled into another project and needs to drop the work he has in progress. He adds some comments to the task that he was working on and moves it back from In Progress to To Do. The assignee field is automatically cleared from the task, so that is very clear that no one is currently working on it.

How do you use this rule? Or what ideas do you have for how this rule could be used? 🙂

Update an issue field

The Update an issue field rule allows you to automatically change the value of an issue field after moving the issue using a particular transition or on initial create.

You must select the field that would like to have updated, and there are two types of change possible…

• Set a value

• Clear a value

I’ll go into more detail about how setting a value works for each fields type…

Default fields provided by Jira	Fields created by you
Description	Paragraph (text)
Story point estimate	Number
Start date * only the date of when the transition or initial create occurs can be used	Date * only the date of when the transition or initial create occurs can be used
Priority	Short text
Labels (one or many Labels can be set)	Timestamp (date/time) * the timestamp of when the transition or initial create occurs
	Dropdown (one dropdown item can be set)
	Checkbox (one or many checkbox items can be set)
	People (one or many people can be set)
	Labels (one or many labels can be set)

Please note we are currently working on enabling separate workflows for each issue type in your project, but until then the Update an issue field rule can only be used on fields that appear on all of the issue types in your project.

Here are some examples of how these selections can be used.

Set a Start date

It’s Monday morning, the coffee’s hot and the team are starting to tackle their sprint. Eoin picks up his first story on the board and moves it from To Do to In Progress. Without needing to open the issue view, the Start date for the story is automatically set to the current date.

Set a label on a piece of work

Eoin is part of the A-Team and they have a couple of projects in progress. They create a Jira project for every project they are running, and set their team name in the Label field for every piece of in progress and complete piece of work. This allows for a filter to be created across a number of projects and a number of teams, to give visibility on all work being undertaken across the organisation - labelled by team.

When Eoin moves the task from To Do to In Progress, a label “A-Team” is added to the story.

Clear a field

Eoin is temporarily pulled into another project and needs to drop the work he has in progress. He had added a Blitz Date to the story to help the team know when to expect to perform a blitz on the changes. He adds some comments to the story and moves it back from In Progress to To Do. The Blitz Date field is automatically cleared from the story, so that is very clear that there is no longer a planned date for a blitz.

Restrict who can move an issue

The Restrict who can move an issue rule allows you to control who can progress work through the workflow.

There are 4 main options to select from…

• Only allow the issue assignee to move issues using this transition

• Only allow the issue reporter to move issues using this transition

• Only allow a specific person to move issues using this transition

• Only allow people in specific roles to move issues using this transition

Here are some examples of how these selections can be used.

Only allow the issue assignee to move issues using this transition

It’s Monday morning, the coffee’s hot and the team are starting to tackle their sprint. Eoin has been assigned a bug and he gets started without delay. He soon diagnoses the problem, implements a fix, and when ready for some validation - only he can move the bug from In Progress to In Review.

Only allow the issue reporter to move issues using this transition

As part of sprint planning the team identifies that a bug reported by Jen could not be reproduced. The team leaves a comment and asks Jen to decide on next steps. Jen realises she had made a mistake in reporting the bug, and because she is the reporter only she can move the bug from To Do to Cancelled.

Only allow a specific person to move issues using this transition

All completed work has been gathered together ready for deployment to production. The team has an additional done status in their workflow to capture this step in the workflow. Harry is the dedicated release manager and only he can move issues from Dev complete to Deployed to prod.

Only allow people in specific roles to move issues using this transition

There are a number of streams of work operating from one project. There is a group of content designers that pick up work from all of these streams by monitoring work that has been moved into Requires content and based on whoever has capacity. A role has been created for this group of people and only a person in this role can move work from Requires content to To Do, so that an engineer can pick up the work.

How do you use this rule? Or what ideas do you have for how this rule could be used? 🙂

In next weeks update, we'll spotlight "Check that an issue has been through a status"!

[Kat Warner]

meatball 

Interesting - I call this the sushi menu ever since I was taught the three lines button was called the hamburger.

[Daniel Lizik]

thanks