Privacy policy

Applies to Doorman for Jira, Super SLA and Precheck, the Altoria apps for Jira Cloud named below. Last updated 27 October 2026.

What each app stores

Doorman for Jira

Formerly Access Audit, and before that Access & Change Governance.

Snapshots of your Jira configuration: user display names and account ids, group names and memberships, project roles, permission schemes, application role assignments, and the field inventory (field names and types, the projects their contexts cover, how many screens and saved filters use them, and when Jira last saw each used).

Change records: what changed, when, the source of the record, and the account id of the actor when one is known. Copies of your Jira audit log records.

Access review rounds and their decisions, each with the deciding account, the time and the reviewer's note. A log of exports, with who made each one, when, and its SHA-256 digest.

Super SLA

Every SLA cycle on every service project issue: start, stop and breach times, goal, elapsed time, and whether it breached. For each cycle, the account id and display name of the issue's assignee at the last read and of the assignee at the moment of breach, taken from the issue history. The before and after of any cycle that Jira recalculated. A list of service project issues with no SLA cycle. With each cycle, the issue key and project key, and the priority, request type and customer organisation names.

Approval decisions on service requests: the step, the approver's account id and display name, and the decision; and each approval step as last read, with the account id, display name and decision of every approver on it, pending ones included.

Breach reviews: the reason, the note, and the account id and display name of the reviewer. Compliance targets and the monthly compliance pack PDFs. Run metrics.

Precheck

For Jira Assets. Nothing. Precheck reads Assets schemas, object types, attributes, statuses and objects, and checks whether user account IDs and group names exist, only while someone uses its page, and only as that person, so it sees what their own permissions allow.

An import file is read in the browser; only the values that need a lookup (identifiers, unique values, reference values, account IDs and group names) go to the app's function on Atlassian Forge, which asks your site's Assets and Jira APIs and returns the answer. Nothing is kept once the page closes. Its error logs hold the failing function's name and the error type, never values from your data.

Where it is stored

Doorman and Super SLA keep their data in Atlassian Forge hosted storage, in the same region as your Jira site. Precheck stores nothing: its lookups run in its function on Atlassian Forge for your site and nothing is kept afterwards. The apps have no servers of their own. The apps' code calls only Atlassian APIs. Atlassian's data residency and security controls apply.

Who can see it

Jira site administrators see everything Doorman stores, through its admin page inside Jira. Super SLA's admin page also opens only for Jira site administrators, but it shows each of them only the service projects where they are an agent and the issues Jira lets them see. Administering Jira alone gives no access to Super SLA data. Some features show part of the stored data to other people:

• Doorman's dashboard gadget shows counts to anyone who can view the dashboard. It shows no names.
• Super SLA's dashboard gadgets show counts only to people who are agents on a service project, and count only the projects where they are agents and the issues Jira lets them see, the same as for administrators. They show no names.
• Super SLA on issues: the SLA fields, the SLAs panel and the JQL functions show SLA data to people who can see the issue in Jira. The Rovo agent answers only agents, about the projects where they are agents and the issues Jira lets them see. It can say who held an issue when it breached.
• Super SLA on the customer portal shows a customer the SLA state and approval steps of the requests Jira lets them see, their own and those shared with them. Approver names appear only if an administrator allows it on the Capture tab.

Each Super SLA feature beyond capture can be switched off on the Capture tab. Altoria never receives the data the apps store and does not share it with any third party. Error logs that Atlassian shares with app developers can contain identifiers such as issue keys from a failed request.

How long it is kept

Precheck keeps nothing, so there is nothing to retain or erase. For the others: the current snapshot is replaced on each run. Doorman keeps the first complete snapshot of each month for twelve months. Change records, audit copies, review decisions, export logs, SLA cycles, approval decisions, breach reviews and compliance packs are kept for as long as the app is installed.

After an app is uninstalled, Atlassian keeps its Forge storage for 28 days, then deletes it. To recover it, ask us within 21 days of uninstalling; reinstalling alone does not bring it back.

Once a week each of them asks Atlassian which of the accounts it holds have been closed or changed. For a closed account it removes the name, email address and IP address from everything it stores; Doorman keeps the account id with no name attached, and Super SLA removes the id as well. For a changed account it replaces the names it stores with the current one.

What Altoria collects about you

Nothing beyond what Atlassian Marketplace provides to partners for billing and support (your site name, the installed app, and license status) and the error logs described above. Support email you send us is kept for as long as needed to resolve the request.

Contact

Questions about this policy: support@altoria.app.