Queue Coverage
by ProfitSignal Labs

Queue Coverage privacy notice

Privacy notice — 30 September 2026. The privacy-reporting update is undergoing development validation before public release. Provider: Jon Ander Irazusta Iribar, trading as ProfitSignal Labs. Contact: support@profitsignallabs.dev. Provider details are in the Legal Notice.

Data processed in the app

The app reads service desk/project identifiers, queue names, definitions and memberships, field schema, and requests visible to the current user: identifiers, keys, status, creation/update dates, resolution presence and visible assignee display names. The current Atlassian account identifier is used for authorization and actor-scoped evidence. This includes personal data where those records identify people.

Data stored

Forge storage holds project IDs, selected queue IDs, active categories, configuration versions/save times, and exclusions consisting of numeric issue IDs, predefined reasons and expiry times. It does not store request titles, assignee names, raw field values, memberships or coverage results. Up to 200 current exclusions and 1,024 immutable revisions are supported per project.

Optional personal run history holds dates and configuration version, at most one latest saved record per UTC day/account/project. A hash of the account ID partitions the history; hashing is pseudonymization, not anonymity. History expires logically after 30 days and has a Forge TTL; physical deletion can lag. A user can delete their own history from the app.

Configuration versions have no automatic expiry. An expired or removed exclusion can remain in an older configuration revision; it no longer changes current eligibility. Configuration erasure is assisted through support. An entitled project administrator can erase selections and exclusion details using the app control. Minimal project/version markers remain to protect against stale writes; personal history is separate. Interrupted erasure must be resumed. Atlassian currently documents a 28-day storage retention period after uninstall and no automatic restoration on reinstall. Platform backups/logs follow Atlassian policies. See Forge storage lifecycle.

Atlassian privacy reporting

The corrected release registers the account ID of users who choose to save history, the age of that data, report timing and the latest history-save time in Forge storage. The account ID and data age are sent only to Atlassian through its Privacy API. Request content, queue membership and report rows are not sent in these privacy reports. A scheduled privacy-only process handles account closure or update instructions independently of Jira permissions and paid entitlement; it does not scan Jira or monitor queue coverage.

Pending privacy erasure or an overdue report blocks access to personal run history until maintenance succeeds. Coverage checks remain independent. History deletion removes the selected account/project records; the reporting registry may remain until the latest history age reaches 30 days and cleanup completes. Temporary erasure checkpoints and closed-account markers prevent stale data from reappearing. Registry and erasure records have a maximum 31-day storage TTL per write; closed-account markers have a 30-day TTL. Interrupted maintenance is retried. Contact support if history remains unavailable.

Access, exports and purposes

Processing provides the requested queue checks, saved policy and support. Runtime Jira calls use the signed-in user's permissions. Administrators manage policy; stored exclusions are displayed only for currently readable eligible requests. CSV export performs a fresh scan, neutralizes spreadsheet formulas and contains only the current observation. The customer controls external copies. UI observations expire after one minute.

Recipients and roles

The app runs on Atlassian Forge and declares no external runtime network destinations, advertising or AI integration. Atlassian supplies the platform infrastructure. For customer-controlled app data, the provider acts as processor under the processing terms; the customer determines its lawful use. The provider handles support correspondence and website operations as controller for those purposes. Do not send issue exports, credentials or sensitive records to the general support mailbox.

Rights and contact

Requests about access, erasure or processing can be sent to support@profitsignallabs.dev with minimal identifying information. Requests are verified before acting. No password or API token is required. Source Jira records and customer-exported files must be managed by their respective owners.

Customer terms and processing agreement · Security statement