What is Advanced JIRA Workflow Configuration

We’ve already discussed all the merits and possibilities of JIRA as a workflow management tool and even touched upon the basic notions of JIRA workflows in this article. Yet being an Atlassian Solutions Partner, we usually perform custom and therefore more sophisticated workflow configurations, the ones that can’t be done by efforts of a system administrator. So this article is dedicated to advanced JIRA workflow configuration, its aspects and peculiarities, and how Polontech team dealt with them using a number of cases as an example.

As you might already know, JIRA has a number of built-in workflows that can provide for basic processes. In case a company wants more diverse functionality, a workflow must be either created from scratch, or an existing workflow must be configured. Advanced workflow configuration presupposes wider number of notions than the basic one. Let’s examine each of them in detail.

Jira workflow Triggers

Triggers are powerful feature for workflow automation. They exclude the need for developers to manually change workflow statuses after they have created a branch, completed a review, etc. Instead, the information from your development instrument (Bitbucket/Fisheye by Atlassian or even GitHub) will be synchronized with your JIRA issues.

There is a number of preset triggers for most typical interactions between a development tool and JIRA workflow. They are triggers for:

• To Do -> In Progress issue transition
• In Progress -> In review issue transition
• In Review -> In progress issue transition
• In Review -> Done issue transition

Of course, each of the standard triggers can be edited if you need wider functionality.

Jira workflow Validators

These features evaluate whether the transition a developer makes is valid, or complies with the requirements set for it. Validators check the input to the transition, and if it fails, the transition doesn’t complete and the issue status doesn’t change. Instead, validator generates an error alert message. A validator is a great control mechanism that allows not to check the transition’s validity manually and saves a lot of time and effort.

Case study validators by Polontech

Validators:

–       SUBEX: Subtask exists validator

–       Allow the transition only if  the subtask for the ticket exists (subtask should have type specified in configuration)

–       SUBSTAT: All subtasks in status validator

–       Check if all subtasks are in the specified status in validator configuration; if yes – allow the transition, deny othervise (subtasks and statuses should be ones specified in the configuration)

–       For Jobs when we are executing transition from In Progress to Ready – we should check that all subtasks of the Work Step type are in the Done state (or are in the transition to the Done state)

–       LINKSTAT: All linked issues in status validator

–       Check if all linked issues are at the specified status

–       When we transit Sales Invoice from In Preparation to Sent state – all Incoming POs should be in To Be Invoiced state

–       LINKEX: issue has links to the issue types validator

–       Check if the issue has links from the ticket to the related issues: incoming PO should have links to jobs, outgoing PO should have links to work steps, sales invoice should have links to incoming POs, purchase invoice should have links to outgoing POs (the link and issue types should be specified in configuration)

–       LINKSUM: check if the summary of the specific data in linked tickets corresponds to manually entered amount

–       When we are moving the Sales Invoice to the sent status – allow the transition only when summ of all Incoming POs corresponds to the amount inside the Sales Invoice custom field

–       When we are moving the Purchase Invoice to Paid status – allow the transition only when summ of all outgoing POs corresponds to the calculated net amount got from the Purchase Invoice custom field

Jira workflow Conditions

Another useful control feature is condition. It allows to limit the authority to execute the transition to a certain number of users. This can be either only the reporter, or the people with specified permission. If a user isn’t included in condition, he or she won’t have the transition button on the “View issue”page. What is more, to provide a complex many-level authority, you can create a group condition and set up the condition logic using All and Any settings. Yet bear in mind, that conditions can’t be applied for validating input parameters – for that you’ll have to implement a validator.

Case condition:

–       ITYPECOND

–       show panels only inside appropriate issue types according to the description

Properties

To add custom features (for example, automatic translation of a workflow from english to your language) to your workflow transitions, implement such elements as properties. JIRA offers a great many of properties, so they are easily added by clicking at the Properties menu of a transition. What is peculiar about properties is that they can’t be edited, so in order to alter something in it, you’ll need to first detele it and set it anew, upgraded in the way you need.

Workflow properties can also be used to introduce restrictions on transitions or steps. Yet this kind of properties are not safe to use, so they are recommended to use only at your own risk. You can find the available restriction properties at Atlassian web site.

Jira workflowPost Functions

As a transition is completed, you need to perform certain actions to update the workflow. Instead of doing it manually, it’s better to implement post function that can:

• update issue fields
• comment an issue
• trigger event notification on transition completion
• change history for the issue

There are essential and optional post functions. The essential ones can’t be edited or deleted and should be performed in a certain order:

1. Issue status setting
2. Adding a comment
3. Updating change history
4. Re-index to sync with the database
5. Launch a Generic event

What concerns optional post functions, they are the following:

• Assign to Current User
• Assign to Lead Developer
• Assign to Reporter
• Create Perforce Job Function
• Notify Hipchat
• Trigger a Webhook
• Update Issue Field

You can also create your own post function with the help of Workflow Plugin Modules plugin.

Case study of Polontech post function

–       PARUPD: Update parent if siblings in status

–       If all work step have the done status the parent ticket should be automatically moved from in progress to ready (the issue types and statuses should be specified in the configuration screen)

–       LINKUPD: Transit all linked tickets when the transition of the ticket occures

–       When we transit Sales Invoice from In Preparation to Sent state – all Incoming POs should execute the transition from To Be Invoiced to Invoiced state.

–       When we transit Purchase Invoice from Waiting for Invoice to Invoice Received state – all Outgoing POs should execute the transition from Sent to Invoiced

So this is what elements advanced JIRA configuration consists of and how Polontech performs some of them. Yet if you feel like you won’t be able to master this process yourself, you can always turn to our team for assistance.