Jira workflows with action conditions in JCWE
Keeping a necessary minimum number of workflows is one of the essential rules when managing workflows in Jira at all. You certainly don’t want to have a mess in the configuration and having workflows as generic as possible surely is a good idea. However, there’s also the other side of the coin – workflows have to be functional and correctly map your processes in Jira. All you need is… flexibility.
JCWE comes in pack with features boosting the configurability of workflow conditions, validator, and post functions introduced by the app. Action conditions, because that’s what we are talking about, make it possible to decide if a workflow condition, validator, or a post function will be triggered based on the issue data (JQL condition) or user groups or project roles (executor condition). In this article, we’ll present a few examples of how to take advantage of these powerful features.
Fast support for blockers
In support processes, it’s a common case to have two or three tiers of support with each having different responsibilities. Before a support ticket gets to the 3rd line, it has to pass the previous two. JCWE can enforce this process with the Was current issue in status condition (or validator), which will hide the 3rd line support transition unless the issue was in 2nd line support status. Generally, it’s a good idea to keep things structured and transparent, but what if we encounter an unusual case? Something that has to be taken care of by experts right away. We need an emergency way out.
Let’s say we want to disable the validation for bug tickets with the Highest priority because such issues might require urgent actions from our third-tier support experts. No problem. Just add a JQL condition type = Bug AND priority != Highest to condition and that’s all. From now on the Was current issue in status condition will not check bugs with Highest priority.
Transition monitoring
Most of the time you want specific actions to be done by certain people. For example, all the tasks, stories, and bugs should be closed by the product owner upon checking and approving them. On the other hand, completely blocking the corresponding transition for other users might be unfortunate, because the PO can be out of office and then your process gets stuck. The solution could be to keep the transition available to everyone but mark the issue in a way when it’s used by someone else than intended.
JCWE introduces the Comment current issue post function that can be used to add a comment during a workflow transition what could be our marker. But we don’t want to use this marker if the product owner is the one closing the issue and that’s when the Executor condition comes into play. Define that the post function should be triggered when the user is not in the Product Owner project role. Simple as that. Moreover, if you want to make the comment more meaningful, use the {source.currentUser.displayName} macro to have clear information on who transitioned the issue.
Grade based issue access
Grades are a common way to describe an employee’s place in a company’s hierarchy. The system is implemented by numbers, letters, or different names depending on the organization. Grades are related to all kinds of things like salary range, various benefits, responsibilities, or permissions. This can be also used for designing access to Jira issues.
To cover this case we might want to assign the appropriate security level based on the grading system of the company. Setting the security level can be done automatically with JCWE’s Set security level on current issue, but what about the relation of different security levels to company grades? We can add a few post functions mentioned previously, each with a different JQL condition. One post function would set the security level X if the Grade field on the issue equals e.g. Level A and the other one would set the security level Y for grade Level B and so on.
Leave request approval
Almost every time you want to go on leave, you have to create a new request and at least get approval from your supervisor or manager which is completely normal. When processing such requests in Jira, it is customary to see a user picker field like Approver on the issue view. This person will decide about your leave and it would be wise to make a restriction that only he/she can do it. But again. What if the supervisor is not around?
Jira Custom Workflow Extension brings to the table the Is current user in custom field condition/validator. It can be added to your workflow in seconds to make sure that you can approve or reject someone’s requests only if set in the Approver field. To make sure that we have a way out when the supervisor is not reachable simply set the Executor condition saying that the workflow condition will not work for the users from the HR Manager group
Escalation adds watchers
In some processes, issues can be escalated to mark them as urgently needing action or response in case of a support ticket from whoever is responsible. Such an indication might come from different stakeholders and you might want to take it into account when building processes. Let’s say that an escalation might come from the upper management of the organization. You might want to consider treating it in some special way…
Adding watchers to the issue is a good way to get people notified about what is going on with the issue. In our case, we may want certain users like the product owner or project manager to watch the issue if it’s escalated by someone from the upper management group of users. To achieve it, we need to add the Add watchers to current issue post function with the Executor condition restricting it to work only if the upper management triggers the transition.
Key takeaway
Jira Custom Workflow Extension is a tool that implements a lot of new workflow features such as post functions, conditions, and validators. While they are extremely useful, the feature that adds something special to the configuration is the Action conditions. The setting decides whether the action (validation or post function) should be triggered based on the issues and executor. More importantly, you can build more flexible Jira workflows which is a great value itself.