Automation Rules with Two Branches Not Working As Expected.

[Nicole Gosling]

Hi.  I am trying to modify an existing automation rule (AR) that has been working since it was created three years ago.  

This scheduled automation rule is runs every one hour and retrieve records where the "issue type equals Epic and project equals CC and status equals Invoicing and Approvals."

If all of the stories linked to the Epic are in "Done" or "Completed" status, the Epic transitions from "Invoicing and Approvals" to "Construction and Commissioning" status. 

I need to add a new condition to this rule that checks if the Operations Contact field is empty.  If it is not, the Epic transitions from "Invoicing and Approvals" to "Construction and Commissioning" status, just like the current AR does.  However, if the Operations Contact field on the EPIC is empty, then the Epic status doesn't change and an email is set to a group mailbox to populated the Operations Contact field.

I have read multiple knowledge articles, Atlassian documentation, but I can't find an resolution to my issue.

I made the following AR configurations but can't seem to get them to work properly.

1) If/Else - it would send email for Epics where the "Operations Contact" field was populated. I read the If/Else functionality can be tricky so I tried simpler approach (#2)

2) Multiple Branches - in addition to the conditions in the current automation rule, I add a check for the Operations Contact.  This one was looking promising however when I was digging into the audit logs I noticed that an email was sent for an Epic that had open stories and no operations contact.  Because I used "And" and not "Or" I would have expected the Epic to not pass the first condition in the second branch and do nothing.

Any help you can offer is greatly appreciated.

Thanks,

Nicole

[Bill Sheboy · Accepted solution]

Hi @Nicole Gosling 

I would expect the updated rule you show with the If / Else block to work for this scenario, although the branch on current issue is not needed...and neither is the condition on the Else: you could just assume the field is empty.

Without changing anything, would you please post an image showing the audit log details for the rule execution which did not work as you expect?  That may provide some context to help explain the symptom.

Regarding multiple branches, I would not try that for your scenario.  Such branches execute in parallel and so it will be difficult to diagnose what is happening for any timing-related problems.

Kind regards,
Bill

[Nicole Gosling]

@Bill SheboyThank you for your prompt response. I reviewed the automation rule using the If/Else functionality again, and it appears to be functioning correctly.

We use an API to import data from a another system ("Source System") every 15 minutes, including the Operations Contact. I believe my user received multiple emails for the same Epic because although she entered the operations contact in the source system, the API didn't update in the Jira Epic. I have created a ticket for our AMS team to investigate potential errors in the API.

I'm curious why the branch and ELSE condition are not necessary. We need to ensure that the child tickets are in Done or Complete status and that the operations contact field is populated before the Epic can transition to Construction and Commissioning status. Is there a simpler way to achieve this?

Thanks Nicole

[Bill Sheboy]

I am glad to learn the rule is working for you!

Regarding my other suggestions...

Once the rule is inside that first if / else block, the branch on current issue is not needed because the rule is already acting on the current issue.  The conditions on Area Crew and related issues will work without it.  The key is being inside the branch, and not adding to the conditions of the if / else block.

For the Else...the first condition tested "if Operations Contact is not empty".  And so the else to that would be "empty" and testing that is not needed.

Neither of those impact your rule behavior, and so definitely leave them as-is if it makes it more clear to you and your team.

[Nicole Gosling]

Hi @Bill Sheboy 

Thanks for your response.  If I understand your suggestion correctly, this is how I can configure the automation rule without using a branch. Correct?

Next question. If Area Crew = No, I need to use a different transition but everything else is the same.  Would you suggest that I create a separate rule to keep things simple or is there a way to work that scenario into this one without complicating things?

Thanks again for your help!

[Bill Sheboy]

Yes, that updated rule looks correct.  Well done!

Regarding "Area Crew", with the Data Center version of automation rules, I do not believe if / else blocks can be nested yet.  Given that, there are several alternatives...

Creating separate rules will potentially create rule maintenance / update problems, as they could get out of sync.  Although it will be quite clear what is happening in a single rule.

Another alternative is making the Area Crew test part of the if / else block tests.  To do this, I recommend pausing and creating a logic table to ensure the cases are all covered, in the correct order, and then testing fully.  For example:

         \    Operations Contact
Area Crew \   Is empty    Is not empty
---------  \  ----------  ---------------
No            send email  transition to X     
Yes           ???         transition to Y

A riskier approach (in my opinion) would be using a REST API endpoint to perform the transition and a conditional expression to select the destination status.  That would essentially inline the work.

[Nicole Gosling]

Thanks @Bill Sheboy I like the idea of having one automation rules however I am not sure it will evaluation the If/Else statements as I intended.  I came up with 8 scenarios. The are:

And this is how I configured the automation rule:

[Bill Sheboy]

Well done, and...creating the full logic table helps to use techniques like from Karnaugh Maps to decide what / when to test...

Viewing the table shows only the cases where "Child tickets are Done or Complete" do something, and so moving that test first (before the if / else block) helps.

Next, whenever the Operations Contact is empty, the email is sent.  And so that would be the first test in the if / else block.

Finally, the block may test Area Crew's value last is it impacts the transition-to status.

[Nicole Gosling]

Thanks! I don't understand what you mean in the last two paragraphs. Are there other changes I need to make to get it to work the way I want it to?

[Bill Sheboy]

As I do not have a Jira Data Center site, I do not know...my suggestions were based on how the if / else block works for Jira Cloud.

I was noting the order of the testing based on most-to-least restrictive, ensuring there would be no overlaps in cases.  If you have tested all of the cases and it works as expected, you are done!

[Nicole Gosling]

Yay! Thank you so much for your help; I've leaned a lot. Let the testing begin!