It is possible to create a complex Jira Automation with a single rule?

[Giurgola Diego]

Hello all, I need to create a Jira Automation rule that allows me to create this workflow:

1- in project1, create task1
2- in project2, create task2
3- in project3, create story1 which is blocked by task2
4- in project3, create 3 subtasks in story1
5- in project4, create story2 which is blocked by story1

it is doable via Jira Automation?
Also, it is possibile to open each task/story in this chain only when its blocking item is closed?
Thanks for your time?

[Gabriela]

Yes to the creation part, and it fits in one rule. Add a Create work item action for each issue — task1 in project1, task2 in project2, story1 in project3, the three subtasks under story1, story2 in project4. The one gotcha: {{createdIssue}} points at the LAST thing you created, so right after each Create, add a Create variable step to stash that issue's key (e.g. task2Key = {{createdIssue.key}}). Then use those variables downstream — a Link work items action to set story1 "is blocked by" {{task2Key}} and story2 "is blocked by" {{story1Key}}, and set each subtask's parent to {{story1Key}}. One rule, manually triggered, builds the whole chain.

The "open each item only once its blocker is closed" part is a separate job — the blocks link is only a marker, it doesn't gate status by itself. Handle that with a second rule: trigger = work item transitioned to Done, then branch to the issues it blocks and transition those from a Blocked/Waiting status into To Do. Give the dependent items a starting status like Blocked so there's something to move them out of when the blocker closes.

So: one rule to build the chain, and a companion transition rule keyed off the blocks links for the sequential unblocking.

[Giurgola Diego]

Hi Gabriela, thanks for your in deep answer! I tried to proceed as you have suggested, so I have a smart value after a work item is created, for example:

MONITORINGcreatedIssue = {{createdIssue.key}} (in the MONITORING project)

Now, it seems that the linking part is not working as expected, I am using the correct item? Here a screenshot (in Italian, sorry):



Also, I am sure that the smart value is working, I tried to "print" it directly into the task description, and I have the key.

What I am doing wrong? Thanks for your time!

[Gabriela]

Don't name the variable createdIssue — that clashes with the built-in {{createdIssue}} smart value, so referencing {{createdIssue}} downstream gets ambiguous. Rename it to something unique like task2Key, and reference {{task2Key}} in the link step.

The bigger thing is usually the Link work items action itself: it links whatever issue is currently in scope at that point in the rule. So the order matters — right after you create story1 (while it's the most-recently-created, in-scope issue), run Link work items → "is blocked by" → {{task2Key}}. If a later Create (the subtasks, or story2) has already run before the link step, the in-scope issue has moved on, and the link lands on the wrong item or with an empty target.

If it's still not linking, tell me what the Link work items action shows — which issue it says it's operating on, the link type, and the smart value in the target field. A screenshot of only that action is enough.

[Giurgola Diego]

Hi Gabriela, I'm providing 2 actual screenshots of what I am working on right now:



So, basically, if an Epic is created in a specific project (deleted in this image) with a specific label, I want to have a ticket created in the MONITORING project, I create the MONITORINGkey variable and I link the just-created task to the just-created Epic in the blanked project. Now, this part just works.

Here comes the second part:



after the MONITORING task + linking to the main Epic + setting MONITORINGkey, I proceed to create a Task in the BACKUP project, and I want to link it to the MONITORING task just created. This second part does not work, at the moment.

[Gabriela]

That confirms it, and it comes down to what the rule treats as the "current" issue. Your trigger is the Epic, so the Epic stays the in-scope issue for the whole rule. When you link the MONITORING task, the Link work items action is really linking the in-scope issue (the Epic) to MONITORINGkey — which is the pairing you want, so it looks like it works. When you reach the BACKUP task, the in-scope issue is still the Epic, not the BACKUP task you created a step earlier, so the second Link action tries to link the Epic again instead of BACKUP to MONITORING.

Two ways to fix the second link. The cleaner one is to link during creation: in the Create work item action for the BACKUP task, open More options / Choose fields to set, add the Linked issues field, pick the link type, and reference {{MONITORINGkey}}. That links the BACKUP task itself to the MONITORING task in the same step, with no separate Link action.

If you'd rather keep a separate Link action, add a Branch on "Most recently created work item" right after the BACKUP create — inside that branch the in-scope issue is the BACKUP task, so a Link work items action there links it to {{MONITORINGkey}} correctly.

The same applies to your first link, by the way — it lines up on its own only because the Epic you want on one end is already the in-scope issue there.