9.5 Bulk Operations: Edit, Move, Transition, Delete & Watch
Key Takeaways
- Bulk changes need the Make bulk changes global permission plus the matching project permission on every issue, for example Move Issues in the source and Create Issues in the destination.
- One bulk operation handles up to 1,000 issues, and bulk transitions run one transition at a time for groups of issues that share a workflow and status.
- Versions and components can be bulk-edited only when all issues are in one project; Project, Resolution, Summary, Description, Attachments, and time-tracking fields can't be bulk-edited.
- Bulk moves map statuses and fields; moving company-managed issues into a team-managed project permanently drops component and version data.
- Clearing 'Send mail for this update' prevents notification floods, but bulk changes still write history and can trigger automation for every issue.
9.5 Bulk Operations: Edit, Move, Transition, Delete & Watch
Blueprint objective 6.3 asks you to understand bulk operations: the options available, how permissions and workflows limit them, how fields are mapped when issues move, and what side effects (replaced values, notifications, data loss) a bulk change can cause. Jira admins use bulk changes to clean up after reorganizations, fix bad data, and migrate issues between projects.
Starting a Bulk Change
- Run a search (basic or JQL) that returns exactly the issues you want. Filter first, then act.
- From the search results, open More actions (•••) > Bulk change all … issues.
- Select the issues to include (up to 1,000 issues in one operation), then choose the operation.
| Operation | What It Does |
|---|---|
| Edit issues | Change field values on all selected issues |
| Move issues | Move issues to another project and/or issue type, mapping statuses and fields |
| Transition issues | Move issues through one workflow transition together |
| Delete issues | Permanently delete the selected issues |
| Watch / Stop watching issues | Add or remove yourself as a watcher |
Permissions: Global Plus Project
Every bulk operation needs two layers of permission:
- the Make bulk changes global permission, which unlocks the bulk tool itself; and
- the normal project permissions for the action, on every selected issue.
| Operation | Project Permissions Also Needed |
|---|---|
| Edit | Edit Issues (plus Assign Issues to change Assignee, Modify Reporter to change Reporter, Schedule Issues to change Due Date, Set Issue Security to change Security Level, Add Comments to add a comment) |
| Move | Move Issues in the source project and Create Issues in the destination project |
| Transition | Transition Issues, and the user must satisfy the transition's rules (conditions and validators) |
| Delete | Delete Issues |
If a user can't see a bulk operation, check the global permission first, then the project permission for that specific action.
Bulk Edit: What You Can and Can't Change
Bulk edit offers a field only when it makes sense for all selected issues:
- Versions and components (Fix Version/s, Affects Version/s, Component/s) can be bulk-edited only when all selected issues belong to one project, because these values belong to a project.
- A field that is hidden in any field configuration used by the selected issues isn't offered.
- Custom fields are offered when the field applies to all selected issues: a global custom field, or a field scoped to one issue type or one project that all the issues share.
- Security Level can be changed only if all selected projects use the same issue security scheme and you hold Set Issue Security.
- Sprint changes only affect active and future sprints (you supply the sprint ID). Closed sprints aren't touched.
- Closed issues can be edited only if the workflow allows editing in that status (for example,
jira.issue.editableisn't false).
Some fields are never available for bulk edit, each with a documented alternative:
| Not Bulk-Editable | Use Instead |
|---|---|
| Project | Bulk move |
| Resolution | Bulk transition (transitions set Resolution) |
| Summary, Description, Environment, Attachments | Edit issues individually, or use automation |
| Time tracking (Original estimate, Remaining estimate, Time spent) | Log work or edit individually |
Replacing values: a bulk edit overwrites the chosen field on every issue. Multi-value fields such as labels or components offer choices such as adding to, replacing, or removing existing values. Read the option carefully, because choosing "replace" wipes values that were different on each issue.
Bulk Transition and Workflows
- You can run one transition at a time. If the selected issues use different workflows, Jira groups them by workflow and status, and you transition one group at a time.
- Only transitions that are available to you on those issues appear. If a restrict rule (condition) hides a transition from you, you can't bulk-run it either.
- You must supply values for any required fields on the transition screen. For example, closing issues usually requires a Resolution (Done, Fixed, Won't Do), which is exactly how admins bulk-fix issues sitting in Done without a resolution.
Bulk Move: Status and Field Mapping
A bulk move can change the project, the issue type, or both:
- Choose the destination project and issue type for each source project and type.
- Map statuses: if the destination workflow doesn't contain an issue's current status, choose a status in the new workflow. Atlassian advises mapping to a similar status category.
- Update fields: for fields the destination requires or configures differently, either enter a value or choose Retain. Retain works only when the fields have the same custom field type and name.
- Sub-tasks come along: if the issues have sub-tasks, those must be moved to the destination too.
- Review and Confirm.
Moving Between Company-Managed and Team-Managed Projects
- Company-managed to team-managed: Atlassian warns that component and version information isn't retained, and is permanently removed once the move completes.
- Team-managed to company-managed: the move transfers system fields, comments, and attachments, but custom field data isn't included. Atlassian's documented workaround is to export the issues to CSV (all fields) before the move, bulk-move them, then re-import the custom field values with the CSV importer, using the new issue keys.
- Moved issues get new keys in the destination project. Links to old keys redirect, but saved JQL that names specific keys must be updated.
Notifications and Other Side Effects
- Send mail for this update: on the confirmation step, you can clear this option to avoid flooding everyone who watches the affected issues. Atlassian notes that in Jira Service Management, agents who aren't project or Jira admins can bulk edit but can't turn notifications off.
- History: each changed issue records the change in its history under the person who ran the bulk operation.
- Automation: rules triggered by edits or transitions may run for every issue changed. That can produce many rule executions and use automation steps quickly.
- Delete is permanent: Jira Cloud has no recycle bin for issues, and Atlassian's backups can't restore individual deleted issues. Prefer a Cancelled or Won't Do status, and keep Delete Issues tightly restricted.
A project lead has Make bulk changes and Edit Issues in project OPS. When she bulk-edits 300 OPS issues, the Due Date field isn't offered, although Priority and Labels are. What's the most likely reason?
An admin needs to set Resolution = Done on 400 issues that are already in a Done status but have no resolution. Which approach works?
A team bulk-moves 200 issues from a company-managed project into a new team-managed project. Afterwards they notice every issue has lost its Fix Version and Component values. What happened?