Atlassian apps privacy policy

How the Atlassian Marketplace apps by Dangel Studio handle data: one policy for all apps, with a section per app.

Last updated: 18 August 2026

This privacy policy applies to all apps for Jira Cloud offered by Ben Dangelmayr (Dangel Studio) on the Atlassian Marketplace. It complements the website privacy policy. This page is also available in German.

Architecture shared by all apps

All apps run entirely on Atlassian Forge, Atlassian’s cloud platform:

No external servers, no data egress: processing happens exclusively inside Atlassian’s infrastructure. No data is transferred to Dangel Studio servers or third parties; I have no access to your site’s Jira data.
Display uses your permissions (asUser): what an app shows you in the interface is read with the permissions of the signed-in person; only what you can see in Jira yourself becomes visible.
Reacting to Jira events (asApp): two apps also react to issue changes: Requirement Drift Guard and Reopen Receipt. Such an event fires without a signed-in person, so that path runs with the app's own permissions. What is read and stored there is described in the app's section; what gets displayed is still limited to what you can see in Jira.
No AI, no tracking, no third-party services, no ads.
Storage location: where an app keeps configuration or receipt data in Forge storage, it is hosted by Atlassian as part of your site’s data; the location follows your Atlassian site’s data-residency settings.
Uninstall: when an app is removed, Atlassian deletes its Forge-stored data in line with the Forge data lifecycle, retaining it for up to 28 days to do so. If an app was uninstalled by mistake, get in touch within 21 days: only then can a restore be requested, with your consent. Reinstalling on its own does not bring earlier data back. Apps that store nothing leave nothing behind to delete.

Platform runtime logs

The Forge platform writes technical runtime logs for every app. As the developer I can read them in Atlassian's developer console for 30 days by default, so that I can investigate errors; the administrator of your Atlassian site can switch that access off at any time. The apps write only technical identifiers (issue or status ID) and HTTP status codes to those logs. Issue content, names, email addresses, account IDs and credentials are not logged.

Roles: who is responsible for which data

The operator of the Jira site (your company): controller within the meaning of the GDPR for the Jira data the apps process inside your site.
Atlassian: processes your site’s data as your processor under the agreements between you and Atlassian.
Dangel Studio: provides the software. The apps transmit no customer data to systems operated by Dangel Studio; processing happens inside Atlassian’s infrastructure, and I have no regular access to your site’s Jira data; the only thing available to me is the technical runtime logging described above. What each app processes transiently and what it stores is described in its app section. Whether a processor relationship exists in an individual case depends on the actual circumstances; contact me if you need a data processing agreement. Independently of that, I am the controller for the support and contact data described below.

What each app reads and stores

The authoritative, always-current statement is the “Permissions and data” section on each app’s documentation page; here is the summary:

Requirement Drift Guard

Reads (transient processing: live, with your permissions, not stored by the app): the current field values of the issue to compute the baseline comparison (strictly read-only).
Stores: baselines, change entries and acknowledgements per issue in Forge storage. Change entries contain the Atlassian account ID of the person who made the change, exactly as Jira itself records it.
Personal data stored? Yes: account IDs in change entries (pseudonymous identifiers under the GDPR).

Reopen Receipt

Reads (transient processing: live, with your permissions, not stored by the app): the status and changelog of the one affected issue to detect reopens (strictly read-only).
Stores: receipts and classifications per issue in Forge storage.
Personal data stored? No. Who reopened an issue is read live from the Jira changelog at display time and never stored.

Weekly Brief

Reads (transient processing: live, with your permissions, not stored by the app): one bounded, read-only search per page view, limited to the project you are viewing; only the fields the brief displays are read.
Stores: nothing; the app persists no data at all.
Personal data stored? No.

Tree Clone

Reads (transient processing: live, with your permissions, not stored by the app): the tree being cloned (root plus two levels below, scoped to that one tree).
Stores: nothing; every clone is planned fresh on the server. The cloned issues are created as regular Jira issues in your project, as you (asUser).
Personal data stored? No.

Stale Radar

Reads (transient processing: live, with your permissions, not stored by the app): one bounded JQL search per page view within the one project (max. 3 pages of 100): summary, status, assignee, last-update time.
Stores: one small record per snoozed or excluded issue: until-date or permanent flag, an optional free-text reason, a created timestamp. No issue content, no account IDs.
Personal data stored? The snooze records contain no account IDs. The optional free-text reason can contain personal data if users enter it. The interface explicitly asks not to; responsibility for entered content stays with the user or site operator.

Automation Heartbeat

Reads (transient processing: live, with your permissions, not stored by the app): per registered canary (at most 15) only the issue’s last-update time, summary and project; on registration, the existence and project check.
Stores: exactly one record per canary: the admin-written label, the expected interval in hours, a created timestamp. No issue content, no account IDs.
Personal data stored? No.

External ID Guard

Reads (transient processing: live, with your permissions, not stored by the app): one bounded JQL search (max. 3 pages of 100) for issues with a value in the watched field: only summary, status and that one field.
Stores: one configuration record per project: the ID of the watched field. No field values, no account IDs.
Personal data stored? No.

Field Health

Reads (transient processing: live, with your permissions, not stored by the app): one bounded JQL search per page view across the project’s open issues: summary, status and the configured fields; every value is immediately reduced to filled/empty in memory.
Stores: one configuration record per project: the IDs of the fields to check (at most 20). Never field values, never account IDs.
Personal data stored? No.

Rollup Guard

Reads (transient processing: live, with your permissions, not stored by the app): one bounded, read-only JQL search per page view in the project you are viewing: summary, status, issue type, parent, due date.
Stores: nothing; the app persists no data at all.
Personal data stored? No.

Handoff Receipt

Reads (transient processing: live, with your permissions, not stored by the app): the one issue whose panel is open: its changelog (up to 300 entries), creation date, assignee, status.
Stores: nothing; the timeline is computed in memory and displayed immediately.
Personal data stored? Stored: no. The app does, however, display personal Jira data (assignee, change history); it is read transiently at runtime and never stored by the app.

Intended use

The apps are not intended for covert employee monitoring, automated performance evaluation or automated personnel decisions. Where issue and history data allows conclusions about individual people’s work, the customer remains responsible for employee data protection (in Germany in particular § 26 BDSG), transparency towards employees and any co-determination rights (e.g. of a works council).

Data for which Dangel Studio is the controller

The only personal data I process for my own purposes is the data you send me yourself: by support email or through the contact form:

Purpose: answering your request and providing support for the apps.
Legal basis: Art. 6 (1) (b) GDPR for support connected to your use of an app, otherwise Art. 6 (1) (f) GDPR.
Storage period: support emails are kept only as long as needed to handle the request and keep the case traceable.

Your rights

Where personal data is processed, you have the rights under Art. 15–21 GDPR (access, rectification, erasure, restriction, data portability, objection) against the respective controller. Please direct your request to the controller responsible for the data in question: for Jira data, the operator of your Jira site; for your Atlassian account, Atlassian; for support and contact data, me. You also have the right to lodge a complaint with a data protection supervisory authority (Art. 77 GDPR).

Changes to this privacy policy

If an app’s data handling changes (for example through new features), the updated version will be published on this page before it takes effect, and the date above will be adjusted.

Controller for support and contact data

Ben Dangelmayr
Friedensstraße 49
69121 Heidelberg, Germany
Email: support@dangelstudio.de