Two entirely different jobs go by the name bulk edit, and almost every article about this conflates them.
The first: sixty issues already exist in Jira and something about them is wrong. Wrong sprint, wrong component, wrong assignee after somebody left. You need to change a field on all of them without opening sixty issues.
The second: sixty issues do not exist yet. They are lines in a document, rows in a sheet, a list from a planning session — and they need types, owners and consistent naming before anybody creates them.
The tools for these two jobs share almost nothing. Start with the first one, because it is the one Jira already solves, and it solves it for free.
Native bulk change is the default answer
For issues that already exist, Jira's built-in bulk change is the right tool most of the time. It is worth knowing properly rather than reaching past.
Getting to it: run a search that returns exactly the issues you want — the issue navigator, or JQL if the selection is at all subtle — then take the bulk change action from the results. The selection is the search, which is the part worth internalising. Time spent sharpening the JQL is time not spent ticking checkboxes.
What it can do: edit fields, move issues between projects or issue types, transition them through a workflow, delete them, and start or stop watching. Five operations. That is the whole set, and note what is not in it — bulk change never creates anything.
What it needs: the global Make bulk changes permission, plus the project permission matching the operation. A bulk move needs Move Issues as well. If the menu item is not there at all, you are missing the global permission, and no amount of reloading the page will grow it back. A bulk transition needs the transition to be legal from each issue's current status, which is the usual reason a bulk transition silently skips a third of the selection.
The ceiling: 1,000 issues per operation on Jira Cloud. On Data Center an admin can raise that number. On Cloud there is no setting — you batch the work into thousand-issue selections and run it more than once.
The checkbox that ruins afternoons: the confirmation step controls whether the change notifies watchers. Leave it ticked on a 600-issue edit and you have generated 600 issues' worth of email for everyone watching them. Nobody thanks you for that twice.
The shape of the thing
Everything above is documented. The property that matters is not, because it is a consequence rather than a feature.
Bulk change is a broadcast. It writes one value across the entire selection. So the cost of a job is set by the number of distinct values you need — not by the number of issues (Fig. 1).
Two columns of five issues. In the first, every issue receives the same priority and one operation covers all of them. In the second, each issue receives a different assignee, which native bulk change cannot express in a single operation.
Select from a filter, pick the field, set the value. Scales to the 1,000-issue cap without getting harder.
Each pass needs its own selection, so you write the JQL that isolates each group first. Past a handful of values this stops being worth doing by hand.
Which flips the intuition. Setting Fix Version: 4.2 on nine hundred issues is one pass and takes a minute. Setting the right assignee on nine issues, where the right assignee differs each time, is nine passes and takes longer. The big job is the easy one.
Recognising which of the two you have, before you start clicking, is most of the skill here.
When you need a different value per issue
Four honest options, roughly in order of how much machinery they require.
Split the work into groups. The underrated one. You rarely need nine different values — you usually need three values spread across nine issues. Write JQL that isolates each group, run bulk change per group, done in three passes. If the groups are describable as a query, this beats every other option on this list and needs nothing you do not already have.
Automation rules. A rule can branch over a set of issues and act on each one individually, which is exactly the per-issue behaviour bulk change lacks. It also runs on a trigger, so it fixes the next hundred issues as well as this hundred. The trade: it processes items one at a time against service limits on rule execution and processing time, so it is well suited to a steady trickle and poorly suited to a one-off backlog of thousands.
The bulk-operations REST API. Up to 1,000 issues and 200 fields per request. The right answer when the correct values live in another system — a spreadsheet of ownership, an HR export, a config file — and the mapping is mechanical. It is also the only option here that you can dry-run against a copy before committing.
CSV, through the admin importer. The External System Import can update existing issues by matching on an Issue Key column, which makes CSV a legitimate bulk-edit tool. Two conditions, both load-bearing: it is admin-only — the CSV import on the issue search screen creates but does not update — and any field you leave out of the file is reset to its default, not left alone. That behaviour has eaten a lot of data. Include every column you care about, or do not use this method.
A worked example: somebody left
The most common real bulk edit there is. A teammate leaves. They are the assignee on 140 open issues across four projects, and every one of those issues is now invisible to whoever should pick it up.
The instinct is to select all 140 and reassign them to a lead. That produces one pass, a tidy board, and a lead with 140 issues they cannot possibly own. Three months later the same 140 issues get reassigned again, by hand.
The better shape is three or four passes, sliced by something that already encodes the right answer:
assignee = "departed.person" AND status != Done AND component = "Billing"
assignee = "departed.person" AND status != Done AND component = "Search"
assignee = "departed.person" AND status != Done AND labels = "infra"
assignee = "departed.person" AND status != Done
Run the specific queries first and the catch-all last, so each issue is claimed by the most precise rule that matches it and the remainder — the genuinely ambiguous ones — is what lands on the lead's plate. That remainder is usually a tenth of the original number, and it is the only part of the job that needed a human decision.
Notifications off for all four passes. The team already knows.
The general move: find the field that already correlates with the answer, and let JQL do the sorting. Component, label, epic, sprint, reporter. It is nearly always there. Selecting issues by hand because the query was hard to write is the most common way this work becomes an afternoon instead of ten minutes.
Bulk move deserves its own warning
Moving issues between projects or issue types is the most useful bulk operation and the one that loses information.
The wizard walks you through mapping fields, statuses and issue types to whatever exists in the destination. Anything the destination has no home for does not come along. Custom field not on the target project's screens — gone. Status with no equivalent in the target workflow — remapped to whatever you pick, for every issue in the batch.
None of this is a bug. It is what a move has to mean when two projects are configured differently. But the wizard is long, the consequences are quiet, and by screen four you will be clicking Next with the calm of someone who has stopped reading. Run it on two issues first, look at what came out the other side, then run it on the other four hundred.
The other bulk edit — the one that happens before Jira
Now the second job.
A large share of the bulk-change work a team does in a quarter is repair. Issues created one at a time, over days, by different people, with the type set by whatever was default and the naming set by whatever each person felt like. Then someone spends an afternoon in the bulk-change wizard making them consistent.
That afternoon was avoidable, and the reason is structural rather than behavioural. An edit before creation and an edit after creation cost wildly different amounts (Fig. 2).
a keystroke
Nothing exists yet. No issue history, no notification decision, no permission beyond the one that lets you create at all. Get it wrong and you retype a line.
a pass, an audit line, a notification decision
Every change is now a write against a real issue. It lands in that issue's history, it can email its watchers, and it needs the Make bulk changes permission plus the project permission for the operation.
Before the issues exist, changing your mind costs a keystroke. There is no history to pollute, no watcher to notify, no permission to hold, no 1,000-row ceiling, and no broadcast constraint — every row can have its own value because you are editing rows, not issuing an operation.
After they exist, the same change costs a pass, a line in each issue's history, a notification decision, and the permissions above.
This is where SuperTemplates sits, and it is worth being exact about the boundary: it is an editor for a batch that has not landed yet. Type or paste the rows, restructure them, set types and assignees and dates across a selection in one pass, name forty tasks consistently, then create the whole batch. What it does not do is edit issues that already exist in Jira — for those, everything in the first half of this post applies, and native bulk change remains the correct starting point.
If you are choosing between the two: the question is not which tool is better. It is which side of the create boundary your problem is on.
Choosing, in one paragraph
Issues already in Jira, one value across many — native bulk change, and sharpen the JQL rather than the clicking. Issues already in Jira, a different value each — split into groups by query first, and reach for automation, the REST API or the admin CSV importer only when the groups are not describable. Issues that do not exist yet — fix them before they exist, in whatever holds the draft, because that edit is free and every edit after it is not.
And if you find yourself in the bulk-change wizard every sprint fixing the same class of mistake, the wizard is not the problem you are solving.
This post is about the methods, native ones first. If you want the product walkthrough of the pre-creation editor instead, that is bulk editing a batch before it reaches Jira. If what you actually need is many children under an existing parent, that is a different job — see how to create multiple subtasks in Jira.