You are over the field limit and need to delete something. This works out how far safe deletions get you, and whether cleanup alone will be enough. Runs in your browser — nothing is sent anywhere.
Enter your numbers below.
| Custom fields in this spacethe number you are trying to bring down | |
| The limit700 per space unless Atlassian has changed it |
Count each field once. A field that is both unscreened and empty belongs in tier A only — do not also count it in B or C, or the total will lie to you.
| Tier | Count |
|---|---|
| A — safeon no screen and holding no data in any work item | |
| B — likelyholds data, but nothing has written to it in 12+ months | |
| C — review firstduplicates by name, or suspected obsolete but still in use | |
| Blockedlocked or managed by an installed app — you cannot delete these |
| If you delete | Fields left | Against the limit |
|---|---|---|
| Fill in the numbers above. | ||
Deleting a custom field in Jira destroys its data, and there is no undo. A field that looks dead often has one dashboard or one automation rule quietly depending on it. Check every one of these first:
Safer order: remove the field from all screens first, wait a sprint, see what breaks, and only then delete. A field that is off every screen counts against nothing you care about visually, but still counts against the limit — so this buys you time, not headroom.
If deleting everything deletable still leaves you over, the problem is structural rather than hygienic. The usual answers are splitting the space, consolidating near-duplicate fields into one with a shared context, or moving per-team fields into contexts on a single field instead of separate fields per team.