Privacy policy: Merge Duplicate Requests
Last updated: 1 November 2026
Merge Duplicate Requests is made by Stacix ("we"). This policy explains what the app stores and who can see it.
Summary
- The app runs entirely on Atlassian's Forge platform. It does not send any data to us or to any other server.
- We cannot see your data. It stays in your Atlassian site.
- Everything a merge copies (notes, attachments, replies) is written into your own Jira requests, with your agents' permissions.
- The app's own storage keeps only settings and a record of each merge, with Atlassian account IDs (no names, emails or request content).
What the app stores
In your site's Forge storage (hosted by Atlassian, in the same data region as your Jira site):
- Settings your Jira admins choose: the customer message, closing status, resolution, link type and attachment options.
- A record of each merge, so the Merged requests panel can show it and Undo can reverse it: the request keys, when it happened, the Atlassian account ID of the agent who merged, the account IDs of the people added to the main request (or who couldn't be added), and the IDs of the comments, attachments and links the merge created. No names, email addresses, request summaries or comment text.
- Which requests were merged, so replies to them can be passed on to the main request, and a marker per passed-on comment so it's only passed on once.
Once a week the app reports the stored account IDs to Atlassian, as Atlassian's privacy rules require. If someone's Atlassian account is closed, their ID is removed from every merge record.
What the app reads and writes in your site
The app asks Atlassian for these permissions and uses them only as described. All requests are made as the agent using the app, except passing on replies to merged requests (see below).
| Permission | Used for |
|---|---|
read:jira-work |
Reading the requests being merged: summary, description, comments, attachments, status, links; finding likely duplicates; checking admin rights for the settings page |
write:jira-work |
Adding the internal note and summary, copying attachments, linking and labelling the duplicate, closing it, and reversing these on Undo |
read:servicedesk-request |
Reading request participants and the portal link of the main request |
write:servicedesk-request |
Adding people to the main request, and posting the reply to the duplicate's requester |
read:jira-user |
Showing who merged and who was added, by name, in the Merged requests panel (looked up live, not stored) |
storage:app |
Saving settings and merge records in Forge storage |
The app also listens for new comments on requests. It acts only on comments added to a request that was merged, and copies them to the main request as an internal note. This runs as the app, because nobody clicked anything.
Data residency
The app keeps its data in Forge hosted storage, which supports data residency. If your organization pins Jira to a location (for example the EU, the US or India), the app's data is stored in the same location and moves with it.
- In scope (pinned with your site): everything listed under "What the app stores".
- Out of scope: nothing the app controls. Notes, attachments and replies the app creates are ordinary Jira data and follow your Jira site's residency.
Sharing
We don't sell, share or transfer your data. We have no access to it. Atlassian hosts it as part of the Forge platform under Atlassian's privacy policy.
Retention and deletion
- Merge records are kept while the app is installed, so merges can always be undone and audited.
- If you uninstall the app, Atlassian keeps Forge-hosted app data for 28 days in case you reinstall, then deletes it (Atlassian Forge storage).
- Notes, attachments, links and replies the app created in your requests stay there like any other Jira content; Undo removes the ones it can.
Children
The app is a business tool and isn't directed at children.
Changes
We'll update this page if the app starts storing anything new, and change the date above.