| App | UndoTrail for Jira (Atlassian Forge app) |
| Provider | Astrospray Limited, a company registered in England and Wales, number 10903246, registered office 47 St James Avenue, Upton, Chester, CH2 1NB, United Kingdom |
| Contact | legal@astrospray.com · Security: security@astrospray.com · Support: help@astrospray.com |
| Effective | 28 September 2026 |
| Version | 1.1 |
In one paragraph
UndoTrail runs entirely inside Atlassian’s own cloud on the Atlassian Forge platform. It has no egress permission, which Atlassian enforces at the platform level: the app cannot send your data outside Atlassian, to us or to anyone else, and we cannot read your Jira site or the app’s storage. If people use the app’s Rovo agent, Atlassian Rovo writes its answers under Atlassian’s own terms, using Atlassian’s sub-processors. Most of what the app shows is read live from your Jira site, in your browser, using your own Jira permissions. A small amount of data is stored inside Atlassian’s Forge storage for your site, chiefly snapshots of work items so that deleted ones can be restored.
What the app processes, and why
| Data | Why | Where it is stored | How long |
|---|---|---|---|
| Work item change history (who changed which field, from what to what, when) | To show, filter and export the report you asked for | Not stored. Read from Jira on demand, in your browser | Only in memory while the page is open |
| Snapshots of work items (summary, description, type, priority, status, labels, components, assignee, reporter, due date, parent, subtask keys and custom field values) | So a work item deleted later can be restored with its fields | Atlassian Forge key-value storage, inside your Atlassian cloud instance | Live snapshots are replaced on each change and kept while the work item exists (from a project deleted permanently, until the app is uninstalled); snapshots of deleted items expire automatically after your retention setting (default 90 days, 1–365 configurable by a Jira admin) |
| Deleted-work-item records (as above, plus who deleted it and when) | The “Deleted items” list and restore | Forge storage | Retention setting, then deleted automatically by Atlassian |
| Comment versions (text of each version, author, timestamp). On by default; a Jira admin can switch it off, or exclude projects | Jira keeps no record of edited or deleted comments; this restores that audit trail | Forge storage | Until an admin erases it, or the app is uninstalled |
| View records (Atlassian account ID and timestamp). On by default; a Jira admin can switch it off, or exclude projects | To show who opened a work item | Forge storage | The most recent 500 per work item (older ones are dropped), until an admin erases them, the person’s Atlassian account is closed, or the app is uninstalled |
| Saved views and app settings (names, queries, retention, permissions, redeemed access code) | So your reports and configuration persist | Forge storage | Until deleted by a user or the app is uninstalled |
| Scheduled reports and signed-export records (the owner’s or signer’s account ID and display name, plus the query) | To run reports on a schedule, and to verify an exported file later | Forge storage | Until deleted, or the app is uninstalled |
The app requests these Atlassian scopes and nothing else: read:jira-work, write:jira-work (only for restoring a deleted work item and for reverting a change you explicitly ask it to revert), read:jira-user, storage:app, report:personal-data (the weekly report of stored account IDs Atlassian requires, so closed accounts are erased), and read:board-scope:jira-software, read:project:jira, read:sprint:jira-software (read-only, to list boards and sprints for the report’s sprint picker), and read:group:jira, read:user:jira, read:avatar:jira (read-only, to find who is in a group picked in the report’s Changed by group filter; only account IDs are kept).
What we, the provider, can see
We cannot read your Jira site or the app’s storage. We have no access to Forge storage for your installation, no network endpoint to receive your data, and no back door. If you contact support, you choose what to share with us in your message.
Atlassian shares the app’s operational logs with us, as it does with every app’s developer, so a failed operation can be traced. They record operation outcomes, error types and counts, identifiers such as work item keys and scheduled report names, and, when a call fails, the error message Jira returned, shortened; see Logging. An organization admin can switch this sharing off in Atlassian Administration, under Connected apps.
Atlassian also provides us with commercial information about installations (site name, licence tier, contact details supplied when you install or buy), and the usage metrics and installation details it gives every app’s developer, such as how often the app’s functions run and fail, and which sites it is installed on. These hold no Jira data. We use all of this only to run the business: licensing, support, invoicing and product decisions.
Legal basis (UK GDPR / EU GDPR)
For personal data inside your Jira site (names, account IDs, anything your team typed into a work item) you are the controller and we are not a processor of it, because we never receive it: processing happens within your own Atlassian instance under your agreement with Atlassian. Atlassian is your processor and sub-processes on your behalf.
For the commercial information above, we are the controller, and our legal basis is legitimate interest (running and supporting a paid product) and, where applicable, contract.
Data residency and sub-processors
App data is held in Atlassian Forge storage in the region Atlassian assigns to your site, under Atlassian’s own data-residency programme. We add no sub-processors of your Jira data: the app cannot send it outside Atlassian. If people use the app’s Rovo agent, Atlassian Rovo writes its answers under Atlassian’s own terms, using Atlassian’s sub-processors. Our own business systems (payments, invoicing) are operated by Atlassian Marketplace.
Your rights
Because your work-item data stays in your Atlassian instance:
- Access and export: the history report exports to CSV and Excel, and the Reports tab also exports to PDF; Jira’s own export and API cover the rest.
- Deletion: deleting a work item’s data is a Jira operation. When a work item is deleted, the app’s snapshot of it becomes a deleted-item record, which expires on the retention schedule; live snapshots are kept as the table above describes. After the app is uninstalled, Atlassian keeps its storage for your site for 28 days and then deletes it. A reinstall starts empty; to have it reconnected to the earlier data, contact us promptly, because Atlassian must receive the request within 21 days of uninstalling.
- Erasure of a person’s data: this happens in two ways. When a person’s Atlassian account is closed, the app’s weekly check erases their view records and removes or anonymises their account everywhere else the app stores it (see the next point); a name typed or @mentioned in captured comment text, or an account ID written into a saved JQL query, stays as written. And a Jira admin can erase captured comment history and view records from the app’s admin page, for the whole site or for one project; erasing works by site or project, not for one person alone. An admin can also exclude projects from tracking so nothing further is captured.
- Closed Atlassian accounts: the app reports the account IDs it stores to Atlassian’s personal data reporting API every week. When Atlassian says an account has been closed, the app erases that person’s view records and onboarding progress, removes them from stored work item snapshots, and shows them as “Former user” wherever a record has to keep its shape (comment versions, signed-export records, saved views, scheduled reports). Changed display names are refreshed the same way.
- For the commercial information we hold, contact legal@astrospray.com; we respond within 30 days.
Telling your people
Comment history and viewer history are on by default, because an audit trail with gaps in it is not an audit trail. Both record what your own staff do in Jira, so if you are subject to UK/EU GDPR or similar rules, tell your staff that this is being recorded, and why, as you would for any other monitoring. Either can be switched off entirely, or excluded per project, under Jira settings → Marketplace apps → UndoTrail, and captured data can be erased from the same page.
Children
The app is a business tool and is not directed at children.
Security
See the Security and data-handling statement. Report vulnerabilities to security@astrospray.com; we acknowledge within one business day.
Changes
We will update this page when the app changes what it stores. Material changes are announced in the app’s release notes and on the Marketplace listing. The version and effective date above always reflect the current text.