Study guide
9.5 Bulk Operations: Edit, Move, Transition, Delete & Watch
Atlassian Certified Professional - Jira Administration for Cloud ACP-120
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview, Blueprint & Jira Cloud Fundamentals
1.1 ACP-120 Exam Structure, Blueprint & Testing Strategy 1.2 Jira Cloud Architecture, Products & Admin Hierarchy
2 Chapter 2: Organizations, Managed Accounts & Global Access
2.1 Atlassian Organizations, Domain Verification & Managed Accounts 2.2 Atlassian Guard, SAML SSO, SCIM & Authentication Policies 2.3 Site Access, Product Access Tiers & Global Permissions 2.4 User Directory Architecture: Groups vs. Project Roles
3 Chapter 3: Project Permissions & Issue-Level Security Schemes
3.1 Permission Scheme Mechanics & Critical Project Permissions 3.2 Permission Troubleshooting, Additive Permissions & Permission Helper 3.3 Issue Security Schemes, Security Levels & Access Containment
4 Chapter 4: Project Configuration, Types, Versions & Boards
4.1 Company-Managed vs. Team-Managed Project Architecture 4.2 Project Templates, Project Keys & Project Categories 4.3 Project Components, Component Leads & Default Assignees 4.4 Versions, Fix Versions, Release Lifecycles & Project Archiving 4.5 Scrum and Kanban Board Configuration, Board Filters & Columns
5 Chapter 5: Issue Types, Custom Fields, Screens & Schemes
5.1 Standard vs. Sub-task Issue Types & Issue Type Schemes 5.2 Custom Field Types, Global vs. Project Contexts & Options 5.3 Field Configurations, Renderers, Hiding & Required Fields 5.4 Screens, Screen Schemes & Issue Type Screen Schemes
6 Chapter 6: Workflows — Company-Managed and Team-Managed
6.1 Statuses, Status Categories, Direct & All-to-One Global Transitions 6.2 Transition Rules: Conditions vs. Validators 6.3 Post Functions, Execution Order & Resolution Management 6.4 Workflow Schemes, Editing Active Workflows & Status Migration 6.5 Team-Managed Workflows, Statuses & Workflow Rules
7 Chapter 7: Jira Cloud Automation
7.1 Automation Engine, Rule Architecture & Event Triggers 7.2 Automation Conditions, Smart Values & String/Date Expressions 7.3 Branch Rules, Related Issues, Sub-tasks & Parent Epics 7.4 Rule Scopes, Automation Usage, Audit Logs & Error Handling
8 Chapter 8: Notifications, Events, Personal Settings & Mail Handlers
8.1 Jira Events, System Events & Notification Schemes 8.2 Notification Recipients, Custom User Fields & Deduplication 8.3 Team-Managed Notifications, Personal Settings & Troubleshooting Missing Email 8.4 Mail Handlers: Creating Issues and Comments from Email
9 Chapter 9: JQL, Filters, Dashboards & Bulk Operations
9.1 JQL Fundamentals, Clauses, Operators & History (WAS / CHANGED) 9.2 Advanced JQL Functions & Dynamic Date Searches 9.3 Filter Permissions, Shared Filters & Filter Subscriptions 9.4 Dashboard Layouts, the Default Dashboard, Sharing & Essential Gadgets 9.5 Bulk Operations: Edit, Move, Transition, Delete & Watch
10 Chapter 10: System Administration
10.1 Global UI Features: User Defaults, Look and Feel, Announcement Banner & Default Dashboard 10.2 Statuses, Resolutions, Priorities & Sub-tasks: Global Configuration 10.3 Global Settings: Time Tracking, Issue Linking, Attachments & Application Links 10.4 System Backup, Restore & Data Import
9.5 Bulk Operations: Edit, Move, Transition, Delete & Watch
Key Takeaways Explain This Topic AI
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.
Last updated: September 2026
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.editable isn'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.