Getting started
Bulk Ops is an admin-only app. After it is installed, open Jira Settings → Apps → Bulk Ops for Jira. Only users with Jira administrator permissions can see and use it.
Every operation runs as you, the admin who launches it. The app can only read and change what you could already read and change manually in Jira, and it respects all of your project permissions, field configurations, and workflow rules.
Running an operation
Each run follows the same three-step wizard, ending in a preview you must confirm before anything changes.
Step 1: Select issues
Write a JQL query in the editor (it offers field and value autocomplete), then run the search to preview the exact set of issues it matches. You can refine the query until the matched set is what you intend. A run must match at least one issue to continue.
Step 2: Build the operation
Choose what to do to the matched issues: set a field, add or remove values, or transition them (see The three operations below). Pick the field and the value(s) involved.
Step 3: Preview & confirm
The preview names the exact field being changed and shows the before and after value for each matched issue, so there are no surprises. You can also choose to suppress Jira notifications for the change. Nothing is modified until you confirm here.
Once confirmed, the run executes in the background on Atlassian's infrastructure. You can watch live progress, or close the tab and come back later: the run continues server-side either way.
The three operations
Set a field
Replaces a single-value field with the value you choose. Supported field types include text, numbers (such as story points), dates and date-times (such as due date), priority, user fields (assignee, reporter, user pickers), single-select options, components, versions, and groups.
Add or remove values
Adds or removes values on multi-value fields without overwriting what is already there. Works on labels and on multi-user, multi-select, and multi-group fields. Add appends only the values that are missing; Remove takes away only the values you specify and leaves the rest intact.
Transition issues
Moves matched issues through a workflow transition, with an optional resolution. Only issues that can legally make the transition from their current status are moved; the rest are reported in the audit trail (see below).
Progress & the audit trail
As a run executes, Bulk Ops shows a live tally: processed, ok, failed, and skipped. Every issue is recorded in a per-issue audit trail with its result and the before/after values, which you can export to CSV.
- Ok: the change was applied successfully.
- Skipped: the issue was already at the target value, so no change was needed. This is normal and not an error.
- Failed: the change could not be applied to that issue (for example, a permission, validation, or workflow rule prevented it). The reason is recorded on the issue's audit row.
Free vs. paid
- Free: the full operation set, with runs capped at 1,000 issues per run and run history retained for 7 days.
- Paid: unlimited issues per run and 90-day run/audit retention. Pricing is per user, with the 1–10 user tier free and volume discounts at larger tiers.
On the free plan, if your JQL matches more than 1,000 issues the run is blocked with an upgrade prompt. Narrow the query (for example, add a date or project clause) to bring the matched set under the limit, or upgrade for unlimited runs.
Permissions & data
Bulk Ops is built natively on Atlassian Forge and runs entirely within your Atlassian environment, with no external servers and no data egress. It stores only operational metadata (your run definitions and the audit trail) in Forge storage, references users by Atlassian account ID only, and deletes all of its data automatically when the app is uninstalled. See the privacy notice and security policy for details.
Frequently asked questions
Can I undo a bulk operation?
There is no one-click undo. However, the audit trail records the before value of every changed issue, so you can reverse a change by running an inverse operation (for example, set the field back, or remove the labels you added). For this reason, always review the preview carefully before confirming.
Will everyone get email notifications for the changes?
You can choose to suppress Jira notifications for a run on the preview step, which prevents the usual flood of change emails for field edits. Some changes (such as transitions) may still generate Atlassian-side notifications; where a notification could not be suppressed, the audit trail flags it on that issue.
Some issues were "skipped." Did something go wrong?
No. "Skipped" means the issue was already at the target value, so no change was necessary. This also makes runs safe to re-run: re-applying the same operation simply skips the issues that are already done.
Why did a free run process slightly more or fewer than 1,000 issues?
The free-tier limit is checked against Jira's approximate match count, which can differ slightly from the exact number processed. The 1,000-issue cap is a plan boundary, not a safety control, so a free run may occasionally process a little above or below it. Operations always run within your own permissions regardless.
Does it work with Jira Service Management?
This release is built and tested for Jira Software and Jira Work Management. Jira Service Management is not officially supported yet.
What happens if I close the browser while a run is going?
Nothing is lost. Runs execute in the background on Atlassian's infrastructure. You can close the tab, navigate away, or come back later; progress and the audit trail are preserved, and the run keeps going.
How large a run is practical?
Runs are processed in batches in the background and routinely handle many thousands of issues past Jira's native 1,000-issue ceiling. For extremely large operations (tens of thousands of issues), it is good practice to split the work into a few JQL-scoped runs (for example, by project or date range).
What if I hit Jira's rate limits?
Bulk Ops detects Jira API rate limiting and automatically pauses and resumes the affected work, so a large run may simply take longer rather than failing. No action is needed on your part.
Can a transition that requires mandatory fields be run?
Transitions support an optional resolution. If a transition's screen requires other mandatory fields that the operation does not set, those specific issues will be reported as failed in the audit trail, with the rest unaffected.
Can two admins run operations at the same time?
Yes. Runs are independent and each appears separately on the runs dashboard with its own status, progress, and audit trail.
Does my data leave Atlassian?
No. The app runs on Atlassian Forge with no external egress, and stored data follows your Jira site's data residency. All app data is deleted when you uninstall.
Need more help?
Email support@magratheasoftware.com and we will be glad to help.