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
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
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
Thanks so much, Bill! Switching that on worked perfectly.
And to answer your question, short version is I'm new at this and not entirely sure what I'm doing, lol. My company is new to using JIRA to this extent and we have a lot of metadata that needs to be attached to different workflows. I figured this was the easiest way to go about it when something changes, but will take your advice if it'll be less problematic down the line to have a separate rule for each field.
Thanks again,
Bryan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Awesome; I am glad to learn that helped!
Regarding the number of rules and the field copying...
For some, having fewer rules and including more fields is preferred...even it it makes it harder to check what happened (in the logs) and increases the risk of errors. For others, having a rule for each field (or groups of related fields) is better for granularity.
Either approach will lead to the same number of rule executions, and so if you are indeed on a Free license level of Jira, the difference does not matter: https://support.atlassian.com/cloud-automation/docs/how-is-my-usage-calculated/#What-are-my-usage-limits
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.