Link all issues in one project into another project using automation, with dynamic updating.

[Martyn Sheriff]

Hi

I have read many posts on similar subjects but cannot find the solution to my situation.

I have 2 Projects (Project 1 and Project 2)

Both projects are based on the Kanban template.

Issue types

• Epic
• Story
• Bug
• Task
• Sub-task

Workflow

• To Do
• In Progress
• Done

Objectives:

• When I create a new Epic, Story, Bug, Task, or Sub-task in Project 1, it is automatically created in Project 2 with the same Issue Type and Workflow status.
• In Project 1, for any information added or edited from within any issue, the copied version in Project 2 is updated automatically,
• The workflow is managed in Project 1 only; however, any change in the status in Project 1 will also change the status in Project 2.
• Project 2 is almost a read-only copy of Project 1, with one single requirement: the ability to add comments and attachments.

What we have tried so far:

In Project 1 - Created an Automation.

• When: Issue created (the rule is run when an issue is created).
• Then: Clone Issue into Project 2.
• Actor = Automation for JIRA

Result when triggered (An Issue is added)

Some Errors entry in the audit log-

Issue created 03/04/2025, 10:23:50

Clone issue 03/04/2025, 10:23:50

Failed to fetch fields for project/issue

type - 10574/10643

Any help will be much appreciated.

Kind regards

Martyn

[Trudy Claspill · Accepted solution]

Hello @Martyn Sheriff 

Welcome to the Atlassian community.

In the Clone action for the Issue Type option did you choose Same issue type?

What are the project types of the two projects? To get that information go to the View All Projects page under the Projects menu. Find each project in the list. What is the information in the Type column for each project.

Can you please provide and image showing the complete automation rule?

And can you please provide an image showing all the details in the Audit Log for when the rule ran? Make sure you show all details by clicking all the ">" characters that display along the right edge of the log.

[Martyn Sheriff]

Hi Trudy, Thank you. :)

The Issue Type option is set to Same issue type.

Both projects are Team-managed software type projects.

If you need anything else, please don't hesitate to ask.

Many thanks

Martyn

[Martyn Sheriff]

BTW I do understand that I will need to add more rules, but I just though I would walk first before I run :)

[Trudy Claspill]

The issue is caused because of your use of Team Managed projects.

With issue types, status values and custom fields, each of those elements has a human readable "name" that you see and a numeric id that you don't see. The numeric id is unique for that element across the Jira instance.

With Team Managed projects the configuration information for the project is project-specific. While you may have identically named issue types, status values, and custom fields in the two projects, each of those has its own unique, project-specific numeric id.

The trigger issue from Project 1 may be named "Story", and you may want to create a "Story" in Project 2, but the "Story" issue type from Project 1 does not exist in Project 2. Those two issue types have different numeric ids in the backend.

When you say that you want to create "Same issue type" in your automation, the backend is trying to find an issue type in the destination project where the issue type numeric id is the same as in the source project. And it can't find that because the numeric id is different for the same-named issue type in the destination project.

You will have to explicitly select the issue type rather than using Same issue type.

You can either create a rule for each issue type, or you can use an IF/ELSE block to check the type of the trigger issue and then use a Clone Issue action that selects the corresponding type in the destination project.

You may run into additional problems copying data between custom fields in these issues if those custom fields are specific to each TM project, and you may run into additional problems trying to transition the linked issues.

[Martyn Sheriff]

Hi Trudy

Great advice!

I shall revise my approach and get back to you with the results.

Many thanks

Martyn

[Martyn Sheriff]

Hi Trudi

I have created two identical company-managed projects, and the basic automation of cloning new issues to another project does work.

I now need to know how these cloned issues can be updated by information entered in the original issue and how to make the cloned issues a read-only copy.

Many thanks

Martyn

[Trudy Claspill]

Hello @Martyn Sheriff 

To make the work items in Project 2 read only you need to apply a Permission Scheme to it where no user, project role, or user group is granted any of the permissions that would allow the work item to be updated.

You will want to ensure that one group - atlassian-addons-project-access - is granted all the permissions. They for your rules set the Actor to Automation for Jira. That built-in user is a member of the above project role and will need all the permissions in Project 2.

You may also want to grant permissions to the Administrator role, if you trust the members of that role not to update the work item except when it is absolutely necessary.

You mentioned that you wanted to be able to add comments and attachments to issues in Project 2. There are permissions for those two items in the Permission Scheme. Allocate those to the appropriate users individually, or user group(s), or make a project role to which those users can be added and grant the permission to the project role.

You will want a custom Permission Scheme for this one project; not a Permission Scheme that is shared with Project 1.

For more information on managing Permissions for Company Managed projects, refer to

