IF Condition running despite not fitting condition

[Erica Robinson]

I've been working on building out an automation that will generate a set of subtasks for teams based on the number of employees selected within a form on JSM.

As of right now, I have been able to build the subtasks with no issues, the values are coming in from the form as they should. The issue I'm running into is that when I'm trying to have an IF/ELSE condition run based on the number of employees selected, the IF/ELSE runs even if the value isn't met. For example, if the submitter selects 3 employees, only the first 3 IF/ELSE conditions should run, the other seven shouldn't. What's currently happening is all of them are running.

Here's the condition for the first set of subtasks:

The condition is the same for the others with the "Second value" increasing to 3, 4, 5, etc.

The end goal is that if a user selects a number of employees, example: 4, then the subtasks for 1, 2, 3, and 4 are created, but 5-10 are not.

I've had a comment added to the main ticket that adds the value in plain text to confirm that jira is reading the value as expected:

I've also attempted to make the value a variable and the results were the same.

Any assistance with this would be appreciated. :)

[Bill Sheboy · Accepted solution]

Hi @Erica Robinson 

For a question like this, context is important for the community to help.  Please post the following:

• an image of your complete automation rule in a single image for continuity
• images of any relevant actions / conditions / branches
• an image of the audit log details showing the rule execution

Until we see those...

The if / else block does not process each block that matches...The assumption is the rule-writer ordered the blocks to be mutually exclusive, in the desired order of testing.

And thus if I am guessing your rule structure correctly, you were thinking it would process each one where the number matched your greater than criteria, correct?  Seeing your entire rule will confirm this.

There are several ways to solve this, such as using branching with conditions or using separate if / else blocks for each condition test, or perhaps even using an Advanced Branch.  Again, seeing what actions your rule takes will determine how to proceed.

Kind regards,
Bill

[Erica Robinson]

Hey Bill,

Apologies for not including those. Here's the full rule, it's a bit long so I've split it into two columns:

Here's the most recent audit log:

I removed the action to create the comment from the automation as it already confirmed the value was coming across as expected, but it can easily be added back in.

Correct, we need each section to run when a value higher than itself it selected since the users have the option to add up to 10 values in the form.

Thanks,

Erica

[Bill Sheboy]

Thanks for that information!

Have you tried writing the form field to the audit log to confirm it contains what you expect?

What is the type of your form field?

I notice the first two conditions both test a value greater than 2.  Is that correct?

[Erica Robinson]

I hadn't tried writing the form field to the audit logs, but I did have the field written out to a comment at one point and it was returning the values I was expecting. I can test again using the audit log instead.

The type is a dropdown.

Ah, good catch! That first one should be a value greater than 1. I've adjusted it.

[Erica Robinson]

Hey Bill, 

I've added a log entry to record the value for the number of employees selected:

And here's the associated logs from that test run:

Thanks,

Erica

[Bill Sheboy]

Awesome; that helps identify the cause: please note in the audit log how the value from the dropdown is surrounded by brackets (either as text or as a list).  And so the comparison of:

The test of "[3] greater than any number" will always be true because it is performing a text comparison and the left-square bracket [ character-code is always greater than any digit character-code.

However, are you certain that field is a drop-down type?  I just tested this myself with a dropdown field in a JSM form where the field only contained numbers and it did not add brackets when the form was form was submitted.  Here is my example form field and what appeared in the log:

Do the dropdown values in your form field choices contain brackets, or is it another field type?

[Erica Robinson]

Hey Bill, 

I can confirm that we're using a dropdown within the form: 

I do have one automation that uses the "forms.last" method to get the data from the form upon initial submission. This automation will update the initial ticket and create a table in the description based on the number of employees selected. I added a logging step to the initial automation and noted it returns a non-bracketed value, like your example.

The second automation (the one I'm having issues with and as you noted is return bracketed numbers) creates subtasks for different teams for each employee (3 per employee). The second automation kicks off after the initial ticket has been fully updated. I use the "issue.forms.UUID" call to get the data since the trigger is "issue transitioned" not "forms submitted". 

Despite the calls being different, I would've expected the results to be the same given they're accessing the same data. 

I'll test with having both automations kick off using the same trigger and see if that resolves the issue or just makes a mess. I will also submit a support ticket to see if they can look into why these two calls are getting different results.

[Bill Sheboy]

Yes, I would also expect the results to be the same (when the same form instance is selected, regardless of trigger).  Let's try figuring out what is in that field...

In your current rule, and near where you are logging that value which is bracketed, add two more writes to the log:

field size assuming a list value: {{....your form field info.label.size}}

field value assuming text: {{....your form field info.label.substringBetween("[", "]")}}

If the first one returns a number (e.g., 1) then the value is a list, and could use this to get the number 3, or whatever was selected:

{{....your form field info.label.first}}

If not, the second one should correctly extract the value from within the brackets.

[Erica Robinson]

I've added those two extra writes and it is returning a number:

With that in mind, I'll work on making some adjustments to the automation based on either this or triggering it with the "Forms submitted." I appreciate all of your help with this issue!

- Erica

[Bill Sheboy]

Yup, it is a list of values.  Please try adding the .first to get the value.

[Erica Robinson]

Hey Bill,

I just tested this with the automation and it it did work as expected! Thank you so much for helping me sort this issue out. :)

- Erica