Automation to sync multiple specific labels from parent to child issues

[Daniel Lee]

Hello, I’m trying to set up a Jira automation that does the following:

1. Look at a parent issue (Epic) and check to see if they have any/many/all of the following labels:
   Type_PI1
Type_PI2
Type_PI3
Type_PI4
Type_PI5



2. If the Epic has any of these labels, perform an action where the child inherits these labels (Epic -> Stories/Tasks -> Subtasks).

3. Also, if any labels are removed from the parent, they should also be removed from all children.

I’ve had challenges particularly with the point (3), making sure labels removed from the parent actually are removed from the children. For instance, when someone updates the labels in bulk (i.e. user removes Type_1 & Type 2, then changes it to Type_3 & Type 4. The issue history just shows a single “labels changed” entry, which I think makes it hard for automation to detect what was added vs what was removed.

I'm not sure if I need multiple rules here, or a scheduled rule that simply re-syncs children to match the parent rather than relying on the “field changed” trigger.

I don’t mind which approach as the important thing is to have a reliable setup that keeps the labels sync'd.

Has anyone set up something like this or can help me resolve this query please? 

Thanks in advance!

Note: Here are a couple of screenshots of a rule I've tried without success. I'm just trying at a Story to Sub-Task for now. 

[Bill Sheboy]

Hi @Daniel Lee 

When do you want the labels synched?  You show a couple of example rules, where one uses a Scheduled trigger and the the other uses Field Value Changed for the labels.

Next, you note examples of adding / removing labels and of just keeping them aligned.  Have you tried rules where they just copy the labels from the parent work item to completely replace them?

Finally, you seem to be describing only update cases. However, there are several others, potentially requiring multiple rules.  Please consider which cases you want to cover, as they included at least these:

• When the labels change in a parent work item, update its children to match
• When a work item is created with a parent, copy from the parent
• When a work item is removed from a parent, do ???
• When a work item changes parents, copy the labels from the new parent
• When a work item changes type such that it no longer has a parent, do ???
• When someone changes the labels in a child work item, reset them back to the parent?
• When Atlassian has an outage preventing rules from rules from running, they do not necessarily all run later to "catch up" for different events (e.g., work item edit).  For this case, it can help to have a scheduled trigger rule with JQL to update any out-of-synch work items.
• This amount of field synching can use up a bit of automation capacity.  Given different license level, service limits, this means rules may halt running in the site if the limits are hit.  Please talk to your Jira Product / Site Admin if you have concerns about this, which can sometimes be mitigated with less frequent field updates.

Some of these cases can be combined to use fewer rules.

Kind regards,
Bill

[Daniel Lee]

Hi @Bill Sheboy 

This was my initial thinking (but totally ok with being flexible):

1. When? As soon as the Epic label changed (any of the Type_PIx ones), so that dashboards that use this specific field will also be up to date in near real-time.
2. Also When? In addition to above, run a scan every 12 hours, to see if anything got missed by (Point 1) above. 
3. I like your thinking but in our case, each issue (Epic, Story, Task, Sub-task) carries its own label specific to that label that shouldn’t be touched. The only labels that must stay aligned are the Type_PI(1 through to 5). A replace would wipe these non-Type_PI labels from the children.

For all your 8 x dot points:

• Your first point matches the original use case unless I am misunderstanding. Label Change = Yes.  I guess this would be covered by the (1. When?) above. 
• For new child issues, we want the rule to copy only the Type_PIx labels from the parent. I guess this was also the reason for the (2. Also When?") 12 hour above
• If a child is unparented, it can keep whatever labels it already has. There's no need for it to maintain any Type_PIx. 
• If the parent changes, the child should remove the previous parent’s Type_PIx labels and pick up the new parent’s ones.
• Same principle as (point 3 above) unparented cases above. No further syncing required. 
• If someone changes the Child one, then it should reset to the parent one but only for the Type_PIx labels. To be honest, people have been clearly instructed to update the Epic and treat that as the source of Type_PIx truth. So technically, everything should reset back to the Type_PIx labels on the Epic. 
• Atlassian Outages - will the (Also When? 12-hour scan) help here? 
• Thanks for the heads up. The (1. When?) rule would only trigger once a parent has been updated.. and the (Also When? 12-hour scan) would only update exceptions. This is also only being applied to a handful of projects, not across the whole enterprise too, which lessens the total number of updates. 
  
  I’m totally happy to be convinced if there’s a better way to approach this to meet the items above. At the moment I haven’t been able to get anything reliably working.

[Bill Sheboy]

Thanks for those additional details, @Daniel Lee -- Please note I was listing those other cases to help you consider what / how to handle them...and not as a roadmap to provide you a bunch of rules.  I would actually need to implement each one to determine the exact steps, and then post those details.

Short answer: my recommendation is to make one single rule for field changes (or scheduled) which updates children for a specific type of parent.  Confirm that works as expected.  Only then investigate adding / modifying rules for other cases.  Ultimately, it may be easier to use a separate custom field for the Type_PI1..5 values rather than Labels to ensure the separation and synch of the values is accurate.

From what you described...

Updates in "near real-time" may not be fully possible. Yes, you could create a lot of rules to cover the cases and get closer to the current values across the issues, but remember the possible timing / outage / usage limitations.

Another wrinkle you describe is selectivity setting the labels: the parent label values are a superset of what could be in the children.  You do not want them to exactly synch from parent to child.  This makes solving this much more difficult.

There are known rule defects where when a list field such as Labels change, the rule cannot consistently detect exactly what changed.

A possible workaround would be:

• when a rule triggers for a parent, gather all of the labels-of-interest which are currently used in the parent, probably using the match() function and regular expressions
• for a child to be updated
  • remove any of the possible labels from the set Type_PI1 through Type_PI5
  • only add back in the ones currently in the parent

[Daniel Lee]

Yet again, thanks for your advice @Bill Sheboy 

The near real time is the desire but not a strict requirement. I'm sure the program would be ok with there being a delay in favour of a reliable solution. 

With regards to the workaround you proposed, do you have an idea of the automation steps and fields.

I have had some success with the 'Add' but not the 'Remove'. (see image below)
Do you see these as being two separate rules?

[Bill Sheboy]

Well done making progress solving this one!

When updating the work item, I recommend first performing the label deletions, re-fetching, and then adding the correct ones.  This prevents racetrack timing problems / collisions in the updates.  For example:

• action: edit work item, to remove any matching / old labels
• action: re-fetch work item data
• action: edit work item, to add the new labels to sync to the parent

For the deletion, your regular expression is missing the group parentheses, so perhaps try this:

{{issue.labels.match("^(Horizon_PI[0-9]+)")}}