Create sub tasks based on the input from two multiple select list fields

[Molly Hopper]

I have two multiple select list fields that I would like to create sub tasks for each option select.

For example what I need:
custom field 1 has the options: a, b, c, d, e
custom field 2 has the options: 1, 2, 3, 4, 5

If "a, c, e" are selected and "1, 4" are selected I'd need the following subtasks:

a, c, e, and, a-1, a-4, c-1, c-4, e-1, e-4.

What I have: 2 different automations (showing 1 below, set up identically but with different smart values) but I'm still left having to manually create some sub tasks and wonder if there is a way to automate it. 

With the 2 rules I have now I would get the following subtasks:
 
a, c, e, 1, 4

 Is there a way to iterate the sub task creation over multiple smart values? 

[Bill Sheboy]

Hi @Molly Hopper 

Rules do not currently support nested branching (i.e., branches within branches) or nesting list iterators when the values are at the same or higher scope (i.e., two custom fields in an issue).  That makes solving this quite challenging, and I'll outline four approaches to help you decide if you want to take on that challenge / risk.

#1) Build this outside of Jira using another tool

For example, such as a standalone service that can be called from a Jira automation rule using the Send Web Request action.

I can think of three other rule-based workarounds for your scenario, all of which require some degree of hardcoding the custom field values.  However, first some questions, and assumed answers: 

When these custom field values are set, that produces some period of variability.  And so...

• Using a field value changed trigger seems like a bad idea for this scenario.  Would using a manually triggered rule be acceptable?  Assumed answer: yes, and that will be the base for the solution approaches.
• How stable are the field values, once selected?  Assumed answer: mostly stable.
• What happens when there is an "oops" and the incorrect values are selected?  Assumed answer: they will be manually cleaned up.
• Assumption: for simplicity, I am assuming only the Summary of the subtasks will change, but that is not a limitation to set other fields.
• Assumption: there is no way to control the order of the created subtasks with automation rules for this scenario

#2) Hardcoded conditional expression and created variable to drive advanced branching

A large conditional expression could be created, checking each value in CustomField1 to then iterate the values in CustomField2, building a created variable.  The variable may then be split for branching.  For example:

• action: create variable
  • variable name: varCombinations
  • smart value:

{{#if(issue.CustomField1.value.match("(value A)").size.gt(0))}}
  {{#issue.CustomField2.value}}value A--{{.}},{{/}}
{{/}}
{{#if(issue.CustomField1.value.match("(value B)").size.gt(0))}}
  {{#issue.CustomField2.value}}value B--{{.}},{{/}}
{{/}}
...repeat as needed

• advanced branch:
  • smart value: {{varCombinations.substringBeforeLast(",").split(",")}}
  • variable name: varOnePair
    • to access the pieces, split the variable
      • field value 1 is {{varOnePair.split("--").get(0)}}
      • field value 2 is {{varOnePair.split("--").get(1)}}

#3) Hardcoded conditional and created lookup table to drive advanced branching

Similar to #1 above, but store each entry in a table to improve readability / maintenance.  For example:

• action: create lookup table
  • lookup table variable name: tblCombinations
    • row
      • key: value A
      • value: {{#if(issue.CustomField1.value.match("(value A)").size.gt(0))}} {{#issue.CustomField2.value}}value A--{{.}},{{/}}{{/}}
    • row
      • key: value B
      • value: {{#if(issue.CustomField1.value.match("(value B)").size.gt(0))}} {{#issue.CustomField2.value}}value B--{{.}},{{/}}{{/}}
    • ...
• advanced branch:
  • smart value: {{tblCombinations.entries}}
  • variable name varOnePair
    • smart values condition: test if varOnePair is not empty
    • ...the remainder is the same as #1 approach

#4) Multiple rules, chained from one rule

Create a rule with an incoming webhook trigger, assuming it will only process CustomField1's value A.  Branch over the values in CustomField2 to create the subtasks.

Clone that rule N-times, once for each CustomField1 value.

Create a manually triggered rule which will use the Send Web Request action to selectively call each rule:

• trigger: manual
• branch: current issue
  • condition: CustomField1 has at least value A selected
  • action: Send Web Request, to call the first incoming webhook triggered rule, allowing the rule to proceed if the call fails and logging the result
• branch: current issue
  • condition: CustomField1 has at least value B selected
  • action: Send Web Request, to call the next incoming webhook triggered rule, allowing the rule to proceed if the call fails and logging the result
• ...repeat for the other cases

Kind regards,
Bill