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