← Prunewell
DocumentationPrivacyEULASupport

Prunewell documentation (public knowledge base source)

Getting started

  1. Install Prunewell from the Atlassian Marketplace. Only Jira admins can open it: Jira settings > Apps > Prunewell.
  2. On Overview, click Start scan. The scan reads your configuration in the background (about two minutes for a site with 50 spaces; up to about an hour on very large sites). You can leave the page.
  3. When it finishes, use Where used, Unused and Migration check. Reports always show the time of the scan they use. Scan again after big configuration changes.

Prunewell is read-only until a Jira admin turns on Allow cleanup actions in Settings.

What a scan reads

Spaces, custom fields (screens, contexts and Jira's last-used date), groups and member counts, statuses, project roles and their members in each space, screens, screen schemes, work type screen schemes, workflows (statuses, transition screens, and the groups, roles, fields and screens named in conditions, validators and post functions), workflow, permission, notification, security and field configuration schemes and which spaces use them, filters (JQL, sharing, editors, owners, subscriptions, favourites, last use), dashboards (sharing and the filters their gadgets show) and boards (filter, column statuses, estimation field).

Filter JQL is read by Jira's own parser, so cf[10044], field names, membersOf() and filter = 123 are all found. A filter with JQL errors is reported as broken.

What a scan can't see: automation rules (Forge apps can't read them), board administrators, quick filters and swimlanes, global permissions and product access, service management queues, SLAs and request types, and settings other apps keep in their own storage. Legacy dashboard gadgets that keep their settings outside Jira's API are counted on the Overview.

Where used

Search by name or id, optionally limited to one type, and open a result. Used by lists every place that uses it, grouped by type, with where exactly (for example "Grants BROWSE_PROJECTS" or "Condition on Approve"). It uses lists what a filter, workflow, board or scheme points at. Show as CSV gives both lists for your change ticket.

Unused and stale

Pick a type. Each line says why it is listed:

  • Custom fields: on no screen and used nowhere we can read; or no value changed for longer than "stale after" (Settings, default 365 days). Locked fields (Sprint, Rank, app fields) are never listed.
  • Filters: owner deactivated or deleted; JQL errors; or not on any board, dashboard or other filter with no subscriptions, no favourites and no recent use.
  • Groups: referenced by no scheme, role, workflow, filter or dashboard. Groups such as jira-software-users-... may grant app access in Atlassian Administration; check there.
  • Statuses: in no workflow and on no board. Workflows: not in any workflow scheme.
  • Schemes and screens: not used by any space (or, for screens and screen schemes, by any scheme or transition). Jira's defaults and team-managed items are never offered for deletion.
  • Dashboards with a deactivated owner or no gadgets; boards whose filter is gone or broken.

Groups, roles, security schemes, field configuration schemes, dashboards and boards are report-only.

Deleting safely

  1. Settings: turn on Allow cleanup actions (this is logged).
  2. Unused: tick items (up to 50) and click Preview delete. The preview re-reads each item in Jira and skips anything in use now, renamed or protected, with the reason.
  3. Type the phrase shown (for example DELETE 3 ITEMS) and click Delete. The preview is yours only and expires after 15 minutes.
  4. For each item Prunewell reads it again, checks it again, saves a JSON export, then deletes it as you, so Jira's own rules apply (Jira refuses to delete an active scheme or workflow). Custom fields go to Jira's trash.

Restoring

History lists every export. Restore brings a custom field back from Jira's trash with its values, or recreates a filter, screen (with tabs and fields), screen scheme, work type screen scheme, workflow scheme, permission or notification scheme, or status from the export. Recreated items get a new id: attach them to spaces or boards again. A filter whose JQL is no longer valid can't be recreated as is; copy the JQL from View JSON and fix it. Workflows are export-only.

After your Data Center migration

Open Migration check right after each migration wave:

  • Likely duplicates: names that are the same once "(migrated)", "(copy)", "Copy of", case and spacing are ignored, side by side with how much each is used (custom fields only cluster with the same field type). Keep the one in use, move spaces and filters to it, then remove the rest.
  • The checklist links to the Unused reports that matter most after a move: unused fields and schemes, inactive workflows, orphaned statuses, filters with JQL errors, filters and dashboards owned by people who didn't move, boards with broken filters, and orphan groups.

Settings

  • Allow cleanup actions (off by default).
  • Count fields and filters as stale after N days (30 to 3,650, default 365).
  • Keep the audit log and exports for N days (90 to 3,650, default 730).

Permissions and data

Admin-only. The scan runs as the app and only reads; deletes and restores run as the admin who confirms them. Everything is stored in your site's Forge storage; nothing leaves Atlassian.