Automatition: How to link 2 child issues of the same epic, if one one is a trigger issue.

[Alexey]

Hello,

It seems that due to limitations in how automation handles variables and the inability to manage dual branching (such as combining relation + if/else), I struggled to implement what should have been a relatively simple automation.

Background

The initial design was to have a manual rule that would create several tasks from an epic and then link them together. This worked well as a single-threaded automation, using a variable to store the previously created KEY_ID and then utilizing that {{key_id}} in the linked issue block.

Things became more complicated when the team decided to utilize the 'input' feature for manual triggers, including checkboxes, as some tasks are optional. Since automation filters act as 'gates,' my script was interrupted whenever someone chose not to create a 'Design' (or any other) task.

To address this, I attempted to use branches with IF/else conditions, where I checked each user input and then proceeded with task creation (or skipped it). However, I encountered a problem with using Variables because they can't be passed from one branch to another or to the 'master' branch.

I decided to create custom fields to serve as persistent storage for issue IDs and then used {{smart.values}} during the linking stage. Unfortunately, this approach became messy and unreliable because all branches execute in parallel rather than in sequence, as the UI might suggest. As a result, sometimes a new issue was created faster than the previous task could store the value in the custom field, leading to failed links or even errors due to missing values.

Since there is no built-in delay function, I tried strategically placing re-fetches without success. I also added dummy actions and filters to slow down some branches so they would execute only after the previous step was completed and the data had populated into 'storage'. Yet, the results remained unreliable.

Finally, I decided to create two separate automations:

• One to create a group of tasks.
• Another to link them together using the logic shown in the image below.

And now I'm stuck even on this seemingly simple automation!

If I set the trigger issue as the Epic itself and then use the 'for children relation' branch, I'm unable to utilize IF-ELSE conditions to process each task one by one, check its presence, and then create a link.

If I set the trigger issue as one of the child tasks, it seems I can't retrieve a list of its siblings. Moreover, if I use the 'for parent' branch to go one level up, I can't then target the siblings.

I've tried using JQL filtering, such as:

summary ~ "[BE]" AND parent = "{{triggerIssue.key}}" (or triggerIssue.parent.key for case then i attempted to use a simple task as trigger)

In the preview, this returns '1' result, but when I run the rule, it always finds nothing. Is this a bug?

Anyway, I'm open to more ideas!

[cash career path]

It sounds like you encountered significant challenges due to the limitations of automation handling variables and branching logic, especially with the need to store and pass values between branches. The struggle with parallel execution and the inability to synchronize task creation with data storage is a common pain point when dealing with complex automation workflows. Your solution to split the process into two separate automations — one for task creation and another for linking — seems like a practical workaround, though it would be ideal if the system provided more robust handling of variables across branches. Hopefully, future updates can address these issues to make the process smoother. Thanks for sharing your detailed experience!

[Bill Sheboy]

Hi @Alexey 

Are all of the tasks created at one time in a single rule?

If so, you could still perform the linking in that rule using this approach:

• As each issue is created, save a variable with its key.  e.g., varBEKey, varDesignKey, varMOBKey
• Then use branch on JQL to access the issues and add the links needed.  As the keys are already stored, any branch parallel processing should not be relevant.
  • FYI, I have recently observed that branch on JQL with one-and-only-one issue, such as key=TEST-123, now runs sequentially (i.e., inline to the rule steps) rather than in parallel.  Although I wouldn't rely upon that as it appears to be undocumented behavior.
• This will lead to a rule with about 15-20 steps, given what you have described

Kind regards,
Bill

[Alexey]

@Hey @Bill Sheboy Thanks for help!

After brief test (with a single linking) i managed to get desired result! My assumption about 'variable belongs to the branch' was wrong! Due to parallelness my breakpoints were unable to catch the value, but your method with JQL 'stop' seems works. 



So now I can create 5-6 issues for each work type via IFs based on user input, and then check each children with a JQL stopper and link them as team wanted. 


 

[Bill Sheboy]

Awesome; I am glad to learn that helped!

The "trick" to make variables retain values for conditions and single-issue branching is to define them before the condition / branch, and then replace (i.e., shadow) them inside.  This method does not work for branches which could be on more-than-one-issue.

For example:

• trigger: some trigger
• action: create a variable named varData with a value of NULL
• branch: on parent
  • action: create the variable named varData again, with your needed value
  • ...
• some other action after the branch, referencing {{varData}}, where it will have the updated value