Automation: Cloning a Service Project Ticket into a Software Project
Asked by Jeremy Snyder:

Hello! Question for the group.

I have set up a "Raise a Request" as a part of a Jira service project, and am trying to get an automation that clones the request, and sends it as a task to my backlog as a Software Project. Both are Team Managed Projects

My issue is that in the Service Project, I have a bunch of custom fields that as a part of the request, and I cannot get them to appear (or populate) in the cloned tickets (Service Management). The ticket IS appearing in the backlog, but not with any of the fields or data that I need.

In my automation I currently I have 1. "When the Issue is Created" 2. "Then Clone issue into" and have all the custom fields "Copy from trigger"

Let me know if you have a solution!


Answers:
author: Trudy Claspill
body: Hello [@Jeremy Snyder](/t5/user/viewprofilepage/user-id/5580140)

Welcome to the Atlassian community.

With Team Managed projects there are two types of Custom Fields that you might have:

1. Custom fields that were defined Globally for Jira, which you are reusing in your Team Managed project.
2. Custom fields that you **created** within the Team Managed project.

The problem you are having is probably related to #2.

Custom fields that you create within a Team Managed project are unique to that one project and get a unique field ID in the Jira database.

If you create a field with the exact same name in another Team Managed project that will be considered an entirely different field and get its own unique identifier in the Jira database.

In your Automation Clone Action you might have something that looks like this:

![Screenshot 2024-08-29 at 4.24.42?PM.png](https://community.atlassian.com/t5/image/serverpage/image-id/344688i78A5B23C4367D1AE/image-size/large?v=v2&px=999 "Screenshot 2024-08-29 at 4.24.42?PM.png")

The "Custom Short Text" field in the destination project is an entirely separate and unique field from the "Custom Short Text" field of the source project, even though they have the same name.

The Automation rule can get "confused" about where to find the data and where to deposit the data.

The way to ensure the right data is being copied from the correct field and into the correct field is to use the Advanced Editing with JSON (**More options**) feature.

<https://support.atlassian.com/cloud-automation/docs/advanced-field-editing-using-json/>

With that you can explicitly identify the destination fields with their custom field IDs rather than their names, and you can explicitly identify the correct source fields with their custom field IDs also.

You will have to identify the custom field IDs for the fields of concern. Information on how to do that is located here:

<https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/>

Look over the documentation, take a moment to digest that information, and let us know if you have additional questions.

comments: author: Jeremy Snyder
body: [@Trudy Claspill](/t5/user/viewprofilepage/user-id/3569011) Thank you for your detailed reply. You are correct, my issue was #2, custom fields I created in a project.

I have used /rest/api/2/issue/\<issuename\>?expand=names to see all the custom fields, and input them into the automation, but I am getting **"Unknown fields set during clone, they may be unavailable for the project/type. Check your custom field configuration. Fields ignored "**

I am assuming this is because these fields only exist in the service project, where I created them, and not in the software project. Is there a way around this? And thank you for your help.


author: Trudy Claspill
body: Team Managed project custom fields can't be shared.

The way to ensure the right data is being copied from the correct field and into the correct field is to use the Advanced Editing with JSON (**More options**) feature.

<https://support.atlassian.com/cloud-automation/docs/advanced-field-editing-using-json/>

The only other alternative is for the custom fields to be recreated as Global custom fields that can be used by both Company and Team Managed projects. You would then add those Global fields to both projects. In the Service project you would have to move all the data from the current project-specific fields into the Global fields. You would probably have to make other changes to filters and forms and request types to accommodate that change.

If the Team Managed projects use Global custom fields then the data can be copied directly as I showed in the image in my previous reply.


author: Luka Hummel - codefortynine
body: Hello [@Jeremy Snyder](/t5/user/viewprofilepage/user-id/5580140) and welcome to the community!

If you're looking for a reliable way to clone Jira Service Management tickets into a Jira Software project with all custom fields intact, you might want to explore our app [Deep Clone for Jira](https://marketplace.atlassian.com/apps/1218652?utm_source=atlassian&utm_medium=referral&utm_campaign=deepj-new-reach-com-2798867). It allows you to clone issues with all details, including custom fields, across different projects. The app is designed to handle complex cloning scenarios, which might resolve the issues you're facing with custom fields not populating correctly.


author: Clara Belin-Brosseau
body: Hello [@Jeremy Snyder](/t5/user/viewprofilepage/user-id/5580140)

If you're seeking for an easier way to **clone an issue from JSM to Jira Software** , you can try our app [Elements Copy \& Sync](https://marketplace.atlassian.com/apps/1211111/elements-copy-sync-clone-jira-issues?tab=overview&hosting=cloud?&utm_source=community&utm_medium=answer&utm_campaign=question_2798867&utm_keyword=CS&utm_vendorID=4952) that allows you to clone and sync a full hierarchy of issues with all their content (summary, description, custom fields, comments, attachments, etc).

You can check our guide [here](https://app.arcade.software/share/NipA2YNWK9p0lteHxiiC?ref=share-link?&utm_source=community&utm_medium=answer&utm_campaign=question_2798867&utm_keyword=CS&utm_vendorID=4952).

The app is for **free during 30 days** (and it stays free under 10 users).


Tags: cloud

jira-service-management

jira-service-management-cloud