When a custom cascading field is updated, use an automation to edit another custom field

[Mireya Cintora]

Hi, I do not have any experience with using JSON as a FYI! We created two custom cascading fields to replace our custom short text fields (Facility Sandbox & Payer). With that though we needed to update our automation rules that involved those two short text fields, but the only way to use cascading fields in an automation is using JSON, at least that what rules said.

Can someone help me create that JSON coding to add to the 'More Options' section of the automation? I grabbed the custom field IDs of the two new cascading fields to get started..

• customfield_12256 (R&D Facility)
• customfield_12248 (R&D Payer)

[Bill Sheboy · Accepted solution]

Hi @Mireya Cintora 

For a cascading field, you set both the "parent" and "child" values at once with JSON:

https://support.atlassian.com/cloud-automation/docs/advanced-field-editing-using-json/#Cascading-select-custom-field

For example:

{
  "fields": {
    "customfield_12345" : { 
      "value": "parent_option1", 
      "child": { 
        "value" : "p1_child1"
      } 
    }
  }
}

However, your case seems more complicated as you appear to be mapping Short Text fields (Facility Sandbox & Payer) to the cascade ones with parent / child values.

Depending upon how many values are involved, you could use conditional expressions or lookup tables to help generate the JSON needed for each field.

Kind regards,
Bill

[Mireya Cintora]

Sorry for confusion, the screenshots are the original automation that needs adjustments. So what I need to be done is when the cascading fields R&D Facility and R&D Payer on the Epic are changed/updated, I would like it to update the cascading fields R&D Facility and R&D Payer on the children work types and sub-tasks.  

[Bill Sheboy]

Thank you for that information, and...

I recommend moving the condition testing the trigger work item is an Epic outside of the groups, as it is common to both.

Then use this JSON expression, substituting in the custom field ID values for the two different fields:

{
  "fields": {
    "customfield_12345" : { 
      "value": "{{triggerIssue.customfield_12345.value}}", 
      "child": { 
        "value" : "{{triggerIssue.customfield_12345.child.value}}"
      } 
    },
    "customfield_67890" : { 
      "value": "{{triggerIssue.customfield_67890.value}}", 
      "child": { 
        "value" : "{{triggerIssue.customfield_67890.child.value}}"
      } 
    }
  }
}

[Mireya Cintora]

So each group is split for:

1. Each Epic and its Children Work Types (Issue Type equals Epic)

2. Each Child Work Types and its sub-tasks (Issue Type does not equal Epic)

