The Ghost Config Problem: What Jira Leaves Behind When You Delete a Space

[#1]

You deleted the space. The team is gone, the work items archived, the backlog cleared. Job done.

Except it isn't.

Somewhere in your Jira instance, a workflow still exists. A permission scheme with that team's name. A screen scheme nobody remembers creating. A notification scheme that will never fire again. They're not attached to anything anymore - but they're still there, quietly accumulating alongside every other space you've ever cleaned up.

This is the ghost config problem.

Why Jira doesn't clean up after itself

Jira does enforce one rule here: a scheme can only be deleted when it has zero assignments. That part works fine. What Jira doesn't do is figure out which schemes became orphaned after a space deletion - that's left entirely to the admin.

There's no built-in tracking of whether a scheme was exclusive to the deleted space or still in use elsewhere. Jira simply removes the space and leaves everything else untouched. The cleanup is a fully manual process.

Atlassian even documented the steps: after deleting a space, an admin should manually check Workflow Schemes, Screen Schemes, Work Item Type Schemes, Field Configurations, Permission Schemes, Notification Schemes, and Security Schemes - one by one - to find what's now orphaned and safe to remove.

In practice, most admins don't. And over months and years, the configs pile up.

What accumulates over time

In a mature Jira instance, this isn't a minor housekeeping issue. Each deleted space can leave behind:

• Workflow Schemes (and the underlying workflows)
• Screen Schemes
• Work Item Type Schemes
• Field Configurations
• Permission Schemes
• Notification Schemes
• Security Schemes

They show up in scheme selectors when configuring new spaces. They slow down admin navigation. And they create a false picture of your instance's actual configuration - making it harder to understand what's really in use versus what's just residue from spaces that no longer exist.

The manual approach

If you've tried to clean this up manually, you know the process:

1. Delete the space
2. Open each scheme type in Jira settings - one by one
3. Identify which schemes have zero assignments
4. Determine whether they were exclusive to the deleted space or still needed
5. Delete the ones that are safe to remove
6. Repeat for every scheme category

It's tedious, error-prone, and easy to skip. Which is exactly why most instances never get cleaned up at all.

A smarter approach: collect first, then clean

The right way to handle this is a two-phase process:

Phase 1 - Collect: Before the space is deleted, identify every scheme exclusively assigned to it. Not shared with other spaces - purely owned by this one.

Phase 2 - Cleanup: Delete the space. Then, with the list of now-orphaned configs already in hand, remove them automatically.

This is what Scalpel for Jira now does when you delete a space through its Space Manager. The entire process runs with a live log - per-space and per-item - so you can see exactly what was collected, what was removed, and confirm nothing was touched that shouldn't have been.

Beyond space deletion

This release also improves how Scalpel handles orphan detection across the board. All orphan categories now follow a consistent pattern: Accept/Revoke for marking items, and Treat to navigate directly to the relevant Manager with the filter pre-applied. No inline deletes, no guessing where to go next.

A few smaller but useful additions: spaces with zero work items now show an "Empty" status in the Space Manager, and the Filter Manager now supports enum and integer filters for more precise queries.

Scalpel for Jira is available on the Atlassian Marketplace.

If ghost configs have been piling up in your instance, this is a good time to run a scan.

best regards

cF