Retention while installed
| Record | Retention | Reason |
|---|---|---|
| Scripts and immutable revisions | While installed | Run workflows and pinned automations; support review, archive, restore, and export. |
| Automation definitions | While installed | Store listener and schedule configuration. Imported definitions start disabled. |
| Execution controls | While installed | Apply pause and usage settings. Settings include the account ID of the administrator who last changed them. |
| Hourly usage counters | 3 days | Enforce the UTC-hour limit. Counters are operational records, not a billing ledger. |
| Monthly usage counters | 365 days | Enforce the UTC-month limit and show bounded usage history. Counters are operational records, not a billing ledger. |
| Health records | 365 days | Show the latest bounded success or failure, including failures that occur before normal run history starts. |
| Run history | 30 days | Show outcome metadata and fixed codes for workflow, console, listener, schedule, simulation, and dry-run behavior. Guest console values, proposed writes, Jira response values, and arbitrary error text are not retained. |
| Delivery claims | 30 days | Suppress a known duplicate workflow event, listener event, or schedule bucket. |
| Live-run confirmation record | Token valid for five minutes; record expires after one day | Bind one administrator, one issue key, and exact source to a single live-run approval. |
| Import idempotency record | While installed | Make a repeated import of the same bundle safe and reject changed content that reuses a bundle ID. |
| Reporting receipt | Until the subject's next reporting cycle is due | Keep a keyed pseudonymous proof of the prior report so Mercury does not report the subject too early. The receipt stores no raw account ID and is removed when the next report becomes eligible. |
| Closed-account barrier | While installed | Keep a keyed pseudonymous value that prevents a closed account from being collected again. This value is pseudonymous, not anonymous. |
Export and import
A portable export contains each script's current source, its personal-data declarations, archived current source, older source snapshots required by pinned automations, and up to 25 automation definitions. An export can be created while automations are enabled, but definitions in the bundle are disabled. It excludes history, claims, confirmations, health, usage, pause state, license state, and installation identifiers. The exporting organization controls the resulting file and is responsible for deleting its copies.
Import creates each source snapshot as a new standalone script with a new local ID rather than recreating a complete historical revision chain. Automation definitions also receive new IDs and remain disabled. Repeating the same bundle is idempotent while Mercury remains installed. Changed content that reuses a bundle ID is rejected.
Legacy and platform copies
Source created before personal-data declarations is marked unreviewed until a Jira administrator inspects every script and revision, then declares up to 20 represented account IDs or confirms that none are present. Backup includes current and pinned source but can omit older unpinned revisions.
Schema 1 and 2 workflow configurations embed source in Jira outside KVS. Mercury rejects those old rules at runtime. An administrator must reopen and save each rule as a schema 3 revision reference or remove it, and rollout requires verification that no embedded configuration remains.
Installation purge leaves execution paused and preserves keyed closed-account barriers. Mercury no longer persists guest log values or arbitrary error text. KVS erasure cannot purge older Forge platform logs, old Jira workflow configurations, or exported files. Those copies require their platform or customer-controlled retention and deletion process.
After uninstall
Mercury uses Forge hosted storage. Atlassian currently documents that hosted data is retained for 28 days after uninstall. Reinstalling does not automatically reconnect the old data. With customer consent, an app developer can ask Atlassian to relink it when the request is submitted within 21 days of uninstall.
These uninstall periods are controlled by Atlassian and can change. Check the current Forge storage documentation before relying on a recovery window.
Data residency
Persistent Forge hosted storage follows Atlassian's data residency controls. Atlassian documents that eligible app data is pinned and migrated with the host Jira site. Mercury does not configure an external app-data remote.
Read Forge data residency and the hosted storage lifecycle.