Security & Data Handling — Leaver Cleanup & Owner Reassignment for Jira
Last updated · 8 June, 2026
This page explains how the Leaver Cleanup & Owner Reassignment for Jira app is built and why it asks for each permission. It is written for administrators evaluating the App and for your security review. See also the App's privacy notice and data processing agreement.
Runs on Atlassian
The App is eligible for the Atlassian Runs on Atlassian program. In practice that means:
- it uses only Atlassian-hosted compute (Forge functions) and storage;
- it has no external egress — it declares no outbound network access, so all outbound calls are rejected by the platform;
- it uses no web triggers; and
- it matches your site's data residency by running on Atlassian infrastructure.
Nothing the App touches leaves Atlassian, and you keep administrative control of it.
Separately, the Atlassian Forge platform (not the Runs on Atlassian program specifically) encrypts Forge-hosted data in transit and at rest and isolates each installation's data.
Data minimisation
The App stores only what it needs to reassign ownership and record it: account identifiers, item references, outcomes, and timestamps. It fetches display names live only when needed — to show the candidate list and label the evidence export — and does not store them. It does not read or store issue content, attachments, or unrelated personal data.
Storage, retention, and erasure
- Data is held in Atlassian-hosted storage (Forge key-value and entity storage).
- Per-change records carry a 90-day retention and age out automatically.
- Administrators can erase a run's records on demand after exporting.
- On uninstall, the App makes a best-effort erase and Atlassian purges the App's hosted storage.
- The App participates in Atlassian's personal-data reporting: it reports the account identifiers it stores on Atlassian's cycle, and when Atlassian reports that an account has been closed, the App erases that account's stored identifiers. Because records are organised per reassignment run, this removes the records of any run in which the closed account appeared in any role — the departed user, the target, or the administrator who ran it — so a run may be erased even if it primarily concerned a different user. (Account closure is permanent account deletion at Atlassian, distinct from deactivating a user. Export any evidence you need to keep before it ages out.)
Why each permission is needed
The App requests the following scopes. Each maps to a concrete action in the flow — there is no over-broad or unused scope:
| Scope | Why it is needed |
|---|---|
| Read Jira users | Detect deactivated or departed users and validate that the reassignment target is active and able to own each item — so a reassignment never silently orphans content to an unusable account. |
| Read Jira work | Find what the departed user owns across the content types listed, and re-read each item's final owner after a write — the read that makes the closure-evidence record reflect the actual outcome rather than an assumption. |
| Write Jira work | Perform the reassignment writes that are the product: issue assignee and reporter, and filter owner, moved to the active target. |
| Manage Jira projects | Write the component-lead and project-lead fields when reassigning those roles. |
| Manage Jira configuration | Confers the Administer Jira capability the App uses to discover and reassign a departed user's private filters. Without it, private filters are shown as unreachable rather than acted on — the App still works, just without private-filter coverage. |
| App storage | Atlassian-hosted storage for run state, the per-change records that become the evidence, and safe-retry / resumability. No external storage; nothing leaves Atlassian. |
| Report personal data | Lets the App report the account identifiers it stores to Atlassian on the required cycle, so account closures can be propagated back and the corresponding data erased. |
Safety properties
- Preview is a dry run — nothing is written until you confirm.
- A binding permission check re-validates your access (globally and per project) before any write; a project that fails blocks the run rather than applying it partially.
- Runs are safe to retry and resume if interrupted, without double-applying.
- Partial failures are shown, never hidden; the evidence record reflects what actually happened.
What is out of scope (named honestly)
Dashboards (owner transfer is a current limitation on Jira Cloud), automation-rule actors (natively transferred by Jira), project-role memberships, board administration, group memberships, watchers and mentions, and comment and worklog authorship are out of scope in this version. The closure-evidence record covers the content types listed, not everything a user may have owned; it is a factual record of actions the App performed, not a certification or guarantee of compliance.
Contact
Security questions: info@wayflare.eu (Wayflare OÜ, Pärnu mnt 141, 11314 Tallinn, Estonia, registry code 17495514).