The hidden config debt Jira silently creates for you

[#1]

While running automated configuration scans across Jira instances, we noticed something unexpected: screens that are orphaned from the moment they are created.

Here's how to reproduce it:

1. Create a new software project in Jira
2. Go to Admin > Screens
3. Search for your project key
4. You'll find 3 screens were auto-created
5. Now check your Screen Scheme - only 2 of those 3 screens are referenced
6. The third one, "Resolve Issue Screen", is linked to nothing. No Screen Scheme. No Workflow Transition. Orphaned from the moment it was created.

Now delete that project.

The project and its work items are gone. But go back to Admin > Screens. The 3 screens are still there. Check Workflow Schemes, Screen Schemes, Issue Type Schemes, Permission Schemes, Notification Schemes - all still there. Jira removes the project but leaves every piece of configuration behind.

Cleaning this up natively:

You'd need to manually visit 8+ different admin pages. Jira does show which projects use each scheme, so you can check if it's safe to delete. But you still have to go through every item one by one, across screens, screen schemes, workflow schemes, issue type schemes, permission schemes, and more. There is no single "clean up after project deletion" option. For a single project, that's easily 10+ items to review and delete manually.

Some Marketplace apps can help by scanning for orphaned configurations after the fact. But it's always a two-step process: delete the project, then run a separate audit to find and clean up the leftovers. The orphans exist in between.

What Scalpel does differently:

One toggle at deletion time. Enable "Delete configurations" in Scalpel's Space Manager and everything happens in a single operation:

• Inventories all assigned configurations before the project is removed
• Determines which are exclusive to this project vs. shared with others
• Deletes the project
• Removes all exclusive schemes, workflows, and screens in the correct dependency order
• Catches screens that Jira created orphaned from birth
• Skips shared configurations and system defaults
• Shows a full summary of what was deleted, what was skipped and why

No separate audit. No manual cross-referencing. No leftover config debt. Works for single and bulk deletes.


If you know what I'm talking about and your instance suffers from config debt, it's time to scan it with surgical precision.
Every surgeon needs the right instrument. A Scalpel for Jira.

wanna see it in action?
Space Manager (Deletion with config items)

[C_ Faysal_CFcon_]

I extended my research...

This has been requested from Atlassian since 2017 (JRACLOUD-67882) and 2019 (JRACLOUD-79026).

Still open.