Effective 7 September 2026. NWGG Pty Ltd operates Mercury Cloud. This notice applies to the Forge app for Jira Cloud. The separate Mercury Server policies remain in the legacy documentation.
Data Mercury processes
| Data | Purpose |
|---|---|
| Scripts and revisions | Names, JavaScript source, immutable revision identifiers, archive state, timestamps, author account IDs, and explicitly declared subject account IDs support workflows, console runs, listeners, scheduled jobs, privacy reporting, and configuration portability. |
| Automation and execution settings | Names, enabled state, pinned revision, project and event filters, issue keys, intervals, execution limits, pause state, and the account ID of the administrator who last changed execution controls govern automatic execution. |
| Run records | Origin, issue key, timestamps, outcome, duration, Jira call count, and fixed error codes provide history and troubleshooting. Mercury does not persist guest console values, returned Jira values, or arbitrary error text in run history. |
| Delivery and usage records | Hashed event or schedule identities, run identifiers, hourly and monthly counters, and recent health results enforce duplicate protection, budgets, pause controls, and status reporting. |
| Jira data used during execution | Issue fields, searches, transitions, and request results are processed so a script can run. Dry-run real issue reads current Jira data and returns proposed writes without sending them. Proposed writes and Jira response values are not retained in run history. |
Mercury records the author automatically. Administrators can declare up to 20 account IDs for other people represented in retained source, names, settings, and imports. An empty declaration means the administrator reviewed the content and asserts that no other person's personal data is present. Mercury cannot discover every person in free-form text.
Where processing happens
Mercury uses Atlassian Forge compute, Jira APIs, and Forge hosted storage. The app manifest does not configure an external remote service for app data. Atlassian scopes hosted storage to each app installation.
Forge hosted storage supports Atlassian data residency. When an eligible Jira site is pinned, Atlassian hosts and migrates the app's hosted data with that site. Forge may sometimes execute an invocation outside the host product's location for platform reliability.
Sharing and access
Mercury sends Jira requests through Atlassian APIs and does not send app data to an operator-run remote database. Atlassian processes Forge-hosted data as the platform provider under its own terms and Forge data-processing commitments.
Workbench actions require a signed-in Jira administrator. Workflow and automation runs use the Mercury app identity and the Jira scopes granted during installation.
Retention and deletion
Run history metadata and delivery claims expire after 30 days. Hourly usage counters expire after three days. Monthly usage counters and health records expire after 365 days. One-use live-run confirmations expire after five minutes and their storage records have a one-day expiry. Scripts, immutable revisions, automation settings, usage controls, and import idempotency records remain while the app is installed.
A keyed pseudonymous reporting receipt remains only until the subject's next report is allowed; it contains no raw account ID. A keyed barrier for an account that Atlassian reports as closed remains while the app is installed to prevent recollection.
After uninstall, Forge hosted storage follows Atlassian's hosted-storage lifecycle. Atlassian currently documents a 28-day retention period. A reinstall does not automatically restore that data. Recovery requires customer consent and an Atlassian request within 21 days.
See the data retention page for the complete table.
Reporting and erasure
Mercury checks hourly for due privacy work and uses a seven-day default reporting cycle. After reporting, Mercury keeps a keyed pseudonymous receipt until the subject's next report is allowed, then removes it. The receipt contains no raw account ID.
A closed or updated response from Atlassian queues erasure of declared content. Erasing one subject deletes each associated script or revision and dependent automation, which can affect other administrators. Manual administrator erasure removes current data, but a later explicit author action can store fresh data for that account. Only an Atlassian Privacy API closed response creates a keyed pseudonymous barrier that prevents recollection while the app remains installed. The barrier is not anonymous data.
Jira administrators can review the subject inventory, request one-subject erasure, purge installation personal data, and classify unreviewed legacy source. Installation purge leaves execution paused and preserves keyed closed-account barriers. These controls do not require an active license. Mercury's KVS erasure cannot purge older Forge platform logs, old embedded Jira workflow configurations, or exported files. Those copies follow their platform or customer-controlled lifecycle.
Your choices
A Jira administrator can disable automations, pause new execution, archive scripts, export portable configuration, use the privacy controls, or uninstall the app. Imported automations remain disabled until an administrator reviews and enables them.
Email plugin-support@johno.it for a private data or privacy question. Use Mercury support for ordinary product help. Do not include Jira data, script source, account identifiers, or security details in a public issue.