Applies to: Visual Dependencies — Work Item Link Map for Jira.
Atlassian requires every partner that declares in-scope End-User Data in its app to publish
what the app treats as in scope and out of scope for data residency. This page is that
definition.
What “in scope” means here
Atlassian defines in-scope End-User Data only as “data that must comply with data
residency requirements”, and leaves the definition to each partner. This is ours.
We treat data as in scope when it is the customer's own product data — the
content of their Jira site and the records the app keeps on their behalf. That data stays inside
Atlassian Forge hosted storage and follows the region the customer pins.
We treat data as out of scope when it is neither customer content nor
attributable to a person from the data itself: measurements of how the software behaved,
carrying an identifier we generated ourselves.
This is a narrower claim than “not personal data”. Some out-of-scope data
is personal data under the GDPR and is treated as such — see our
Privacy Policy. Our Legitimate Interests Assessment for product
analytics is available on request.
In scope
Stored in Atlassian Forge hosted storage, pinned to the customer's region:
- Saved filter presets, saved graph layouts (node positions), the last-used preset, and colour
preferences — each keyed by an Atlassian account identifier.
- The mapping from an Atlassian account identifier to the app's analytics identifier, the
analytics opt-out record, and the record that the analytics notice has been seen.
- Everything the app reads from Jira in order to draw a graph — work items, their links,
assignees and reporters. The app reads this on demand and does not copy or retain it.
Out of scope
- Product-analytics events. Content-free records of which app feature was
used, how often, how long an action took and whether it succeeded, carrying the app's
analytics identifier and coarse context: the surface the app was opened on, the licence
edition, the Jira colour mode, a viewport size bucket, the environment and the app version.
They contain no work-item content, keys or names, no project names, no Atlassian account
identifier, no name or e-mail address, no page addresses, no browser, device or operating
system, and no location. Processed by PostHog Inc. on PostHog Cloud EU.
- The app's analytics identifier. A random value generated by the app per
installation for each account. Never derived from the Atlassian account, name or e-mail
address; never shared between customers; replaced after 12 months; deleted when the user
opts out or their Atlassian account is closed.
- Transport metadata of the analytics connection — the IP address the request
arrives from. Inherent to any request leaving the browser; discarded by PostHog at
ingestion, never stored by us, and never used for geolocation.
- Atlassian's own operational and usage reporting about the app — install
counts, active-user counts, invocation counts, error rates and latency. Produced by
Atlassian as platform operator from data it already holds.
How the boundary is held
The out-of-scope claim rests on the payload, not on a promise, so it is enforced where payloads
are built:
- Every analytics property is a number, a boolean, or a value from a closed enumeration. There
is no free-text property kind, so work-item content, keys, project names, filter text and
user names are unrepresentable rather than merely forbidden.
- A runtime allowlist drops any property not in that schema before a request leaves the
browser.
- Tests fail the build if the schema gains a free-text kind, or if person properties would be
sent.
If the payload ever needed to carry customer content, the correct response is to declare that
data in scope, with the consequences that has for how the app is certified — not to restate
this definition.
Questions about this definition: [email protected]