How to find unused custom fields in Jira Cloud and check where a field is used

Name: Field Sweep demo video
Uploaded: 2026-10-29
Duration: 30 s
Description: A short demo of Field Sweep.

Before you delete a custom field you want to know that nothing uses it. Jira has no single answer to that. Here is what the built-in tools tell you, what you must check by hand, and one option.

Hullspark · updated 2026-10-29

Short answer

On Premium and Enterprise: the Site optimizer lists fields that are used in no space, context or screen, with a last-used date [1]. Atlassian's page does not say whether it also checks filters, boards or dashboards [1].
On every plan: the page on deleting a field describes no way to see where a field is used before you delete it [2].
Safety net: a deleted field is tagged for deletion in 60 days, and you can restore it with its data from the Deleted fields tab [2]. It is removed from automations, advanced workflow functions and apps meanwhile [2].

What Jira gives you out of the box

Jira’s built-in ways to check a custom field
Tool	Good for	Catch
Fields list (Settings, Work items, Fields)	Finding a field, then More actions and Delete or restore [2]	The page describes no view of where a field is used
Site optimizer, Custom fields (Premium, Enterprise)	A list of fields used in no space, context or screen, with type, contexts, screens, last-used date and a recommendation [1]	Not on other plans. The page does not say how the last-used date is worked out or whether filters, boards and dashboards are checked
An advanced (JQL) search on the field	Whether any work item still holds a value in the field [3]	It does not show a filter, board or dashboard that mentions the field
Delete and restore	Undoing a mistake within 60 days [2]	It is the safety net, not a check. Automations and apps lose the field while it is in the trash

Doing it by hand

List the custom fields from the Fields screen and pick candidates. On Premium and Enterprise the Site optimizer gives you a first list.
Search for work items that hold a value in each candidate, for example "Field name" is not EMPTY in advanced search [3]. If two fields share a name, use the ID form, for example cf[10010] is not EMPTY, where 10010 is the number after customfield_. An empty result means no work item holds a value now.
Open your saved filters, boards and dashboards and look for the field. Atlassian's pages describe no single list of references.
Export your automation flows (Settings, System, Automation flows, More actions, Export flows) and search the file for the field's name and its ID (customfield_ followed by digits).
Open the workflow transitions that might use it: conditions, validators and post functions.
Ask the field's likely owner. A field used for a yearly report looks unused for eleven months.
Delete in a small batch, write down the date, and use the 60-day window to catch what you missed [2].

Where the built-in way stops

No usage answer in one place. Filters, boards, dashboards, automation and workflows are separate screens.
Same name, different fields. Two fields can share a name, so a search by name can hit the wrong one.
No record. Jira keeps a deleted field for 60 days, but not your reasons or the evidence for each one.
The check goes stale. A field that nothing used last month can be in a new filter next month.

One option: our own app

I make a Jira Cloud app for the filters, boards and dashboards part, Field Sweep by Hullspark [4]. What it does, as the current code and the product page describe it:

A scan that only reads. It reads your saved filters, boards and dashboards and sorts every custom field into Can clean up, To review or Nothing found. A field is Can clean up only when the scan found no filter, board or dashboard reference, it is on no screen, no other field shares its name, and Jira shows no recent value change. “No change recorded” does not cover values set before Jira began tracking, so check it against real work items.
What uses a field. The Fields tab shows each field's screens, contexts, last-used date and references. References opens the list of saved filters, boards, quick filters and dashboards that use it. Fields that share a name are marked.
A plain list of what it could not read. Automation flows, workflows (conditions, validators and post functions), dashboards not shared with you, and swimlanes and card layout are never read. The Overview lists what it could not read instead of showing zero.
Trash and restore, after a review. A Jira administrator can move unused fields to Jira's trash from the app. Before anything moves, the app checks each field with Jira again and shows a review. The Moved to trash tab lists each field with a Restore button. Jira deletes a trashed field for good after 60 days.
Your rules and a CSV. You set how many days without a value change counts as unused, exclude field IDs, and export the result.

It never deletes a field for good. Only Jira administrators can open it, and the scan runs with that administrator's permissions. Moving a field to the trash needs a license and a scan from the last 24 hours. Check automation and workflows yourself before you move a field.

Field Sweep demo video thumbnail — Demo video. Nothing loads from the video host until you press play.

See it on the Atlassian Marketplace Product page

Questions

Does Jira show where a custom field is used?

Atlassian's page on deleting a field describes no such view. The Site optimizer on Premium and Enterprise lists fields used in no space, context or screen, and its page does not say whether it checks filters, boards or dashboards.

Can a JQL search tell me a field is unused?

Only that no work item holds a value. A filter, board or dashboard can still refer to the field, so you check those separately.

Can I get a deleted field back?

Yes, within 60 days, from the Deleted fields tab, with its data. After that Jira removes it for good.

Does Field Sweep read automation flows?

No. It also does not read workflows (conditions, validators and post functions), dashboards not shared with you, and swimlanes and card layout. The Overview lists these gaps so you can check them by hand.

Does a scan change anything?

No. A scan only reads. The app writes to Jira only when an administrator moves a field to the trash or restores it.

Does my data leave Atlassian?

No. The app runs on Atlassian. Details are in the privacy policy.

What needs a license?

The Fields list, Settings, the CSV export and moving fields to the trash need an active license. The Marketplace listing has the current pricing.

What I have not verified

I checked the Jira claims on this page against Atlassian's documentation on 2026-10-29. I did not re-test each one on a live site, and Atlassian changes plans and screens.

Atlassian's delete page mentions the Site optimizer for Enterprise, while the optimizer page says Premium and Enterprise. I did not confirm the exact JQL wording for every field type. I make no claim about the columns of Jira's Fields screen beyond what the pages above state. The steps on exporting automation rules and checking workflow transitions are general practice, not taken from a cited page. The app description comes from its current code and product page. I have not tested other vendors' apps and name none; read their listings.

Sources

[1] Atlassian Support: Optimize your custom fields: https://support.atlassian.com/jira-cloud-administration/docs/optimize-your-custom-fields/
[2] Atlassian Support: Delete or restore a field: https://support.atlassian.com/jira-cloud-administration/docs/delete-or-restore-a-field/
[3] Atlassian Support: JQL fields: https://support.atlassian.com/jira-software-cloud/docs/jql-fields/
[4] Atlassian Marketplace listing of the app (fetched 2026-10-29): https://marketplace.atlassian.com/apps/439033528

Questions? Support or support@hullspark.com. Privacy policy