Hosted on Atlassian Forge
The app runtime and primary data storage use Atlassian Forge services rather than partner-managed infrastructure.
Overview
What this page covers
Backlog Hygiene for Jira analyzes Jira backlog data, identifies stale issues, calculates hygiene scores, surfaces dashboards and historical trends, stores notification digests inside the app, and supports Jira-native bulk cleanup workflows initiated by authorized Jira users.
The app uses Atlassian Forge-hosted runtime and storage services. The current Marketplace release is intentionally limited to Atlassian-hosted storage plus Jira-native delivery paths. Slack, Microsoft Teams, and direct email relay are not part of the active release surface.
Privacy workflows exist in-product
The admin module supports subject-level export and erasure plus installation-wide hosted-data purge operations.
Release boundary is narrow
The active release avoids unnecessary raw account ID copies in downstream app records and keeps notification delivery Jira-only.
Data categories
What data the app accesses and stores
Backlog Hygiene for Jira accesses and stores only the data needed to deliver its stated Jira backlog analysis and cleanup features.
| Category | Examples | Why it is stored |
|---|---|---|
| Jira issue analysis data | Issue keys, summary snippets, status data, timestamps, project identifiers, stale-issue snapshots | Scan backlog health, calculate scores, support dashboard and export views, and drive stale-issue workflows |
| Configuration and scope data | Selected projects, scoring rules, retention settings, notification settings, release-readiness evidence | Persist customer-selected app behavior and admin workflows |
| Operational records | Scan runs, hygiene scores, notification digests, bulk-action audit logs, export metadata | Power trend reporting, in-app notifications, observability, and auditability |
| Limited identity data | Jira account IDs stored in a canonical identity registry for configured notification recipients and bulk-action initiators | Support recipient delivery, preserve audit ownership, and satisfy Atlassian personal-data reporting obligations |
The current release is designed to avoid duplicating raw Jira account IDs into downstream digest rows, bulk-action rows, onboarding completion metadata, release-readiness evidence, and the active admin snapshot.
The app does not store Jira passwords, customer user API tokens, or customer-managed secrets as part of normal app operation.
Use of data
How data is used
- Evaluate backlog health, stale issue volume, and trend direction.
- Render global and project dashboards, exports, and historical views.
- Generate in-app notification digests and Jira-native summary or comment delivery when configured.
- Execute user-initiated bulk cleanup workflows within Jira permission boundaries.
- Operate support, troubleshooting, reliability review, and release-readiness processes.
- Satisfy Atlassian personal-data reporting obligations for the limited identity registry described above.
Workaround does not sell customer data.
Delivery and egress
Where data may be sent
In the active Marketplace release, Backlog Hygiene for Jira stores operational data in Atlassian Forge-hosted storage and may send configured notification or summary content only to Jira destinations selected by the customer, such as Jira issue comments or related issue updates.
Included in the current release
Atlassian Forge hosted storage and Jira-native delivery paths.
Not in the current release
Slack, Microsoft Teams, and direct email relay are deferred and are not part of the shipped release surface.
Customer-controlled Jira outputs
If Jira-native delivery is enabled, the relevant data is handled under Atlassian's own platform terms and privacy controls.
Retention and deletion
How long data is kept
| Record type | Retention posture |
|---|---|
| Issue snapshots | 30 days by default, configurable by admins from 7 to 90 days, with automatic reduction under storage pressure |
| Notification digests | 30 days |
| Scan runs and bulk-action logs | 90 days |
| Hygiene scores | Retained for trend continuity unless deleted through broader app-data deletion workflows |
| Canonical identity registry entries | Retained while needed for active recipient, audit, and personal-data reporting obligations, or until removed by a supported erasure or installation-purge workflow |
Atlassian Forge hosted storage has its own lifecycle. Atlassian documentation states that hosted app data is retained for a period after uninstall and may be re-linked to a new installation if the customer consents and the recovery request is raised within Atlassian's published recovery window.
If you want permanent deletion of app data, do not rely on uninstall alone. Contact Workaround or use the app's explicit deletion workflows so the request can be tracked and completed intentionally.
Requests and support
How to request help, export, or deletion
-
Support or general privacy question
Email workaroundapps1@gmail.com with your Jira site URL, the app name, and a concise description of the issue or request.
-
Subject access or export request
Include the relevant Jira account ID if known. The app's admin module supports subject-level JSON export, and support can help coordinate the request if you need operational assistance.
-
Deletion or erasure request
For a single subject, the app supports exact-confirmation erase operations. For tenant-wide hosted-data deletion, the admin module supports an installation-wide hosted-data purge workflow.
-
Security report
Send the details to the same address with a clear subject line such as Security Report so the report can be triaged quickly.
Security posture
How the release is scoped and operated
Forge-hosted runtime and storage
The app runs on Atlassian Forge and uses the permissions declared in the Forge manifest for Jira Cloud.
Minimal release surface
The shipped release excludes third-party notification relay paths and narrows raw account ID persistence to a canonical registry with reporting and deletion workflows.
Operational controls
The app maintains release-readiness, audit, DSAR, and hosted-data deletion workflows as part of its operating model.
No method of transmission or storage is guaranteed to be completely secure, and you should continue to follow your own internal access, approval, and data-governance controls when using the app.
Changes to this page
How updates are published
This page may be updated from time to time. The current version will remain available at the same public URL with an updated Last updated date.