Bulk Scheme Management
If you've just restructured your organization and need to update the permission scheme on 200 spaces at once — or you're retiring an old workflow scheme and need to migrate everything off it — this is what you're looking for.
How It Works
All four scheme managers — Permission, Notification, Workflow, and Work Type — follow the same 3-step wizard. Once you understand the pattern for one, you know it for all of them.
Step 1 — Select Spaces
Click the space list to load it. Depending on instance size this takes 5–20 seconds. Once loaded, use the search box and the type/style filters to narrow down to the spaces you want. You can filter by space type (Software, Service, Work), by style (company-managed vs. team-managed), or search by name or key.
Once you've got the right spaces showing, select them individually with checkboxes, or click Select All Matching to grab everything that matches your current filter. The counter shows exactly how many you have selected. Clear All resets your selection so you can start over.
Step 2 — Select Scheme
A table shows all available schemes for that scheme type. For each of your selected spaces, the table also shows its current scheme so you can compare before making changes. Pick the new scheme from the list.
Step 3 — Review & Apply
The preview screen shows each space with its current scheme on the left and the new scheme on the right. Team-managed spaces appear here with a "Skipped" badge (more on that below). Any spaces where the current and new scheme are already the same will also be skipped — they show up in the preview for transparency but the app doesn't make unnecessary API calls for them.
Click Apply to start the operation. A progress bar runs and each space shows its result — success or failure — as it's processed. Failures include the reason, so you know what to address.
Permission Schemes
The most common use case: you've finished a reorg, you've created a new permission scheme for the new team structure, and you need to move a large group of spaces onto it. The wizard handles this in a few minutes regardless of how many spaces you're updating.
A few things worth knowing before you run a permission scheme change:
- Access changes are immediate — the moment the scheme assignment updates, users' permissions change. If you're making a restrictive change, do it during off-hours if possible.
- The Default Permission Scheme can't be deleted, but you can still reassign spaces away from it.
- If you're assigning a scheme to spaces that currently have the Default scheme, and you haven't finished configuring the new scheme, hold off. Partially configured permission schemes can lock people out.
Permission changes are immediate
There's no staging or preview of the access impact here — the scheme assignment changes as each space is processed. Verify the new scheme is configured correctly before applying it to production spaces.
Notification Schemes
There's an important limitation to be upfront about here: Jira's REST API doesn't support bulk notification scheme reassignment the same way it supports permission and workflow scheme changes. This is a Jira API limitation, not an app limitation — the endpoint for reassigning notification schemes via REST isn't available for most scheme types.
What this section does instead: it identifies which spaces are on which notification scheme and provides direct links to each space's notification settings page in Jira — the exact settings page where you'd go to change the scheme manually. So instead of opening each of your 50 affected spaces and hunting for the notification settings, you get a list of direct links, one per space, that take you straight to the right page.
It's more clicks than a fully automated solution, but it's still considerably faster than finding each space manually. The links open in a new tab so you can work through the list without losing your place in the app.
Workflow Schemes
Workflow scheme reassignment is the most complex of the four because Jira treats it differently depending on whether the space has issues in it.
Empty spaces (no issues): the scheme updates immediately. No migration required, no special handling.
Spaces with issues: Jira requires a migration step when you change a workflow scheme on a space that has existing issues. This is because each issue has a current status, and the new workflow scheme might have different statuses. Jira needs you to map old statuses to new ones. When this happens, the app surfaces Jira's native migration page for that space — you complete the migration there, and then the scheme update takes effect.
Plan for migrations on spaces with issues
If you're reassigning a workflow scheme across 100 spaces and 80 of them have issues, you'll have 80 migration steps to complete — one per space. This is a Jira requirement; there's no way to skip the migration on spaces with issues. Factor this into your planning. For spaces with very similar workflows, the migration is usually trivial (status names match, one-click mapping). For major workflow restructures it can take longer.
Work Type Schemes
Work type scheme reassignment is simpler than workflow schemes but similar in structure. The wizard follows the same 3-step pattern. One thing to be aware of: if you're assigning a scheme that has fewer work types than the current scheme, and existing issues use one of the removed types, Jira may require a migration to reassign those issues to a different type. The app handles the scheme assignment; any required migration is handled by Jira's native migration flow.
Team-Managed Spaces
Team-managed spaces — previously called "next-gen projects" — control their own configuration. Unlike company-managed spaces, they don't use the global scheme library. There's no Jira REST API endpoint for bulk scheme assignment on team-managed spaces; they literally aren't supported by the APIs this app uses.
So here's what happens: team-managed spaces appear in your space list and you can select them like any other space. But when you get to Step 3 (Review & Apply), they show up with a Skipped badge and an explanation. The Apply button processes only company-managed spaces; team-managed ones are left untouched.
To change scheme settings on a team-managed space, you'd do it from within that space's own settings — Project Settings > Access (for permission-equivalent settings) or the relevant section in that project's settings. Each one has to be done individually because that's what Jira supports for them.
The skipping behavior is transparent — the preview screen shows you exactly which spaces will be processed and which will be skipped before you click Apply. You won't be surprised by the outcome.
Selecting Large Space Lists
On instances with 5,000+ spaces, scrolling through the list to find what you want isn't practical. Use the filters first. Filter by type (Software, Service, Work), by style (Company-managed, Team-managed), or search by name. Once your filter is showing the right spaces, click Select All Matching (N) to select all of them in a single click — no pagination needed. The N in the button tells you exactly how many you're selecting.
A typical workflow: filter to "Company-managed" + "Software" + search for a team prefix in the project key. You'll usually narrow a 7,000-space instance down to 50–200 spaces that match. Then Select All Matching, proceed to scheme selection, and apply. The whole thing takes a few minutes.
Clear All deselects everything so you can start a new selection. The selection counter at the bottom of the space list shows how many are selected at any time.
Error Reference
| Error | Cause | Solution |
|---|---|---|
| 403 Forbidden | Not a Jira site admin | Confirm you have the global ADMINISTER permission. Project admin isn't sufficient. |
| 404 Not Found | Space or scheme was deleted since you loaded the list | Refresh the space list and try again. The list is a snapshot from when you loaded it. |
| Scheme in use | Trying to delete a scheme that's still assigned to spaces | Use the scheme manager to reassign all spaces to a different scheme first, then delete. |
| Team-managed skip | API limitation — team-managed spaces can't be bulk-assigned | Update via each space's own Project Settings. |
| Migration required | Workflow scheme change on a space with issues | Follow the migration link to Jira's native migration page for that space. |
Audit Trail
Every scheme change is logged in Jira's built-in audit log under your account — not under the app's identity. If you bulk-assign a permission scheme to 200 spaces, each of those 200 changes shows up in the Jira audit log with your name attached to it. This is by design: actions should be traceable to the admin who performed them, not to an opaque application.
You can review these changes in Jira's native audit log or through the Audit Log Analyser in the app. Filter by your account and the relevant date range to see exactly what was changed. If anything needs to be rolled back, the audit log gives you the before and after values for each space.