Automation Rule to Update Common Field in All Sub-Tasks When Value Changes for One Sub-Task?

Bryan Fitzgerald

Hi all! I'm looking for a rule that will change a common field in all sub-tasks of a Story when that field is changed in any one of the associated sub-tasks. Here is our structure with one common custom field listed as an example:

Story1

• - Sub-task1 - Product Team
  
  • Course SKU (custom field)
• - Sub-task2 - Design Team
  • Course SKU (custom field)
• - Sub-task3 - DEV Team
  • Course SKU (custom field)
• - Sub-task4 - Delivery Team
  • Course SKU (custom field)

Let's say the Course SKU, which each team needs to know, changes for some reason at Sub-task2 when the project is with our Design Team. Currently, I have a rule that when at value is changed at the Story level, it trickles down and changes all the sub-tasks. But I've been asked to now create the inverse - a rule that, in this scenario would allow the Design Team to change the Course SKU in their sub-task, and have that automatically updated in the Story plus all its other sub-tasks.

I was able to make a rule that successfully trickles up to the Story and changes the Course SKU there:

 

I have another rule that changes common values for all sub-tasks when a value is changed at the Story level. This works great when a value is changed manually in the Story, but is not kicking in when that value is changed by the Sub-task to Story rule I screenshot above.

My thinking was that the rule above (change in single Sub-task = change in Story) would then activate the rule below (change in Story = change in all Sub-tasks) but it's not working.

Any help here or suggestions on solutions would be MUCH appreciated.

Bryan

Bill Sheboy

Hi @Bryan Fitzgerald 

By default, the actions of one rule do not trigger other rules.  This is to prevent errors and runaway recursive looping, which potentially would lead to all rules halting due to "throttling" conditions.

When you intentionally want the actions of one rule to trigger another, enable the following setting in the rule details only in the downstream rule: 

Check to allow other rule actions to trigger this rule. Only enable this if you need this rule to execute in response to another rule.

 

Looking at the rules you show, I wonder why you have a single rule triggered on changes to so many fields which then updates those same fields in the subtasks.  This will unnecessarily update the fields when no changes have happened, and potentially lead to more likely rule / update errors due to timing problems.  It may be safer to have individual rules for each field.

 

Kind regards,
Bill