The app runs entirely on Atlassian's infrastructure. It sends no retro content, personal data or votes to us or to any third party. We operate no servers and keep no copy of your data; we only see what you choose to send us in a support request.
What the app stores
In Atlassian's Forge hosted storage, inside your own Atlassian cloud instance:
- Retros: name, team, columns, sprint, settings, who moderates and who may open it (Atlassian account IDs), its current step, and the vote totals once it ends.
- Cards: their text and grouping. A card in a named retro also stores its author's account ID. A card in an anonymous retro does not: while the retro is open it carries a code, unique to that card, that lets its writer edit it.
- Votes: from the vote step until the retro ends, one record per voter holding only counts per card, stored under a key derived from the retro's secret, never under an account ID.
- A secret per retro, used to derive the card codes and voter keys.
- Actions: their text, status, who created and settled them, and the key of a linked Jira issue.
- Presence: the account IDs of people with an open retro on screen, each expiring after 60 seconds.
- Access checks: whether Jira allows each person to see the project and each linked issue. An answer is relied on for at most 10 minutes, then asked again.
What is deleted, and when
When a retro ends, the app deletes the per-card edit codes, every per-voter vote record, the retro's secret and its presence records, and checks that the codes, vote records and secret are gone before marking the retro as ended. From then on, the app holds nothing that attributes an anonymous card to the person who wrote it.
- What stays: card text and how cards were grouped, the vote totals, the actions and their links to Jira issues, and — in a named retro only — each card's author.
- Ended before the reveal: the cards themselves are deleted.
- Automatic end: after 14 days, an open retro becomes eligible for automatic closure. An hourly job processes pending closures, including any that were interrupted; deletion may take longer when work is queued or an attempt needs retrying.
- Presence: a presence record written just as a retro ends can outlive it by up to 60 seconds before it expires.
Who can see what
| Who | What the app guarantees |
|---|---|
| Other participants and moderators | In an anonymous retro they never see who wrote someone else's card; during the Write step each person sees only their own. While people write and vote, the app shows no counts and sends no update for each card or vote; cards are revealed in random order and carry no time. They do see who is present. One residual signal: a retro holds at most 300 cards, so someone who fills it to the limit can notice when others add one. In a named retro, authors and card counts are shown by design. |
| People outside the retro | A retro opens only for its moderators and the people it was shared with (or the whole project, if its moderators chose that), and only for people Jira lets see the project. A linked Jira issue shows only to people Jira lets see it. |
| Site administrators | The app does not disclose who wrote another person's anonymous card through any screen or API. During the Write step, each person can see and edit their own cards. Forge storage is readable only by the app's own code. |
| Vantelia, the app's developer | We have no servers and no copy of your data, but the app's code runs in your instance. While an anonymous retro is open, that code can match a card to its writer — that is how it shows you, and only you, your own cards while you write. It never shows that link to anyone else and never logs it, and the data that makes it possible is deleted when the retro ends. |
| Atlassian's platform | We make no claim about backups or copies kept by Atlassian's infrastructure. |
| Anyone, by inference | In a small team, writing style or content can give an author away. No app can prevent that. |
What the app does not do
- It does not store names, email addresses or IP addresses. Names and avatars on screen are rendered by Jira from account IDs; for a named retro's export, display names are read from Jira at that moment and not kept.
- It does not use AI, cookies, analytics, tracking or advertising.
- It sends nothing to any third party and has no sub-processors. Exports to CSV or Markdown are made by the people using it.
- It makes no network calls outside Atlassian. It qualifies for Atlassian's Runs on Atlassian programme, which Atlassian verifies automatically.
- It writes nothing to Jira as itself. An action's issue is created from the person's own browser, as that person.
Why each permission is requested
| Permission | Why it is needed |
|---|---|
storage:app | Stores retros, cards, per-card codes and per-voter records (both deleted when a retro ends), actions and short-lived presence, in Forge hosted storage inside your instance. |
read:jira-work | Reads the summary and status of issues linked to actions, and finds an action's issue by its entity property, so a lost answer from Jira is reconciled instead of retried automatically. If a person confirms an issue was not created and it was, a duplicate can still result. |
write:jira-work | Creates an action's issue, from the person's browser and as that person, so Jira applies their own permissions. |
read:jira-user | Checks that each person can see the project and each linked issue before showing them, and reads display names for a named retro's export. |
read:project:jira | Required with the board permission to list a project's boards. |
read:board-scope:jira-software | Lists the project's boards to find its sprints. |
read:sprint:jira-software | Lists sprints, so a retro can be tagged with the sprint it looks back on. |
Where the data lives, and for how long
In Atlassian's Forge hosted storage, within the Atlassian cloud environment of your own instance and subject to its data residency. Ended retros stay until the app is uninstalled. On uninstall, Atlassian soft deletes the app's data and keeps it for 28 days before permanent deletion; within 21 days a reinstallation can be relinked to it, only at your request.
Legal basis and your rights
Where the GDPR applies, your Atlassian instance administrator is the data controller for the data described above. It is created and kept inside your own instance and we do not receive a copy of it; our position is that we act as neither a data controller nor a data processor in respect of it.
What the app offers today: during the Write step, before cards are revealed, each person can edit or delete their own cards; any participant can export a retro's results from the Discuss step on; ending a retro deletes its authorship data as described above. Ended retros cannot yet be edited or deleted one by one from the app; uninstalling the app removes all of its data, subject to Atlassian's retention. For anything else, contact soporte@vantelia.es.
Support data
If you contact support, we receive whatever you choose to include. Please keep card text out of support requests.
Changes
Material changes will be reflected here and the "Last updated" date revised.