Estimate Gaps for Jira

How we handle data

A record-by-record explanation of what this version processes, stores, and retains.

  • Atlassian app
  • Version in development

01

Summary

This page describes the version in development, not a public Marketplace listing. Read the privacy policy for the legal terms.

This page describes the Estimate Gaps version in development, not the held Tallyfield Rollups for Jira Marketplace submission. The held submission still lists legacy storage and write permissions that have not been reconciled with this version. Estimate Gaps processes the Jira issue ID or key, summary, issue type, project, parent link, and Original Estimate presence only while answering the current viewer's request. It does not write Jira values, store panel results, log them, or send them outside Atlassian. The panel keeps only aggregate counts from the previous completed scan for one refresh comparison, then clears them on the next comparison, on failure, or when the panel closes. Earlier development versions left app-owned field values and Forge-hosted records. Removed field values have a 30-day cleanup target. Other Forge-hosted residuals follow Atlassian's lifecycle. The held submission described retention that could continue for up to 60 days after billing or trial ends. Development major 4 is installed on one site, and there is no production installation, so no customer production migration is currently required.

Personal data stored
Yes. See the records below.
What happens after uninstall
Each record below explains its retention. We do not make a general immediate-deletion promise.
Where data is sent
The version in development has no external egress. Current request processing stays between Jira and Atlassian Forge.

02

Records and retention

Current panel request data

Purpose
Read the issue in context and show only connected missing-estimate rows Jira returns to the person viewing it.
Location
Request memory in Jira and Atlassian Forge.
Retention
No application persistence, logging, export, or analytics retention. Refresh comparison retains only aggregate prior complete visible-gap count(s) in panel memory; no row data is retained, the completed-comparison baseline clears on the next comparison, all count memory clears on failure, and navigation or unmount discards it. Jira summaries can contain personal data and are processed transiently.

Development legacy Estimate Coverage/Rollups residuals

Purpose
Earlier development releases used app-owned derived-rollup fields; Forge KVS issue-to-project mappings and deletion markers; field-ownership, repair, and job state with temporary job pages; bounded aggregate analytics and recent project health; and completed hierarchy snapshots plus activation/unsupported markers. Those records supported rollup calculation, cleanup, recovery, and bounded operational status. The current panel cannot access or purge them and creates none.
Location
Existing development Jira app-owned fields and Forge KVS records only. No production installation currently appears, so there is no customer production migration.
Retention
Removed development fields follow a 30-day lifecycle. Legacy Forge-hosted residuals are subject to Atlassian's applicable Forge-hosted-storage lifecycle; the previously submitted Estimate Coverage contract described retention that could extend up to 60 days after the billing or trial period ends. The current panel creates no such records and makes no separate fixed post-uninstall retention promise.

03

Privacy

Read the privacy policy for the legal terms that apply to this product and the support channel.