A story gets refined. The team lands on the breakdown — API endpoints, the frontend form, a migration, tests, docs. Fifteen children, and now somebody has to put them into Jira.
There are five ways to do that. Search results tend to argue that four of them are wrong, which is not true. Each is the right answer to a different situation, and the situations are easy to tell apart — three questions, asked in order, and the first one that fires picks the method (Fig. 1).
Is it the same breakdown every time?
Does the list already exist as data?
How many children, and how often?
One thing to clear out of the way first, because it sends a lot of people down a dead end: Jira's bulk change tool cannot create anything. Bulk change edits, moves, transitions, deletes and watches issues that already exist. Every one of those operations needs issues to operate on. If you arrived at a bulk-change doc page looking for a way to make forty sub-tasks appear, that page was never going to help you.
Sub-task, or child?
Worth thirty seconds, because the words steer the method.
A sub-task is an issue type sitting at the bottom of Jira's hierarchy. It cannot have children of its own, it belongs to exactly one parent, and in most of the current Jira Cloud interface it is labelled a child work item rather than a sub-task.
A child is anything one level below something else. A Story under an Epic is a child. It is not a sub-task.
The distinction matters because a few of the methods below only reach sub-tasks. If what you want is eight Stories under an Epic, you are in a different — and generally easier — part of the product than someone wanting eight sub-tasks under a Story.
And before any of this: check that sub-tasks are switched on. If the type never appears, it is disabled in the project's issue type scheme on a company-managed project, or turned off in project settings on a team-managed one. Nothing else in this post works until that is fixed, and several methods fail in ways that do not mention it.
Method 1 — the child work items panel
Open the parent. Find the child items panel. Add.
Faster route: Cmd/Ctrl + K, type "Add child", type the summary, Enter. It never leaves the keyboard, and for anyone doing this a few times a day the command palette is the whole difference between the panel being fine and the panel being tedious.
Genuinely good at: three to five children, right now, with whatever defaults the project gives them. Zero setup. No permission beyond the one that already lets you create issues. Nothing to learn and nothing to undo.
Where it stops: one summary per trip, and the quick-create form is deliberately short — the summary plus whatever your project makes mandatory. Everything else gets set afterwards, per child, by opening it. Fifteen children with fifteen different assignees is fifteen summaries followed by fifteen visits back into each issue. That second half is the part people forget when they estimate this at "a couple of minutes".
The trick most people miss: the global Create dialog has a Create another checkbox. Tick it and the form stays open with your field values still in it. If all fifteen children share an assignee, a priority and a parent, that is dramatically faster than the child panel, it is free, and it has been sitting in Jira the whole time.
Method 2 — CSV import
Genuinely good at: one-time loads. A migration off a different tracker. A backlog that a stakeholder already sent you as a spreadsheet. Anything past roughly a hundred rows. Nothing else native moves 400 issues in one operation with a different value in every field of every row — that combination is CSV's actual superpower, and it is a real one.
The mechanics that sink most attempts live in a single column (Fig. 2).
Two more things worth knowing before you start:
- There are two different CSV importers, and they are not equivalent. The one on the issue search screen imports into a project. The External System Import under system settings is admin-only and is the one that can update existing issues, by matching on an Issue Key column.
- Updating through CSV resets any field you did not include. A column absent from the file is not a column left alone — it is a column set back to its default. People discover this after the import, which is a bad time to discover it.
Where it stops: it is a batch job with a mapping wizard in front of it. Get the mapping wrong and the fix is a re-import plus cleanup of whatever the first attempt created. That round trip is cheap when you are loading 400 rows once and expensive when you are loading 15 rows weekly. For a fifteen-row list you will spend longer in the wizard than the child panel would have taken end to end.
Method 3 — automation rules
Genuinely good at: the same breakdown, over and over. Every QA story needs the same six checks. Every release epic needs the same four sign-off tasks. Every onboarding ticket spawns the same list of accounts to create.
Write a rule once: when a Story is created with a given label, create these six children with the parent set. From then on nobody types anything. The children appear the moment the parent does — no forgetting, no drift, no "we skipped the security review sub-task again".
It also handles the fan-out case that surprises people. Take a text field holding a comma-separated list, split it on commas, and create one child per item. That turns an arbitrary list into an arbitrary number of children, generated at run time.
The numbers: rules scoped to a single project have no monthly execution cap on Free, Standard or Premium. Global and multi-project rules do — 100 executions a month on Free, 500 on Standard, 1,000 per licensed user on Premium. If you build this as a global rule across thirty projects, that ceiling is closer than it looks.
Where it stops: the child list is inside the rule. Changing it is a rule edit, and in most organisations rule edits are gated behind someone with admin rights and a queue. If the breakdown is different every single time — which is the normal case for feature work — you are writing a rule per breakdown, and that is strictly worse than typing.
Method 4 — the REST API
Genuinely good at: the list already exists in software. A test matrix generated by a script. Tickets derived from a monitoring config. Anything where a human transcribing the list is the slowest and least reliable step in the chain.
Jira Cloud's bulk-operations endpoints take up to 1,000 issues and 200 fields in a single request. Sub-tasks are created the same way as anything else — set the parent in the fields payload.
Where it stops: a token, a script, and error handling. Mostly error handling. The question everyone answers badly the first time is what happens when a batch half-fails and you re-run it: without an idempotency strategy you now have seventy-eight children where you wanted forty, and both runs reported success, because both runs succeeded. This is a fine method for a pipeline and a poor one for a Friday afternoon.
Method 5 — a Marketplace app
The honest positioning for this whole category: it exists for the case none of the four above serve well. A list of ten to a hundred children, different every time, currently living in your head or in a doc — and you want per-row field values without a mapping wizard and without touching a rule.
That is a narrow gap. It is also an extremely common one, because it describes sprint planning.
Ours works this way: type or paste one line per child, set the parent once for the whole batch, set assignees and priorities across rows in a single pass, review the tree, create. We wrote up what that looks like end to end, with screenshots, on the product side of this site.
Two limits worth stating plainly, since the point of this post is to help you choose rather than to sell you the fifth option:
- It creates issues. It does not edit issues that already exist in Jira — for that you want native bulk change, and we wrote a separate post about exactly that.
- Batches cap out at 300 rows on the Advanced plan and 150 on Standard. Past that, CSV is the correct tool and we will tell you so.
Two questions that always follow
"Can I turn my checklist into sub-tasks?" No, not natively. Checklist items are text living in a description field or inside a checklist app's own storage. Jira has no conversion path from either into issues. Whatever you use, the items get retyped or pasted somewhere that turns lines into rows — which is why a plain list of lines is the input format for every method above except the API.
"Can I turn issues that already exist into sub-tasks of a parent?" Yes, and this is the one place bulk change genuinely helps with sub-tasks. It is a move, not a create. Select the issues, bulk move them, pick Sub-task as the destination type, and the wizard asks for the parent.
Three constraints on that, all of which people hit:
- One parent for the whole batch. You give the wizard a single issue key and every issue in the selection becomes a child of it. Different parents means one bulk move per parent.
- The parent has to be a standard-level issue, not an Epic. Sub-tasks live below Story and Task, not below Epic.
- Same project. Parent and children must share one.
Batching by parent is tedious but it is a real, free path, and it is the answer to a surprising share of "we planned this wrong" situations.
Picking, in one paragraph
Same breakdown every time — automation rule. Already a spreadsheet, or over a hundred rows — CSV. Produced by code — the API. Three or four children with shared defaults — the child panel, with Create another ticked. A different list of ten to a hundred every sprint — that is the gap the apps fill, and it is the only situation where paying for one is obviously correct.
Everything else is somebody's preference dressed as a recommendation.
This post compares methods for getting many children under a parent. If you want the product walkthrough of the fifth option instead, that is bulk-creating subtasks in Jira. Starting a backlog from scratch rather than adding children to something that exists is a different job — see bulk-creating Jira issues from any text.