Workaround for tracking KPI performance using automation

[#1]

Hello all!

It's me again with another use case I've had for a few customers now.

The requirement is that the customer has a deadline, usually for a workflow transition, and they want to understand the performance of the deadline, how often this deadline is met or breached.

There are, of course, apps for this, such as Time to SLA, which I've implemented in customers and work well. There is also the added benefit, in particular for the app of Time to SLA, that you have included some dashboard gadgets. 

If an app isn't a possibility for budget or other reasons, here is how I implemented this requirement in two of my customers cloud instances.

First of all, we need to identify the deadline. If this is a custom field that already exists, great.

I also have a use case where this deadline needs to be derived from data, let's look at that as well while we're here. 

In this case, I have an automation that has the trigger of when the issue is created. 

Then, I have a condition for the type of issue, but you could also have here other attributes, such as the project, project category, etc.

Then, I have an IF / ELSE condition where, if for the issue type specified, the priority is 'Highest' to have an action to edit the issue field to set the Deadline with this smart value 

{{now.plusDays(5)}}

Then, in the Else condition, I have specified what to set the deadline to for the priority, 'High', 

{{now.plusDays(10)}}

Then a further Else for the priority, 'Medium', 

{{now.plusDays(20)}}

Once we have a deadline, we will need to capture the date and time in which the transition which is the target of the deadline has taken place. I am doing this with another automation rule.

Here, the trigger is the transition which the deadline is for.

Of course, you can also have conditions to limit the scope of this rule, such as specifying the issue type or project.

Then, we have the action to populate a date field with {{now}}.

Finally, we need another automation to do the confrontation between the deadline and the actual transition date, where we can also set a value for the outcome, so comparing the two dates and where the number is negative, to set a value of breached and where the number is positive or neutral to set the value of met.

In this case, we are using a scheduled trigger, but you could also use another type of trigger if you wanted.

Here we have an IF / ELSE condition where we are comparing if the date where the transition was actually done was before the deadline date (this is the comparison we are doing between the two custom field values).

Then, we have an action for the IF to set a custom field for the performance to be 'MET', otherwise, if the actual transition date is not less than the deadline, we will have the action to set the performance to 'BREACHED'.

In this way, you can obtain a performance of your issues in this scope against a deadline.

A few caveats:

• This is my opinion. Other opinions are available. :)
• Could you do something more elegant with Listeners? I am almost certain but I don't have those skills.
• Here, you would have to create several rules and custom fields. Therefore, this solution, as it is outlined here, isn't going to be as viable for a Jira standard instance. However, you could use more conditions and limitations to try to mitigate for this. Please reach out if you think I can help you with this.
• This is a solution that I came up with for two different customers but this article is actually a hybrid because in one customer, we have Time to SLA and, in the other, they have eazyBI, so we don't need to capture these transition dates in automation. This might also be the case for you, in the sense that, if you have already some apps available, you could implement something like this without creating as many rules or fields.

I hope this helpful for anyone with this use case. If you have any suggestions to improve this approach, please don't hesitate to share your feedback in the comments.

Cheers!

[Bill Sheboy]

Hi @Valerie Knapp 

Thanks for your article.  A couple of suggestions for this scenario are:

• The Issue Created trigger can have racetrack errors where all of the data may not yet be available when the rule starts.  And this could cause problems using the fields to find the dates.  The workaround is to always add the Re-fetch Issue action immediately after the Issue Created trigger to slow the rule a bit and reload the data before proceeding.
• Have you considered using Create Lookup Table to map the field data to the amount for the date / time increment?  That would remove all of the if / else logic and, the repeated Edit Issue actions, and make rule maintenance easier.

Kind regards,
Bill