Back up, restore and delete app data

2 min read

Global settings → App data is where you take a backup of everything people have built, restore it if something goes wrong, and remove the app’s data entirely if you ever need to.

i
Worth doing periodically. A backup is one click and one file. Take one before a bulk delete, before handing the site to someone else, or just on a schedule.

Taking a backup #

Download backup gives you a JSON file containing, for every filter (active and archived alike):

  • The filter itself and its administrators
  • All seven configuration collections: quick filters, field controls, smart rules, queues, custom values, custom ratios and time series
  • Its views

It’s named with the date and time (advanced-filters-backup-2026-09-15-1430.json) and carries a checksum that a restore verifies before reading anything.

Left out on purpose: personal favorites, presets and dismissals; gadget bindings (they name dashboards a restore can’t re-point); and any Jira work item data.

The Back up configurations section with its opening sentence, the Download backup button, and the flag confirming how many filters were backed up.
A backup covers every filter’s configuration and administrators.

Restoring #

Before you choose a file, the panel says what a restore does. Every filter in the file is added as a new filter with a new id, even when the backup came from this installation, and a filter whose name is taken is skipped. Nothing already on this installation changes.

Two steps, and the first one changes nothing.

  1. Choose a file and select Review restore. You get a dry run: how many filters the file holds, how many would be restored, and how many would be skipped, each with a reason (Name already taken, Jira filter not available to you, Installation is full, and so on).
  2. Restore the filters appears only once the dry run confirms something would actually change.

Afterward the report lists every filter in the file as Restored or skipped, with the reason.

i
The trade-off of the new id: gadgets pointing at the original keep pointing there, and need re-pointing at the restored copy by hand.

Backups taken on a different installation are accepted, and older backup files still restore. Files can be up to 64 MB.

If a restore stops part way it shows you what it had already written and hides the button, so the same half-applied file can’t be run again by accident.

The Restore from backup section with its two opening sentences and, beneath them, a dry-run report in which every row reads Name already taken.
The dry run names every filter’s outcome before anything is written.

Deleting all app data #

At the bottom of the panel, collapsed and in red: Delete all app data.

This removes everything the app stores: every advanced filter, view, administrator, favorite, preset, share link, recorded usage, access policy and audit record. Your Jira dashboards survive; their Advanced Filters gadgets stop working. Take a backup first.

It’s also the one action that widens permissions: access policies reset to their defaults, so creating advanced filters opens back up to everyone logged in.

The red Delete all app data disclosure, collapsed, with its dangerous-and-irreversible hint beside the label.
Collapsed by default, and marked dangerous in words as well as color.

The safeguards #

  • Request deletion stays disabled until you type the exact number of filters the installation currently holds. The server recomputes that number when you submit, so a stale page can’t confirm an out-of-date count.
  • There’s then a 7-day grace period. Any Jira administrator can cancel it right up until the sweep begins, and the page shows who requested it and when it will run.
The expanded delete-all form, its confirmation field empty and Request deletion still disabled.
Type the installation’s own filter count back to enable the button.

While a request stands, other administrative writes (policy saves, bulk operations, restores) are refused, though everyday use of the app carries on. Once the sweep starts it can’t be canceled, and if it’s interrupted the next scheduled run resumes it.

Who can do what here #

Everything on this panel is reserved to a Jira site or organization administrator and can’t be delegated. There’s one exception: taking a backup can be delegated through the Export usage and backups grant. See Access policies.