[Side note, originally I had this all under one since I wanted any change to the Epic would update the corresponding to all Children including the sub-tasks, but it wouldn't work so I split it up like so. ]

I tried but I am getting an error message? I am not entirely certain how JSON works but this is what I updated per your code above: 

[Bill Sheboy]

Thanks for the clarification, @Mireya Cintora on the issue types.  And, I had a stray trailing comma in my example which is breaking the JSON.  Please remove the final one after the customfield_12248 section.  I updated my earlier post to reflect both of those changes.

As a final observation: the Advanced Component feature with groups is very new, so I recommend keeping a close watch upon this rule's behavior.  If it does not work as you want, let me know as there is a workaround for this scenario using the Lookup Work Items action and a basic JQL branch (that people have been using for years).  That will work for up to 100 total work items.

[Mireya Cintora]

Awesome it worked perfectly! I left an image below for other people to see...

If I have another question related to cascading fields, can i ask here or create a new one? The original question I posted related to the trigger being "When: Value changes for," this time around when the trigger is "Work Item Created" I want any work item that has a parent work item, to copy over the field to its children work items.  I used the same logic that helped me solve the original issue but it did not work. See below:

[Bill Sheboy]

This other case is different, and reveals there are other scenarios to handle.  (More on that in a moment...)  Your original scenario was:

GIVEN a parent work item with child work items
WHEN field <X> or <Y> change in the parent
THEN copy the field values to the children

Your new one is:

GIVEN a parent work item with fields <X> and <Y>
WHEN a child work item is created with the parent assigned
THEN copy those fields from the parent

For this one, branching is not used / needed, but we do need to get the parent's data using the Lookup Work Items action (because the fields are not in the dropdown list of the action).  Perhaps like this:

• trigger: Work Item Created
• action: Re-fetch Work Item Data (This action is important to mitigate a timing defect with this trigger.)
• action: Lookup Work Items, with JQL of
  • key = {{issue.parent.key}}
• smart values condition: To check the parent was found
  • first value: {{lookupIssues.size|0}}
  • condition: equals
  • second value: 1
• action: Edit Work Item fields, this time getting the data from the lookup results

{
  "fields": {
    "customfield_12256" : { 
      "value": "{{lookupIssues.first.customfield_12256.value}}", 
      "child": { 
        "value" : "{{lookupIssues.first.customfield_12256.child.value}}"
      } 
    }
  }
}

Please note well: I only included the one field you show in your example.

Back to the possible scenarios, please consider which cases you want to handle as they may require additional rules with different triggers.  I will note the ones we have covered first, and ??? where the behavior is unclear.

1. when the fields change in the parent, update the child work items
2. when a new child work item is created, copy the fields from the parent
3. when an existing work item is assigned to a parent, copy the fields
4. when a work item is unassigned from a parent, do ???
5. when someone manually changes the fields in a child work item, reset them back to the parent values ???
6. when there is an Atlassian outage impacting automation rules, my understanding is some rules may not run from the events missed, and so create a rule with a Scheduled trigger and JQL to decide when / how to update any child work items

[Mireya Cintora]

Ok so i created a new automation to try it on a small scale but it reported some errors: 

Regarding your questions:

1. when the fields change in the parent, update the child work items
   1. That was my original question, which you helped me out with. 
2. when a new child work item is created, copy the fields from the parent
   1. This is what we are addressing with the second question correct?
3. when an existing work item is assigned to a parent, copy the fields
   1. This would be neat to include in our automation.
4. when a work item is unassigned from a parent, do ???
   1. This would be taken care of by the above question since the only time it would unlink from the parent would be in error. 
5. when someone manually changes the fields in a child work item, reset them back to the parent values ???
   
   1. This would be neat to include in our automation.
6. when there is an Atlassian outage impacting automation rules, my understanding is some rules may not run from the events missed, and so create a rule with a Scheduled trigger and JQL to decide when / how to update any child work items
   1. This would be neat to include in our automation. Currently we do a manual audit or we fill in fields manually. 

[Bill Sheboy]

The JQL for your Lookup Work Items action is incorrect and does not match the earlier suggestion.  Please use this and then re-test:

key = {{issue.parent.key}}

And, that list of other cases were not questions: they are other possible cases to cover if you want them with additional rules.  Given the number of rules you may want, I recommend working with your Jira Site Admin to help implement them as variations of the one I suggested.

• setting the parent to a value from empty: Requires another rule, with the field value changed trigger for Parent
• changing (or clearing) the parent: Same thing with a trigger on a change to Parent, but it also needs to use the changelog smart value to access the previous Parent.  Theoretically, this can be combined with the above rule.
• manually tampering with the values: Requires another rule, with the field value changed trigger for your custom fields to update them
• scheduled trigger rule to cleanup after an outage: Requires another rule, and can only be done when you can detect that the fields need to be updated using JQL

[John Funk]

Hi Mireya,

What is the use case? What exactly are you trying to do? When I update this field, I want to update this other field with this value ...   etc. 

[Mireya Cintora]

So when I update the the cascading fields R&D Facility and R&D Payer on the Epic, I would like it to update the cascading fields R&D Facility and R&D Payer on the children work types and sub-tasks.  

[John Funk]

See Bill's answer for syntax - I thought you might be updating a different type of field.