Feature Request: Allow bulk conversion of issue types (Task → Sub-task) and parent reassignment via

[Manuel Walker]

Feature Request: Allow bulk conversion of issue types (Task → Sub-task) and parent reassignment via REST API

Summary:
It is currently not possible to programmatically convert a Task to a Sub-task and assign it a parent via the Jira REST API or automation tools. This operation is only partially supported in the UI (one issue at a time) and completely unsupported in bulk.

Use Case:
When structuring a project hierarchy (Epic → Task → Sub-task), users need to reorganize existing Tasks as Sub-tasks under another Task. For example:

Epic: EVD-611 "xxx" └── Task: EVD-205 "xxx" ├── Sub-task: EVD-200 "xxx" ├── Sub-task: EVD-201 "xxx" ├── Sub-task: EVD-202 "xxx" ├── Sub-task: EVD-203 "xxx" └── Sub-task: EVD-204 "xxx"

Current Limitation:

• The PUT /rest/api/3/issue/{issueKey} endpoint does not reliably support changing issuetype from Task to Sub-task while simultaneously setting a parent.

• Bulk operations via the API fail silently or reject the request.

• Users are forced to manually convert each issue one by one in the UI.

Requested Improvement:

1. Allow issue type conversion (Task ↔ Sub-task) via the REST API in a single update call

2. Support bulk conversion of multiple issues in one operation

3. Expose this capability to automation tools (Rovo, Automation for Jira, etc.)

Impact:
Project managers and engineers structuring work breakdown hierarchies are blocked from efficiently reorganizing their backlogs. This is especially painful in manufacturing/engineering projects with deep hierarchies.

[Gabriela - LeanZero]

Hi @Manuel Walker, the bulk move endpoint does this today. The reason it looks missing is that the target parent is not a field in the body at all. It sits in the mapping key.

POST /rest/api/3/bulk/issues/move. The reference gives that key as <project ID or key>,<issueType ID>,<parent ID or key>, and says the parent slot is "Only required when the destination issueType is a subtask". So your five go in one call:

{
  "sendBulkNotification": false,
  "targetToSourcesMapping": {
    "EVD,<subtask-type-id>,EVD-205": {
      "inferClassificationDefaults": true,
      "inferFieldDefaults": true,
      "inferStatusDefaults": true,
      "inferSubtaskTypeDefault": true,
      "issueIdsOrKeys": ["EVD-200","EVD-201","EVD-202","EVD-203","EVD-204"]
    }
  }
}

The middle slot is the numeric work type ID rather than the name, and GET /rest/api/3/issuetype/project?projectId= gives you the sub-task one for EVD.

You get a 201 with a taskId, then poll GET /rest/api/3/bulk/queue/{taskId}. Status can land on FAILED or DEAD as well as COMPLETE, and the same response carries invalidOrInaccessibleIssueCount and failedAccessibleIssues, which is where anything that quietly dropped shows up. I ran this today on a Cloud site, one company-managed project and one team-managed, two Tasks in each, and both finished COMPLETE with the Tasks reading back as Sub-tasks of the parent. One target parent per call though. I tried two mapping keys with two different parents in a single payload and it came back 400, "You can only move issues to a single target project, issue type, and parent issue", so a deep tree is one call per parent. Permissions are the global Make bulk changes, plus Move in the source project and Create in the destination.

The single-issue edit genuinely won't cross that boundary, and that part is by design. Atlassian tightened the validation in August 2022 on JRACLOUD-68207: "The REST API fails if one of the source and target issue type is subtask, but the other one is not." JRACLOUD-27893 is still open for the single-issue version of what you want.

The UI isn't one at a time either. Bulk Change, then the Move work items operation, handles work type changes inside the same project, and picking a sub-task type there makes it ask you for the parent.

[Marc -Devoteam-]

Hi @Manuel Walker 

There is already an open feature request fro this, see JRACLOUD-27893 

Note, You could also use the Feedback button within Jira under the Help button (near your avatar in the upper right corner) to provide that suggestion directly to Atlassian.

Feature or feedback on the public forum is not recognised and will mostly drop away silently.

This forum is public and for users this is not a main support channel.