https://support.atlassian.com/jira-cloud-administration/docs/manage-project-permissions/

With regard to using Automation to copy every change from the Project 1 work item to the Project 2 work item, that can become a bit complex. 

You can use the Work Item Updated trigger to catch most field changes. You would then need to Branch to the linked work item. You would then need to Edit the work item in the branch, copying values from the Trigger work item.

I recommend in your Edit action to select as many of the fields as you can from what is available in the Choose fields to set list. Not all fields will be available there, and there may be some that you don't actually want to copy, like Parent. 

You can then use the COPY option next to each field...

...to copy the data from the same field in the Trigger work item.

For fields that are not available from the list you will have to use the Advanced Editing with JSON feature.

I would recommend separate rules for synchronizing the transitions and comments, using the Work Item Transitioned and Work Item Commented triggers respectfully.

You would use the same branching, but then use the Transition Work Item and Comment Work Item actions, respectively.

[Martyn Sheriff]

Hi Trudi

Thank you so much for all of this advice. I honestly do appreciate it.

I shall get on with this today

Kind regards

Martyn

[Martyn Sheriff]

Hi Trudi

I have realised that it is more complicated than I have explained.

Project 2 is not completely read-only. Issues are created within it (that all users can add/edit), and issues cloned from Project 1 (are to be read-only).

I am currently ensuring that both projects are set up identically to prevent misalignments later on.

Kind regards

Martyn

[Trudy Claspill]

Hello Martyn,

Looking at this response you provided to Bill:

We have a main projects board (Project 2) that covers all our tasks relating to our digital development. This project has many in-house users. I am trying to assess the possibility of creating a project run by a third-party developer (Project 1) who will manage all of his tasks in a project. The in-house team wants to see his plans for their main project. He can select the issues he wants to report on without bombarding the main project with unreportable issues.

Why do you feel that you need to clone the work items?

Can you not just allow the users of Project 2 read only access to Project 1?

If you want to see work items from both projects on one agile board, you can create a filter that selects the relevant work items from both projects, save the filter, then create a board based on that filter.

If you want the Project 2 users to be able to see only a subset of work items in Project 1, then you would need to implement Work Item Security in Project 1.

https://support.atlassian.com/jira-cloud-administration/docs/configure-issue-security-schemes/

Using a Work Item Security Scheme configured appropriately and applied to Project 1, a Security Level could be set on the work items that need to remain private to the third party developer to limit the visibility of those specific issues.

This path is significantly less complicated than cloning issues and then needing to keep the clone and original synchronized.

Additionally there are limits on how many Automation Rule executions you can have per month.

https://support.atlassian.com/cloud-automation/docs/how-is-my-usage-calculated/

Depending on how many rules and how many changes are occurring, plus the other Automation Rules executing in your instance, you could hit your limit. If you do, no other Automation Rules would be able to execute for the remainder of the month.

[Martyn Sheriff]

Hi Trudy 

I think you are right! :)

As an alternative, why have two projects? Why have one project with six boards?

Project X with six boards: [Backlog], [In Progress], [Done], [To Do], [In Development], and [Completed].

• The Project Team have full access to [Backlog], [In Progress], [Done], and read-only access to [To Do], [In Development], and [Completed].
• Third-party users have full access to [To Do], [In Development], and [Completed].
• Third-Party Users have no visibility to [Backlog], [In Progress], and [Done].
• Admin Users have full access to [Backlog], [In Progress], [Done], [To Do], [In Development], and [Completed].

Many thanks

Martyn

[Bill Sheboy · Accepted solution]

Hi @Martyn Sheriff 

I am curious: what problem are you trying to solve with this scenario implementation for that degree of sync between project work items?  That is, "why do this?"  Knowing that may help the community to offer other solution approaches.

You appear to be on a Standard license level, and so the level of sync you describe would:

• require many automation rules
• cannot fully sync all possible changes (as some changes cannot trigger automation rules, or will cause multiple rule triggering)
• lead to sync errors when there are rule errors or an Atlassian outage
• likely use a significant amount of automation usage capacity just for the sync

Kind regards,
Bill

[Martyn Sheriff]

Hi Bill

Thanks for your input.

I am just trying out possible solutions.

We have a main projects board (Project 2) that covers all our tasks relating to our digital development. This project has many in-house users. I am trying to assess the possibility of creating a project run by a third-party developer (Project 1) who will manage all of his tasks in a project. The in-house team wants to see his plans for their main project. He can select the issues he wants to report on without bombarding the main project with unreportable issues.

I know I could allow him restricted access to the main board, but I want to provide him with his own space.

License issues are not a problem for us, and if I need to upgrade, so be it, but I must prove my methods first.

I hope I am making sense.

Kind regards

Martyn