Work Item Configuration & Views

Overview

Work Item Configuration is where most admins spend most of their cleanup time. Over a few years of Jira usage, an instance accumulates a lot of configuration debt — workflow schemes nobody uses anymore, custom fields from abandoned projects, duplicate permission schemes, screens nobody has touched since 2021. This tool surfaces all of it in one place so you can see what's actually in use and what isn't.

The main screen has a row of tabs at the top: Workflows, Work Types, Fields, Permissions, Priorities, Notifications, Screens. Click Scan All to run everything at once, or click any individual tab and scan that section on its own. Each tab has a badge showing the item count once loaded. Inside every tab, there are two sub-tabs: Overview (summary counts and charts) and Details (the full list with search, filter, sort, and bulk actions). The data is cached once loaded, so switching between tabs is instant — you won't re-trigger any API calls just by clicking around.

Additional sections — Spaces, Dashboards & Filters, Agile Boards, Attachments, Components, Releases, and Automation Rules — are accessible from the main sidebar under Governance and Views & Boards. They're documented below alongside the main tabs since they're part of the same overall audit picture.

Spaces & Trashed Projects

The Spaces view (under Views & Boards in the sidebar) lists all your Jira spaces with the information you actually need for governance: work item count, space type (Software, Service, Work), style (company-managed vs. team-managed), and the lead's name along with whether that lead's account is still active. That last column matters more than it might seem — when someone leaves the company and their account gets deactivated, their spaces show an "Inactive Lead" status. Those spaces don't have anyone getting notified about them, which can create governance gaps if the space is still active.

The Load Scheme Details button fetches the permission, workflow, and issue type schemes for every space. It's a separate action because fetching scheme data for thousands of spaces takes time — on a 7,000-space instance, expect a minute or two. Once loaded, you can filter by scheme to find, for example, all spaces still using a legacy permission scheme you're trying to retire.

Trashed Projects

When someone deletes a Jira space, it goes to the trash rather than disappearing immediately — it's a soft delete. Trashed spaces are invisible in the main Jira UI, but they're still sitting in the background with all their configuration intact. The Trashed Projects sub-tab surfaces all of them. You'll often find spaces that were archived months ago but are still holding references to workflow schemes or permission schemes, making those schemes appear "In Use" in your audit scans.

Workflows

Most Jira instances grow significant workflow debt over time. A company that's been on Jira for five years might have 80+ workflow schemes when 10 are actively in use. The rest are leftovers from projects that ended, team reorgs, or migration efforts where someone created new schemes but never cleaned up the old ones. The Workflows tab shows you all of it.

The Details sub-tab has four sub-tabs of its own: Workflows, Workflow Schemes, Statuses, and Resolutions.

Workflows

Shows each workflow with whether it's active (in use in a scheme that's assigned to at least one space) or inactive. Click Workflow Details on any workflow to expand it and see all its transitions — including validators, conditions, and post functions — with any third-party plugin dependencies flagged. That plugin dependency information is useful before migrating spaces away from a workflow: you want to know if it depends on ScriptRunner or some other app before you move forward.

Workflow Schemes

Shows which spaces are using each scheme. The space count on each scheme tells you whether it's in use. Any scheme showing 0 spaces is a safe delete candidate. Before deleting, make sure those 0-space counts are accurate — if you recently moved spaces to a new scheme, it might be worth rescanning to confirm.

Statuses

You can check which workflows reference each status. This matters when you want to delete a status — Jira won't let you delete a status that's referenced by any workflow, even an inactive one. Use "Check Usage" first to see the full picture before trying to remove anything.

Resolutions

