Resolve the Hierarchy and Project ID errors in automation when converting an issue to a subtask?

[JEROME DREW]

Hi everyone. Thank you in advance for your help! I hope the details in this lengthy post will be more helpful than cumbersome.

My goal is to allow users to convert an issue like a Bug into a subtask using automation. I am aware that there are workarounds, like copying the metadata of the bug and inputting it on the fields of a new subtask. This does not solve the challenge though as we have data connected to an issue from a plugin that does not copy over when cloning the issue, nor is that data accessible to automation.

For clarity, here's the use case:

We're using the Zephyr Scale plugin for QA. This allows you to write test scripts directly in the Jira UI, and log bugs/defects against tickets that fail testing. This ability to log issues is exactly what the automation is for.

From the plugin UI, you can see failed steps in a script:

From these failed steps, you can create an issue that is connected to the steps.

The metadata from the plugin will appear on the ticket as seen above. This is not available when you clone and cannot be copied from any fields as Jira doesn't seem to store any of the data from the plugin itself. In our workflow, these issue derived from failed testing should be subtasks on the failing issue/Story which disallow the parent issue from closing without first resolving the Defect/subtask. So, we need to be able to create subtasks from this workflow, but when you create an issue from the plugin UI, it pulls up the standard Create screen which doesn't and can't include subtasks.

This is the use case for the automation, so any workaround would also have to solve for the above case.

RE the failing automation itself, here's what the automation looks like and the errors I get.

Some notes:

• The {{userInputs.ticketid}} in the JSON is the user-entered value for the what the Parent of the subtask should be. It will be a string like "ABC-123"
• I made sure the workflows for both the initial issue (Bug) and the subtask (Defect) were the same.
• I tested this manually to make sure it works manually, and that works fine.

The error message I get is:

Manual trigger from issue04/09/2025, 19:43:15

Edit issue04/09/2025

Error editing issues

EDZN-20165 (Given parent issue does not belong to appropriate hierarchy., Issues with this Issue Type must be created in the same project as the parent. (pid))

Some notes:

• I included validation in tests to make sure that pid matches between the two issues.
• I ensured the hierarchy of the issues is in line, but of course it's Subtask and Bug/Story so that shouldn't be an issue anyway.
• I also tried a test automation where I create the subtask in one step, to make sure it is initialized as a subtask first, and then set the parent in a another step, but I get an error saying that I cannot create a subtasks without setting a parent so those two things need to happen in the same step.
• I tried re-fetch
• I also tried to explicitly use the JSON only to input the issue type and parent. See below.

{
  "fields": {
    "issuetype": {
      "id": "10076"
    },
    "parent": {
      "key": "{{userInputs.ticketid}}"
    },
    "description": "{{issue.description}}"
  }
}


This gives the same error as above

Does anyone know what could be causing these errors or how to resolve them? My theory is that the automation is trying to change the issue type and set the parent in the same call. This means that the new issue type is not set first, so effectively, the automation is trying to make a Bug issue type the Child of a Story issue type which would cause the hierarchy error, but I'm not sure if this is true or how to fix it.

[Bill Sheboy · Accepted solution]

Hi @JEROME DREW -- Welcome to the Atlassian Community!

First thing, I recommend not trying to change the type of a work item (formerly called "issue") with an automation rule.  Jira has a specific UX feature to "Move" to a new type, and that supports interaction with the person to ask / answer any necessary questions.  There is no equivalent rule action to do this.

One possible work around is to use the Send Web Request action to call the Bulk Move Issues endpoint as that is built to support changing issue types.  When doing so, additional field information may be supplied to support the move.

If you want to try this, here are some references to help:

• https://community.atlassian.com/forums/Jira-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828
• https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-bulk-operations/#api-rest-api-3-bulk-issues-move-post

This approach will also mitigate any rule scoping challenges (i.e., single versus multiple-project) as the endpoint is used directly.

Kind regards,
Bill

[JEROME DREW]

Hey Bill, thanks for the suggestion!

It worked; after many hours of painstakingly trying to figure out how exactly to use Jiras Rest APIs with automation of course. haha

For those wondering how this worked in practice, I got more errors than I can count just following the documentation, so here's exactly what I did that ended up working.

The JSON is:

{
"sendBulkNotification": true,
"targetToSourcesMapping": {
"EDZN,10076,{{userInputs.ticketid}}": {
"issueIdsOrKeys": ["{{issue.key}}"],
"inferFieldDefaults": true,
"inferStatusDefaults": true,
"inferSubtaskTypeDefault": true
}
}
}

What that will do is to:

1. Set the parent = a text value entered in by the user. Here it's smart value "{{userInputs.ticketid}}"
2. It sets the issue type you want to move to where you see "10076"
3. Everything below just tells Jira for any required fields or statuses, use a default. I recommend this because trying to update any fields in the move itself gave me a nightmare list of errors. Instead, you should use subsequent steps in the automation if you want to update field values.
   
   

NOTE: There's a parameter to include in the body of the request that you can use to list out the issues you want to move. You might be able to populate a smart variable to get a list and plug it into the body. This automation only works for a single issue.

You NEED to have an authorization header.

Follow the steps on the page listed by Bill, but when you encode your data, don't include the <> characters from the example. I made that mistake and it left me confused for hours.

Lastly, use the Validate your web request configuration UI. It will save you tons of time instead of running the automation and constantly going back to look at logs.

 fwiw I ran several errors through Deep Seek and got good solutions