Make Jira workflow transitions react to project property changes

Learn how to create Jira workflow transitions, conditions, validators, and post-functions that work differently depending on the context of the project. If you’ve ever wanted to block the creation of issues for certain projects until they are greenlighted, you’ve come to the right spot.

Jira magic is workflow magic

How is it possible that Jira is so adaptable to almost any type of knowledge organization, and yet it allows the creation of robust processes that people actually follow?
Many of the magical powers come from workflows:

Workflows can be shared between projects, supporting standardization.
Yet they are endlessly customization.

Workflow customization has many parts, including the possibility to add any number of statuses and design how statuses are interlinked with transitions.

But that’s not nearly all! In fact, the most sophisticated area of workflow configuration is undoubtedly buried in the transition options: properties, triggers, conditions, validators, and post functions.

Conditions, validators, and post functions look at the issue

Conditions, validators, and post functions happen at different moments of the transition, but they are similar in a very basic way: they all look at the information stored in the issue and its context to restrict the transition (conditions and validators) or make something happen (post functions).

Since the context checked is relative to the issues, it obviously follows that similar issues transition identically in all projects with that workflow.

How to create conditions, validators, and post functions that check for the project

But what if I want to make my transitions sensitive to the project context? What if I want to ensure, for instance, that issues can’t be opened in inactive projects or that an engineer can’t start working on a customer project until the budget for that project has been approved?

Of course, you may argue there is a way around it: associating inactive projects with a different workflow scheme. There are at least two severe problems with that:

Workflow maintenance is important but should be minimized. Ideally, each project should be associated with only one workflow scheme from its creation. Since only Jira Admins can make these changes, it’s unrealistic to expect them to make modifications to the workflow schemes every time project contexts change (for example, every week).
Jira projects are static and don’t change over time. What changes is the work that they contain? Whoever maintains the workflows would have to check regularly with project leads and stakeholders or rely on sources other than Jira to be on the watch for changes in the project status. Making such a sensitive administrative issue reliant on communication between parts of the organization that are often not in the same team seems over the top.

Leveraging Projectrak for workflows that are project-sensitive

You’ll quickly realize that the problem is double if you read the two objections above. To solve it, you don’t only need to make workflows sensitive to projects. You actually have to make projects in Jira dynamic!

Projectrak (formerly Profields) solves both problems:

Thanks to its project custom fields, Jira projects can store data that change over time –either by manual input, with Bulk Operations, or synchronizing to any third-party tool through the REST and JAVA APIs.
Once Projectrak is in your Jira instance, transitions can be customized to look at the current value of any project field.
Finally, busy Jira admins don’t need to update project data, which anyone with the Projectrak admin role can maintain

An example of Projectrak project Layout with all the project information organized.

Workflows that listen to project data are more diverse, more dynamic, and ultimately smarter. The challenging part in creating project-sensitive workflows is identifying change-sensitive information that can stimulate the workflow, triggering behaviors that are smart for your processes.

That’s why we’re presenting three common use cases that we’ve seen used by our customers, one for each type of transition option.

We will assume the simplest possible workflow for all of them so we focus on the transitions without losing the big picture.

Use case 1: Block work until the project is budgeted (condition)

In projects for external customers, it’s not uncommon to start gathering requirements in Jira as part of the tender or proposal of interest and before a final agreement has been reached between the parties. Restraining your teams to start working on any issue unless the project has an approved budget can prove very useful.

Steps

Select the transition “start working” (between Open and In Progress)
Click on the conditions
Select the Projectrak Value Condition

Depending on your processes, there can be different ways to implement this condition. These are just two possibilities:

There is budget

4) Select the project custom field “Budget” (numeric)
5) Mark the budget different than 0, and add it

The budget is approved

4) Select the project custom field “Budget approval”

5) Mark the equal operator and the value “Yes”

Use case 2: Create issues only when the project is open

Similar in a way to the use case above: you might want to lock down a project so users don’t create more issues. There may be any number of reasons for this: the process behind the project is no longer supported, the application you were developing has been deprecated… or the project has simply been considered a loss of focus.
It’s a good practice to include this validator in all your workflows so you can always lock down a project that becomes inactive.

Steps

Select the transition “Create”
Click on the validators
Select the Projectrak Value Validator
Select the Projectrak field “status”
Mark the equalizer connector and the value “open”

Use case 3: Make issues inherit the current priority of the project

This trick can expedite prioritization if your teams use boards with information from different projects that compete for limited resources.

The idea is that if projects are prioritized, then you can automate how issues are ranked. Note that prioritizing projects is intended dynamically, i.e.: Project A may be unimportant this quarter and urgent in December. The issues created in Project A during this quarter will receive a low default priority today and a top default priority in December.

The board will then be populated with issues from multiple projects that are already pre-groomed!

Let’s see how to build this one. In this case, we’ll need some scripting.

Steps:

Select the transition “Create”
Click on the post-functions
Select Projectrak Script Function
And here comes the magic! Paste this code into the box:


import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.IssueManager 
import com.atlassian.jira.config.PriorityManager 
import com.atlassian.jira.issue.MutableIssue 
import com.atlassian.jira.event.type.EventDispatchOption 
import com.deiser.jira.profields.api.field.FieldService 
import com.deiser.jira.profields.api.value.ValueService 
import com.deiser.jira.profields.api.field.Field 
import com.deiser.jira.profields.api.field.priority.PriorityField 
import com.deiser.jira.profields.api.field.item.priority.PriorityItem 
  
def PROFIELDS_PRIORITY_FIELD_ID = 6 
def priorityManager = ComponentAccessor.getOSGiComponentInstanceOfType(PriorityManager.class) 
def issueManager = ComponentAccessor.issueManager 
def fieldService = ComponentAccessor.getOSGiComponentInstanceOfType(FieldService.class) 
def valueService = ComponentAccessor.getOSGiComponentInstanceOfType(ValueService.class) 
def user = ComponentAccessor.jiraAuthenticationContext.loggedInUser 

 try { 
    def project = issue.projectObject 
    PriorityField field = (PriorityField) fieldService.get(PROFIELDS_PRIORITY_FIELD_ID) 
    PriorityItem projectPriority = valueService.getValue(project, (PriorityField)field) 
    def issuePriority = priorityManager.priorities 
    .stream() 
    .filter { 
        priority -> priority.name.equals(projectPriority.text) 
    } 
    .findFirst().get() 
    issue.setPriorityObject(issuePriority) 
    issueManager.updateIssue(user, issue, EventDispatchOption.DO_NOT_DISPATCH, false) 
} catch(NoSuchElementException ex) { 
    //The priority of the project does not exist at issue level 
} catch (Exception ex) { 
    //Here you can handle unexpected exceptions 
}

Hint: the use case is about building a contextual repository

Note that this is a bit of a dummy example to cue you into the important takeaway: using Projectrak (formerly Profields), Jira projects can work as repositories of contextual data that can be inherited by issues while varying from project to project.

Imagine, for example, that your company needs a deputy lead for each project component to cover the vacations and leaves of your main assignee. There’s no place in Jira to do that!

Panasonic created a project layout for component deputies to solve this issue in their change management process, so every change request would be automatically assigned to component leads, and deputy leads for analysis.

Take a look at this video for more details!