Setting the scope for "edit work item"

[Stefan Brandhoff]

For recurring tasks I created an epic as template, containing about 20 stories. An automation rule clones the epic and all the stories. The rule sets some properties like assignee, component, summary and priority. This works fine, but as final step I'd like to set the status of the cloned stories to BACKLOG.

Using edit work item or transition work item always the triggerIssue is affected.

What is the correct way to set the scope to createdIssue? In the actions edit and transition I can't find how to set a "target pointer".

[Arkadiusz Wroblewski]

Hello @Stefan Brandhoff 

In Jira automation, Edit work item and Transition work item always run against the current rule context. Inside your Children branch, that context is the current child issue. The Clone work item action does not switch the context to the new clone automatically. Atlassian’s automation docs are pretty explicit on that: when you create or clone work items, any follow-up actions need a related-item branch for the created items, because the rule otherwise still acts on the original/current item.

Jira automation branches | Cloud automation Cloud | Atlassian Support

In your current rule shape, the Edit and Transition actions below Clone work item will still hit the original child, not the cloned one.

The other important detail is that Atlassian also documents that branches cannot be nested. So once you are already inside the Children branch, you cannot just add another branch there for All created work items.

Branch automation rules to perform actions on related work items | Cloud automation Cloud | Atlassian Support

Because of that, I would change the design:

- Either use a second rule that runs on the newly created clones and moves them to Backlog

- Redesign the rule so you can act on the most recently created item outside that nested situation

[Stefan Brandhoff]

Thanks for the quick answer.
In general I understand your explaination, but it doesn't solve the problem.

Working with two rules, one for creating and one for setting the status is my current workaround.

With your second aproach "Redesign the rule so you can act on the most recently created item outside that nested situation" I need a hint how this should look like.

[Stefan Brandhoff]

According to AI like Rovo and ChatGPT the old "edit issue" was able to work with such a pointer but in "edit work item" this feature was removed. I don't know if that is true, but I hope Atlassian provides a solution. The workaround with two rules works in my case an it might be acceptable. I guess there are may cases where this doesn't work.

[Arkadiusz Wroblewski]

@Stefan Brandhoff 

In your case I would stay with the two-rule workaround.

The problem is not really Edit issue vs Edit work item. The main limitation is that automation actions always run in the current context, and Atlassian also documents that branches cannot be nested. So once you clone child items inside the Children branch, there is no clean native pointer for “now edit/transition exactly that new clone” in the same rule. 

I cannot confirm the AI claims, but from the current docs I do not see a better native single-rule design for your case either. I tried to Reproduce it but without luck.

Honestly your current two-rule solution looks like the safer approach here.

I Suppose when "AI Boom" will be done, these things will be developed faster.

[Stefan Brandhoff]

Ok, I'll stay with my two-rule solution.
Thanks a lot for your help.

[Arkadiusz Wroblewski]

@Stefan Brandhoff 

You´re Welcome.