Two Jira Rules Executing At Same Time When Only One Option is Selected - Jira Cloud

[Digvijay Singh Gehlot]

Hi Community,

I have configured two jira rules in Jira Cloud as below.

Problem: When selecting only one option (Option 1) in Select List (multiple choices) on Parent, two Child issues are created instead of one.

I want that:

- If user selects Option 1 in Select Field, Only one child should be created via Jira Rule 1

- If user selects Option 1 and Option 2 in Select Field, Only one child should be created via Jira Rule 2. (It should ignore Rule 1 in this case)

Jira Rule 1:

Jira Rule 2:

Please provide necessary steps/ conditions/ screenshots to setup the required Rule config, to achieve the requirement.

Thanks 

[Bill Sheboy]

Hi @Digvijay Singh Gehlot 

To ensure consistent behavior, I recommend solving this scenario with one single rule, and using the different field change smart values to detect what was added rather than using conditions.

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/#--fieldChange--

Using a condition test the current value(s) of the field, and thus other changes to the field could lead to creating duplicate work items from multiple rule triggers / executions.

Specifically, if a person selects one option and even briefly leaves the field, returning to select another option, that will trigger the rule multiple times.

Kind regards,
Bill

[Digvijay Singh Gehlot]

Hi @Bill Sheboy , 

Thank you for your message. 

My use-case is:

- Select List (multiple choices) has 30 options.

- Rule should execute only on four specific options although other options are selected or not. 

In DC, I am able to create one rule and add more than 65 components with If-else conditions (contains any of/ contains none of) to accommodate the specific 4 options combination. 

In cloud, there is a limit of adding components in a rule i.e.upto 65. So, I have to break it in two as shown in above example. 

Could you further guide me, how should I use field change smart value for below scenario? 

Four Specific options: A, B, C, D

User selects X, Y, A, B in select list field. 

Then how the rule will check with field change for options contains A, B.. 

Thanks

[Bill Sheboy]

@Digvijay Singh Gehlot -- You original question is tagged as for Jira Cloud and now you mention Jira Data Center.  Which version are you using?

The different Jira versions have different automation features, and so knowing the specific version will help clarify what may help.  For example, those extra field change smart values I noted do not exist in Data Center.

Next, you note 30 options and the rule limits on 65 components, but you appear to only care about 4 options: A, B, C, D.

Even assuming a worst case scenario of all possible paths, that would be 2^4 or 16 paths.  Adding an if / else block, all the possible ones could be tested in the rule and fit within the rule limits.

Or, are you trying to span all the 30 options, with 2^30 cases?

Backing up a bit: what problem are you trying to solve with this rule?  What is the purpose and expected outcome?  Knowing that may help identify other possible solutions.

[Digvijay Singh Gehlot]

Hi @Bill Sheboy 

I am currently using Jira cloud. DC is just for reference how I built it more than 65 components. 

Structure of my Jira Cloud Rule:

Trigger: Field Value Change 

Condition: I have added 30 fields and set as not empty and then able to add only 10 paths of if-else which further includes field conditions (contains any of and contains none of) 

Upto this point I am getting error message on Validating the rule, "62/65 components are added"

So, I created another rule with 30 fields conditions and remaining 6 paths of if-else 

And then I realized that after selecting only 1 option in Select List field, two child issues are creating instead of one. 

Is there any possibility to add negative condition in Rule 1 or Rule 2 so that both rules don't trigger together. 

And how to use field change smart value in both rules, sharing a screenshot will be helpful. 

Thanks

[Bill Sheboy]

Honestly, I am still unclear on what problem you are trying to solve with this rule by checking so many values.  That is, "why do this?"

Until that is known...

Logic which tries to check so many values and span the checks across multiple rules is often a brittle approach.  The reason is multiple rules are separate and the conditions must be mutually exclusive to prevent overlaps.

Additionally for what you describe, there is a high risk the actions to create new work items will happen every time the field updates unless the change log is checked.

Let's assume for the moment your field option values help decide some specific data in a new work item, such as the Summary.  In that case, the rule could greatly simplify:

• limit the field updated trigger to only look for additions
• create a Lookup Table to map the field options to the Summary values
• use the field change smart value to identify the additions to advanced branch for each one
  • and then create the work item with the relevant Summary from the table

Thus a rule to handle 30 options would only be 4-5 components long, instead of longer than 65 components.