Same pattern. Most instances have resolutions from years ago that nothing references anymore. The default Jira resolutions (Done, Won't Do, Duplicate, etc.) can't be deleted — but any custom resolutions you've accumulated can be cleaned up here.

Work Types

Work types (what Jira used to call issue types) accumulate in similar ways to workflows. The tab shows all work types with which schemes they appear in and which spaces use those schemes. The sub-tabs split between the work types themselves and the work type schemes.

The Check Usage button on each work type scans all spaces to verify associations. If a work type isn't in any active scheme, it's safe to delete. If a scheme has 0 spaces assigned to it, that scheme's work types are also safe to clean up once you've removed the scheme itself.

Custom Fields

This is often where the most cleanup opportunity is. Large Jira instances can have hundreds of custom fields — many from apps that got uninstalled years ago, or from projects that ended. The fields stick around even after the apps that created them are gone.

The Overview sub-tab has two charts: field count by category (custom, system, plugin) and a distribution of Last Used dates by year. That second chart is usually where you see the problem — a cluster of fields last used in 2019 and 2020 still cluttering up every screen and context configuration.

The Details sub-tab has two sub-tabs: Field Details (select any field from a dropdown to inspect which screens and contexts it's on, plus recent audit log entries for that field) and All Custom Fields (the full list with filters by category, context, and last-used date).

The Last Used date

Jira tracks when a field was last written to on any issue. Not every field type is tracked — ones that aren't show a dash in the Last Used column. For the ones that are tracked, it's a reliable signal. A field last used in 2020 on an instance that's been active since is a strong candidate for deletion — but check its details first. A field might show an old last-used date because it's on a screen but rarely filled in, not because it's abandoned. Look at which screens and contexts it's in before deciding.

Permissions

Lists all permission schemes with the count of spaces using each. That space count is the key number — any scheme with zero spaces assigned is safe to delete. The lookup dropdown lets you see exactly which spaces are on a given scheme, which is useful both for confirming a zero count before deleting and for understanding the impact before making changes.

Priorities

Priorities are often forgotten in audit work, but instances can accumulate custom priority schemes that aren't assigned to any spaces. The tab shows priorities, which schemes include them, and which spaces use those schemes. Unused priority schemes can be deleted. Priority schemes with 0 spaces assigned are safe candidates.

Notifications

Lists notification schemes with a space count for each. The lookup dropdown shows which spaces are on a given scheme. Schemes with 0 spaces can be deleted. This tab is read-only for auditing purposes — actually reassigning notification schemes to spaces is done through the Scheme Management section.

Screens

Screens have a dependency chain that trips people up. Here's the hierarchy:

• Screens — the actual screen configurations (which fields appear on create, edit, view operations)
• Screen Schemes — group screens by operation type
• Work Type Screen Schemes — link screen schemes to work types within a space

You have to delete in reverse order. You can't delete a Screen that's referenced by a Screen Scheme, and you can't delete a Screen Scheme that's referenced by a Work Type Screen Scheme. The app shows these relationships clearly, so you can see which screens are referenced and which are safe to delete.

Each sub-tab (Screens, Screen Schemes, Work Type Screen Schemes) shows associations and space references. The In Use status tells you whether each item is referenced by anything above it in the hierarchy.

Dashboards & Filters

Found under Views & Boards in the sidebar. This covers Jira dashboards and saved filters. The main thing it does that Jira doesn't give you natively: it checks whether each dashboard or filter's owner account is still active. When someone leaves the company and their account gets deactivated, their dashboards and filters become effectively orphaned — they still exist, other people might be using them, but the owner is gone and can't maintain them.

The Owner Status column flags inactive owners with a red badge. Filter the list to show only items with inactive owners, select all of them, and do a bulk ownership transfer to an active admin. That's the typical workflow here — it takes about 5 minutes to clean up a batch.

Changing ownership

Select the items you want to transfer, and a Change Owner panel slides in on the right. Pick the new owner from the dropdown (it searches your user list) and click Change Owner. Done. The ownership change is immediate and shows in Jira's audit log under your account.

Agile Boards

Found under Views & Boards in the sidebar. Lists all Scrum and Kanban boards with their admin info and the filter each board is based on. Boards accumulate over time — teams spin one up for a project, the project ends, the board sits around. Some boards end up with admins who've since left the company, which means nobody's maintaining them.

The Overview shows how many boards have admins with inactive accounts. Click any board name to open it directly in Jira. Bulk delete works here — select the boards you want to remove and delete them. Each deletion is logged in the app's Activity Log and in Jira's audit log.

Attachments

JQL-driven attachment search. Enter a JQL query — something like project = MYPROJECT AND attachments is not EMPTY — and the app fetches all matching attachments up to 5,000 per search. You get the file name, size, type, author, and a link to the issue it's attached to.

After the data loads, client-side filters let you narrow by file type, size range, and author without making another API call. Bulk delete removes selected attachments directly. The CSV export uses formatted file sizes (showing "4.2 MB" rather than raw byte counts) to make the spreadsheet actually readable.

Components

Found under Governance in the sidebar. Components are per-space, so a large Jira instance can have thousands of them scattered across hundreds of spaces. The tab loads a space list with a component count per space. Expand a space to see its components. Click Check Usage on any component to see if any issues are currently assigned to it.

Components with no issue assignments get marked "Not In Use" after the usage check, and you can select them for bulk deletion. You can expand multiple spaces and do a combined bulk delete across all of them at once.

Releases / Versions

Similar to components — per-space, and you can accumulate thousands of abandoned version entries from projects that ended without anyone cleaning up. The tab works the same way: expand a space, run Check Usage (which looks at both fixVersion and affectedVersion fields), then bulk-delete unused versions.

Version deletion uses Jira's removeAndSwap API, which handles the case where a version has some issue references gracefully — it removes the version reference from those issues rather than failing the delete. You won't get stuck with a version you can't delete just because a few old issues referenced it.

The status column shows Released, Unreleased, Archived, and Overdue. Overdue means an unreleased version that's past its planned release date — these are usually good candidates for archiving or deleting if the work was cancelled.

Automation Rules

Found under Governance in the sidebar. Managing automation rules at scale requires a bit more setup: you'll need to enter your Atlassian email and an API token (generated at id.atlassian.com, not the Org API key at admin.atlassian.com — these are different). These credentials are only used during your current browser session and aren't stored anywhere.

The Overview tab shows rule health: orphaned rules (rules whose creator account no longer exists in your directory), rules with inactive actors, rules with duplicate names, and an age distribution chart. The Rules tab is the full list with search and filter.

Bulk actions: enable, disable, or delete rules. You can also transfer rule ownership and the actor (the account the rule runs as) — including to the "Automation for Jira" app user, which is what you want when cleaning up after someone who's left. To transfer to the app user, enter its account ID directly in the text field; the user dropdown is for regular accounts and won't show app users.

Bulk Delete

Bulk delete works the same way across every tab in Work Item Configuration. Here's the flow:

1. Items show an In Use / Not In Use status "In Use" means the item is referenced by an active configuration — a space, a scheme, another item. "Not In Use" means it's safe to delete. The status is determined by the scan, so if something looks wrong, rescan first.
2. Select items Check individual items or use "Select All Not In Use" to grab everything eligible at once. The selection counter shows how many you have.
3. Click Delete Selected A confirmation dialog shows the count and asks you to confirm. Review it before clicking through.
4. Progress bar runs during deletion You can see which items succeed and which fail, with the reason for any failures. Failures are usually items that became "In Use" between the scan and the delete — someone assigned a scheme to a space in the background, for example.
5. All deletions logged Every successful deletion is recorded in Jira's audit log under your account and in the app's Activity Log.

Large Instance Notes