nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Issue passes If Statement in Automation, but conditions don't match

James K_

Hello, I have an automation that isn't behaving as expected. It runs when a customer opens a ticket and essentially has 2 relevant functions:
1. To set a supported version field based on the product version that customers select when opening the ticket
2. Then based on the time the ticket was opened (during business hours or not), and the ticket request type (an urgent ticket or not), the automation should add an automated message to the ticket.

There are different messages for the combinations of the three "variables" supported/unsupported, Out of Business Hours/During Business Hours, and Urgent / Non-Urgent requests, with the exception of Non-Urgent, Supported Requests opened during Normal business hours.

The first part of my automation sets the field for "Supported Version" to either "Yes" or "No". Then I have If statements for each set of 'variables'. I've added audit log messages in my automation to more clearly see which if statement is being verified, and I'm a bit confused as to how an issue can pass an if or if/else block, but not match the conditions:

If/else block

The following issues passed:

TSM-4140

The following issues did not match the condition:

TSM-4140

I had initially tried setting this up using a smartvalue that I set at the start of the automation to set the Supported, OoBH/DBH/ and Urgency status, however it seems that those smart values don't work outside of the if statement they were created in, so now each if block is a bit wordy, but for instance the ticket TSM-4140 should have matched the if statement conditions.

Is there an issue with having my if statements check against the field status "Supported Version" if I'm changing that value at the start of the automation?

Thanks,
James

Accepted answers

Boldizsár Vermes

@James K_ , my educated guess is that you need to re-fetch issue data if you want to count on a field value that is set after the automation started to run.

If this tip does not help, please share your rule with an audit log for further thoughts.

All comments

Boldizsár Vermes

@James K_ , my educated guess is that you need to re-fetch issue data if you want to count on a field value that is set after the automation started to run.

If this tip does not help, please share your rule with an audit log for further thoughts.

John Funk

Hi James,

Can you share the actual rule for us to take a look? And what exactly with it is not working.

Bill Sheboy

Hi @James K_

First, are you using Jira Cloud or Jira Server/Data Center with your automation rules? I hypothesize you have Jira Cloud, as you mentioned variables. The answer will impact possible suggestions to help.

Next, for a question like this, please post images of the complete rule and the audit log details showing the rule execution. Those will provide context for the community to offer ideas. When you do that, consider using a screen capture or browser addon which allows capturing a scrolling page in one image. That will make understanding longer rules easier.

Until we see that information...

If your combinations of data which map to messages have <= 20 cases, you may want to consider using the new Lookup Table feature rather than many if/else statements. Please look here to learn more: https://community.atlassian.com/t5/Automation-articles/New-Automation-action-Create-lookup-table/ba-p/2311333

Kind regards,
Bill

James K_

It's a bit trick to share the whole rule, as there are 13 if statements, and I can't scale the window over, but I'll share the start which checks for appropriate issue types, and sets the 'SaaS Ticket' field to "No" and sets the 'Last Customer Comment Date' to <Now> which is used for automated check ins in and shouldn't be of concern here:

Next there is a check against "EDG-Product Related Request" issue types, which are handled. The next major section looks to the selected version of the ticket and sets the field "Supported Version" to "Yes" or "No":

Next I have the 8 sections checking the various combinations of Urgent, Supported, and Business Hours, in the example here, an Urgent Ticket, Supported Version, and Outside of Business Hours:

For comparison, here's what the If statement for Non-urgent, Non-Supported, Inside of Business Hours looks like:

The outcome of any of these If Statements besides one (supported, non-urgent ticket, during business hours - which I have set up an audit log message for) should be an automated message, which I've already checked and the comment visibility is set to 'Share with Customer'.

James K_

I had a previous automation that functioned, but due to the need to factor in more besides business hours and SaaS/Non-SaaS tickets, I needed to expand the number of if statements and break the rule into two.

The audit log for a ticket that I just opened as a test for Non-Urgent, Non-Supported, In Business Hours follows:

ACTION DETAILS:
ISSUE CONDITION
The following issues passed:
TSM-4143
EDIT ISSUE
Issues edited successfully
TSM-4143
LOG ACTION
Log
Next If Statement: Product Licensing
IF BLOCK
The following issues did not match the condition:
TSM-4143
IF/ELSE BLOCK
The following issues did not match the condition:
TSM-4143
IF BLOCK
The following issues did not match the condition:
TSM-4143
EDIT ISSUE
Issues edited successfully
TSM-4143
IF/ELSE BLOCK
The following issues passed:
TSM-4143
LOG ACTION
Log
Next If Statement: Urgent, Supported, OOBH
IF BLOCK
The following issues did not match the condition:
TSM-4143
IF/ELSE BLOCK
The following issues did not match the condition:
TSM-4143
LOG ACTION
Log
Next If Statement: Urgent, Not Supported, OOBH
IF BLOCK
The following issues did not match the condition:
TSM-4143
IF/ELSE BLOCK
The following issues did not match the condition:
TSM-4143
LOG ACTION
Log
Next If Statement: Non-Urgent, Supported, OOBH
IF BLOCK
The following issues passed:
TSM-4143
The following issues did not match the condition:
TSM-4143
IF/ELSE BLOCK
The following issues passed:
TSM-4143
The following issues did not match the condition:
TSM-4143
LOG ACTION
Log
Next If Statement: Non-Urgent, Not-Supported, OOBH
IF BLOCK
The following issues passed:
TSM-4143
The following issues did not match the condition:
TSM-4143
LOG ACTION
Log
Next If Statement: Non-Urgent, Not-Supported, INBH
IF BLOCK
The following issues passed:
TSM-4143
The following issues did not match the condition:
TSM-4143

The last section is the one which I would have expected the issue to pass, but it didn't. Please let me know if there is an easier way to share the automation. I've exported the rule as json, but am unsure how helpful that will be.

Sam Harding_7kkuxm

Hi @James K_

Uploading the json of your rule could help here, but it also seems like there is some nuanced details at play here affecting your rule execution.

It may be more effective to raise this as a support request at https://getsupport.atlassian.com/ so we can take a look at your use case in greater detail, and get to the bottom of the problem

Thanks
Sam

William Rentfrow

We have found instances where comparing two fields of the same type and with the same data fails, but putting the values into actual variables first and then comparing them works. We've run into that mostly when trying to compare between two different product areas (e.g., Assets and JSM).