Work Item Linking Between Projects

[Luke Jackson]

Hi there,

We have a couple of different projects under one JSM instance, there is a requirement for work items in one project to sometimes be copied and linked to a new item in another project, similar to the below:

User logs request > Agent determines this is for the other project > Sends to other project > Existing item remains in original project > New Item created in other project and linked to original.

I can see this is a feature for "Link Work Item" then "Create Linked Work Item" and I can then select a project and request type to assign it to, it then shows in the work item view but I have a couple of queries around this process.

1. Can this be linked to a Jira Automation? So an agent has a one click button that does the process for them?
2. Does the agent need access to both projects to see details in the linked work item?
3. Can an automation be created to allow a comment to be added to both work items?

[Jayesh Raghuvanshi]

@Luke Jackson 

That is an excellent use case for Jira Automation. You are correct that the native "Create Linked Work Item" feature is a good starting point, but a single-click automation rule will significantly streamline the agent's workflow.

Here are the answers to your queries regarding the process you described.

1. Can this be linked to a Jira Automation?
Yes, absolutely. You can create an automation rule that performs the entire "copy and link" process with a single click by using a Manual Trigger (a button on the issue screen).

Automation Rule Steps:
Trigger: Manual trigger (Allowing the agent to select it from the … menu). You can set conditions to limit its visibility to only the agent's project or specific issue types.

Action 1: Create Issue

Set the Project to the target project.

Set the Issue Type to the appropriate request type.

Copy Fields: Use the "Copy from the trigger issue" option or Smart Values ({{issue.summary}}, {{issue.description}}, etc.) to map all relevant data from the original ticket to the new one.

Action 2: Link Issues

In the same "Create Issue" action (Action 1), you can configure the Linked Issues field.

Set the link type (e.g., "relates to," "is blocked by") and the target issue key, which should be the key of the issue that triggered the rule (the original issue). You can use the Smart Value: {{triggerIssue.key}}.

This combined action creates the new ticket in the other project and instantly links it back to the original, achieving your one-click workflow.

2. Does the agent need access to both projects?
Yes, for viewing all details of the linked item, the agent needs the appropriate permissions in both projects.

To create the linked issue (via the manual action or automation): The agent needs Browse Projects and Create Issues permission in the target project.

To see the linked ticket's key and summary: They only need the Browse Projects permission for the linked project.

To see the linked ticket's full details (description, attachments, comments, etc.): The agent must have the Browse Projects permission in the linked project's permission scheme. Without this, the linked issue panel will only display basic information, or potentially an "Access Denied" message if they try to click through.

3. Can an automation be created to allow a comment to be added to both work items?
Yes, you can create a second, separate automation rule to synchronize comments between the two linked issues.

This is a two-way synchronization, meaning you'll need two global or multi-project rules (one for each direction).

Comment Sync Automation Rule (Example: Project A to Project B)
Scope: Global or Multiple Projects (selecting both Project A and Project B).

Trigger: Issue commented (set to run on issues in Project A).

Condition: Issue fields condition where Comment Visibility is set to Internal (or whichever visibility you want to sync).

Branch: Branch rule / related issues

Select Linked issues (specifying your linking type, e.g., "relates to").

Add a condition to this branch to only proceed if the linked issue's Project Key is Project B.

Action: Comment on issue

Use the Smart Value {{comment.body}} to pull the text from the original comment.

Crucially, you should set the Comment Visibility to Internal comment in the target issue so that customers in Project B do not see internal chat from Project A agents.

You would then create an identical rule for the reverse direction (Project B to Project A).

This synchronizes the content of the comment. Note that if you want to include attachments from a comment, this requires an extra step in the automation rule to copy the attachments as well, due to how Jira handles file links.

[Valerie Knapp]

Hi @Luke Jackson , welcome to the Atlassian Community and thanks for your post.

I like to recommend for automations that people take a look at the Automation Library that is provided by Atlassian to get ideas for how to approach these cases.

For example, I think this could be a good rule to use as a basis https://www.atlassian.com/software/jira/automation-template-library/rules#/rule/9918982/207129029 .

I would recommend, in the beginning, that you don't have this called by a trigger of someone writing a comment because I think there is more risk of extra things getting created when people didn't mean for them to be.

In this rule, it's a manual trigger, so the agent would evaluate the ticket, decide, okay but not for this project, call the rule, which clones the ticket into the other project. Then, the agent can close the original ticket as 'won't do' or something like this. In terms of the agent's ability to see the cloned ticket, you can have a permission setting which would allow for them to be able to see the cloned ticket but if they shouldn't work on it anymore, I don't know that that is necessary. 

Please have a look at the rule and share your thoughts.

Best wishes