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:50Clone issue 03/04/2025, 10:23:50Failed to fetch fields for project/issuetype - 10574/10643 Any help will be much appreciated. Kind regards Martyn

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

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; } } }

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

Martyn Sheriff

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

Accepted answers

Trudy P Claspill

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.

Bill Sheboy

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

All comments

Trudy P Claspill

Hello @Martyn Sheriff

Welcome to the Atlassian community.

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

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

Martyn Sheriff

Hi Trudy, Thank you.

The Issue Type option is set to Same issue type.

Both projects are Team-managed software type projects.

Screenshot (83).png

Screenshot (85).png

Screenshot (84).png

Screenshot (86).png

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

Bill Sheboy

Hi @Martyn Sheriff

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

Trudy P 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 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

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

clone

automation

jira-automation