nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira Automation for transitioning a work item in other space

Niklas Malmberg

I have two projects / spaces, one a Service desk type (called ISSD), one a Software project (called SAT). I have the same issue type [System] Service request existing on both projects.

Since we're not allowed to work in ISSD ourselves, we want to clone the issues there into our working space SAT, and process it there. Once completed in out working space we would like to close it to DONE.
What I'm now trying to accomplish is to automate a transition of the original ticket in the original space, also set that to DONE.

We have already fixed the cloning (in an automation in ISSD space, that works), and in the SAT item that was created we have saved a reference to original ticket in a 'Action item from' Linked work item field.
So I believe I have the information available, it's just a matter of creating automations

My automation now looks like this:

Questions:
* When issue (ex. SAT-1234) of the right issuetype is transitioned to DONE, what action to use to transition the linked issue (ex. ISSD-2071) in the space ISSD to DONE too?
(common 'Transition work item' action does not look to be able to specify another space as context).

* How to access Linked Work item data (=reference to original work item) in an issue in automations?

* Now I'm attempting to create this new flow in SAT space.
Do I need to move it to a global automation space?

Accepted answers

Tansu Akdeniz

Hi @Niklas Malmberg

1- You can use branch step to connect to the linked items.

2- If you need to edit an item in linked issue, you can either directly edit the value or copy the value from original trigger issue.

3-You should include the projects to the rule scope which can be configured in global automation page.

James Gamble

Hola Niklas,

You’ve already got the important part in place: the SAT work item has a real work-item link back to the original ISSD request. You don’t need to extract the key into a variable or call the REST API for this.

The native Automation pattern is Work item transitioned > Branch rule / related work items > Linked work items > Transition work item.

Atlassian documents essentially this exact pattern for transitioning linked work items. In your case, I’d configure the rule to trigger when the SAT work item is transitioned to DONE. From there, add a condition confirming the work type is [System] Service request, then use Branch rule / related work items > Linked work items to move the automation context onto the linked ISSD work item.

For the link type, select the relationship you’re already using for “Action item from.” Pay attention to the direction shown in the branch selector so that you’re following the link from SAT back to the original ISSD item, rather than the opposite direction.

Inside that branch, I’d add a condition to make sure you only touch the original request, for example: Space key = ISSD Then add: Transition work item > DONE

Once you’re inside the Linked work items branch, the context changes to the linked ISSD work item. That’s why the normal Transition work item action is enough. You don’t specify ISSD in the Transition action itself. Atlassian explains how branching changes the work-item context here.

The part you do need to change is the rule scope. Because SAT and ISSD are different spaces, a rule scoped only to SAT can’t execute actions against the ISSD item. Atlassian explicitly states that automation involving items in another project/space must be a multi-project or global rule.

You don’t necessarily need to make it global. I’d scope it to just SAT and ISSD if those are the only two spaces involved. In the rule’s Flow details, change Scope to Multiple projects/spaces and select SAT and ISSD.

One other thing to check is the rule actor. The actor needs permission to browse and transition the ISSD work item, and the ISSD workflow must allow that transition from whatever status the original request is currently in. If the branch finds the linked request but the transition fails, the Automation audit log will usually indicate whether the failure was due to a permission or workflow condition.

Atlassian has a good troubleshooting guide for failed Automation transitions here.

Thanks,

James

Marc -Devoteam-

Hi @Niklas Malmberg

@James Gamble is correct on making the rule scoped to both spaces, this can only be don in global automaton, by a Jira admnistrator.

But most important and essential is the actor of the rule, this actor needs to have a JSM License (be agent in the JSP space) and have the relevant permissions to be ble ot achieve this.

Also keep in mind that the status the work item (in the JSM space) can transition to the status Done from it's current status.

All comments

Tansu Akdeniz

Hi @Niklas Malmberg

1- You can use branch step to connect to the linked items.

2- If you need to edit an item in linked issue, you can either directly edit the value or copy the value from original trigger issue.

3-You should include the projects to the rule scope which can be configured in global automation page.

James Gamble

Hola Niklas,

The native Automation pattern is Work item transitioned > Branch rule / related work items > Linked work items > Transition work item.

Inside that branch, I’d add a condition to make sure you only touch the original request, for example: Space key = ISSD Then add: Transition work item > DONE

Atlassian has a good troubleshooting guide for failed Automation transitions here.

Thanks,

James

Niklas Malmberg

Branch rule and change of rule scope, that was what was missing for me!
Now it works like a charm.
Fabulous explanation too, many many thanks James !

Niklas Malmberg

I'm pretty sure your explanation is spot on, but since it was a little condensed I tried to follow James first, posted 5 minutes later. I think they are very similar in the proposed solutions, and indeed these were the two areas I needed to use to fix my automation.
Thank you Tansu !

Marc -Devoteam-

duplicate

Marc -Devoteam-

Hi @Niklas Malmberg

@James Gamble is correct on making the rule scoped to both spaces, this can only be don in global automaton, by a Jira admnistrator.

But most important and essential is the actor of the rule, this actor needs to have a JSM License (be agent in the JSP space) and have the relevant permissions to be ble ot achieve this.

Also keep in mind that the status the work item (in the JSM space) can transition to the status Done from it's current status.

Marc -Devoteam-

Niklas Malmberg

Thank you for making these details clear, @Marc -Devoteam-.

Indeed, I stumbled upon the issue of the tickets in JSM and JSW having slightly different workflows and possible transitions, had to tweak my rules a little to accommodate that.

Josh

A native approach is to let the rule run in the project where the event occurs, then use Create work item with the target project and issue type, followed by Link work items (or Clone if you need a copy). Store the created issue key in an automation variable and use a second rule in the target project if its workflow needs to advance. Cross-project transitions require the rule actor to have Browse, Edit and Transition Issues in the target project, and the target workflow must expose a valid transition for that issue type. Check the audit log for permission or workflow-validator failures before adding more branches.

Welcome!

It looks like you're new here. Sign in or register to get started.