Smart values across automation

[Tim Foster]

I have an automation that creates a whole shed-load of tasks and subtasks. I had this working perfectly, until someone threw the spanner of maximum steps into the works.

So, I've split my process into 3 primary task creators that all trigger off the same event (i.e. Epic transitions to Planned). This creates my tasks nicely, and as they are created they all add a label that triggers the creation of the subtasks (so, Task A is created by triggering of the Epic with a label of auto-x, and the subtasks of Task A are created by the automation that triggers when a task is created with the label of auto-x). This all works to create the tasks etc. However, some of the tasks have a dependency on other tasks. So, Task X can't start until Task Y is complete, or Task Z can't start until subtask w is complete etc). If these are in the same automation it's fine. What I want to do though is create the dependencies in the other automations. Is this possible? If not, is it possible to wait until certain tasks are created (the ones on which the dependencies exist) and them create the dependency using a jql query?

[Mark Segall · Accepted solution]

Hi @Tim Foster - I came across a similar issue where my single automation was getting unruly and needed to split it up.  I split it like this:

1. Automation 1 triggered by whatever and at the end apply label_x
2. Automation 2 triggered by label_x and at the end clear label x and apply label_y
3. Automation 3 triggered by label_y and at the end clear label y

[Tim Foster]

That's a good approach Mark, thanks. I guess if I create the dependent task as a label I can trigger the creation of the other tasks off that label.

I am finding that automations are more limited than I'd like. Perhaps it's time for an automation object of execute automation? 

[Bill Sheboy]

Hi @Tim Foster 

What options to restructure your rule did you try that might solve this?  The 60 component limit in a rule does cause challenges, some of which can be solved with loops and advanced branching.

Kind regards,
Bill

[Tim Foster]

What I've done initially is just have three separate rules triggered from identical conditions. The rules are split by team so I have a shared rule (for tasks involving both teams) and frontend and backend rules. The frontend rule creates a task that a backend task is dependent on. I could move the dependent tasks into the other rule, but then it starts getting messy.

I already have some tasks that add a label and then rules that look for tasks with this label to create subtasks under that parent.

Maybe if I wrote jql to find the key of the task in the same epic as the current task that have label-x I could define a variable and use that, but it seems unnecessarily complicated.

I'd like to create the rule and have a branch that executes that rule so my process would be:

trigger if... then

Fire rule x

create variable abc

Fire rule y passing variable abc to rule y

Fire rule z passing the return value from firing rule y

Doable?

[Bill Sheboy]

Hi Tim,

Thanks for that info, and there is definitely no way to call a rule directly from another yet.  Instead the expectation appears to be to create the conditions in issues which lead to triggers happening...and so decentralize the work.

Use of the created variable is what I was wondering; if you have already considered and decided against that, no worries.

Thanks again,
Bill

[Tim Foster]

Hi Bill,

I haven't decided against it. I'm happy to try anything that will get me to the place I need to be.

I was thinking that I should have the last step of the first one create a task with a specific name, then have that trigger the second rule with that doing the same at the end, so we have a linear progression. This would mean I can guarantee that the dependent tasks are present when I create the dependency. So,

Trigger on transition of epic, last step creates task in this epic with summary of Placeholder xxx (where xxx is the key of the task I want to create the dependency on.

When task Placeholder xxx is created this triggers the second set of tasks (one of which is the dependent task) so read the key from the summary into a variable and create tasks under the same epic. Penultimate step deletes the placeholder xxx task. Last step of this rule creates a task with the summary of the other dependency and have this trigger step 3.

I think this will work, but it seems very clunky and not very intuitive.

[Bill Sheboy]

Yup, that should work.  Think about edge cases for timing and cleanup when testing your rules.  For example, when one of the rules does not fire due to some automation engine, timing, cloud infrastructure hiccup, etc.  Perhaps consider adding a "magic value" to the label of that flag-task, helping you find them with a JQL search later.