Data Handling: Retention and Deletion

Effective [date of publication]

App	TuneCraft: Automation & Site Cleanup, a Jira Cloud app built on Atlassian Forge
Marketplace listing	Not listed yet. TuneCraft is not on the Atlassian Marketplace yet, and its app key will be added here when it is.
Forge app ID	ari:cloud:ecosystem::app/facece90-dfd5-4792-9bff-6a5bd061a341
Vendor	Plugincraft Software Inc., a company incorporated under the laws of Québec, Canada

The short version

All the data the app stores is kept in Forge SQL, Atlassian's hosted database for Forge apps, in your Jira site's data residency location, and moves with the site.
The app sends no data to Plugincraft or to any other service outside Atlassian, so there is no data held by a third party to delete.
Scans, readings and records are kept for the times in the table below. A daily maintenance run removes what has expired.
When the app is uninstalled, Atlassian keeps its stored data for 30 days and then permanently deletes it.

Where data is kept

The app stores its data in Forge SQL, Atlassian's hosted database for Forge apps. The database belongs to your installation. Forge hosted storage supports data residency: it stays in the same location as the Jira site, and Forge moves it when an admin moves the site. The app needs no setting of its own for this, and keeps no copy anywhere else. It uses no key-value storage and no object storage.

What the app creates in Jira itself, such as alert and notice work items, is kept in Jira under your site's own rules. Its text is in Jira, not in the app's database.

The app declares no egress, so there is no data sent outside Atlassian whose retention could be described here. The automatic scan sends data in, from a sender the customer runs, and not out of the app. The sender first reads the rules' real text through Atlassian's API, wherever the customer runs it: on its own systems or as a scheduled job in ScriptRunner Cloud, a script app from another publisher that the customer installed (see the privacy policy).

Encryption. Atlassian states that the Forge platform uses AES-256 to encrypt data at rest for data stored within Forge app storage, and TLS 1.2 or higher in transit. See Encryption at rest and in transit in the Security overview, which links to Atlassian's documentation.

What is stored and how long it is kept

The list is by kind of data. The privacy policy says what each holds and why. All of it is in Forge SQL.

Data	How long
Scans: for each flow, its id, name, trigger type, project ids, creation day, owner's and actor's account ids, a fingerprint of its structure, its score and its findings; and, for a scan a Jira admin starts, the flow's structure with every text replaced by a placeholder, and the account ids its steps name	The last 24 scans and, while none of them kept what its flows name, the latest scan that did. The daily maintenance removes older ones, and a person at the Manage level can delete a scan sooner on the History page. A kept flow stays while a scan that names it is kept.
What each flow uses (ids and keyed hashes)	The latest scan that kept what its flows name, and the one being made. The daily maintenance removes them from older scans, and a deleted scan's go with it.
What each flow names that Jira no longer has, from the Automation tool's Broken flows reading (ids and keyed hashes)	The reading published last, for the scan it covers. A newer reading replaces it, and a deleted scan's go with it. Turning the Automation tool's background checks off does not remove it.
The governance counts of each flow, and how many of its JQL texts Jira refused (numbers only)	The latest scan that kept what its flows name, and the one being made, like what each flow uses. The counts of a scan that kept no references stay as long as the scan: the last 24 scans, or longer for the scan kept as above.
Fixes that scans confirmed: the flow's id, the finding and the steps saved	Kept as the record of what was saved. The flow's name is removed once the scan that confirmed the fix is no longer kept.
Numbers and days from automation audit logs: each flow's runs, steps, run time and how its runs ended; the site's runs and steps by day and product; and, from a log that lists every run, the time of its newest run (one time, with no flow, run or person beside it)	400 days, except that one time, which is kept only when the log reaches the day of the scan and stays until the next scan of a log that lists every run and ends the same day or later replaces it.
Run health: for each flow, the runs of its newest audit log by how they ended, and the days of its last runs (numbers and days only)	One row for each flow, replaced by each newer log and removed once the flow is no longer in the last scan and the row has not been replaced for 90 days. The days the logs covered: 400 days.
Settings: app access, plan and allowance, alert settings, the organization's email domains, naming conventions, the two numbers of days after which Sprints left behind counts a sprint as left behind, targets (with the account id of the Jira admin who set each), guidance for a check, and the cost model's values, each with the account id of the person who last saved it (a Jira admin or, for the cost model, a person at the Manage level)	Until a Jira admin (or, for the cost model, a person at the Manage level) changes them, or the app is uninstalled. A target: until a Jira admin removes it, and 400 days after it was met.
Alerts sent (what they were about, when, and the work item's key), and the account ids of the people alerts mention	Alerts: 400 days. The people mentioned: while they are picked.
Owner notices sent: the flow, when, the work item's key, and the account ids of the person told and of the sender	One year.
The To do list: each action's status, the account id of who set it, and the key of the work item linked to it	400 days after a reading confirmed an action done, or once no reading has seen its problem for 400 days. An action ignored, or marked done without a reading's confirmation, stays while a reading still shows the problem.
The ignore list and the watch list: Jira ids, the day, the reason code and the account id of who did it	Until stopped or the days are up, or Jira no longer has the object; an ignore for a flow also goes once the last scan no longer has the flow and the ignore is more than 30 days old. A watch also goes within a day when the checks of its tool (Fields, Spaces or Filters) are turned off. At most 500 rows for each tool on the ignore list and 100 on the watch list.
Seats of an uploaded user export: account id, last day of use and whether the person is a product admin (names and email addresses stay in the browser)	Until a Jira admin uploads a new file or removes it, and at most 90 days after the upload.
Readings of Jira's configuration for the clean-up tools that have background checks (Limits, Fields, Spaces, Filters, Schemes, Workflows): ids, counts, days, Jira's own vocabulary and keyed hashes. People has no checks of its own: it uses what Filters, Schemes and Spaces keep. Labels and Boards keep no reading	While a Jira admin has the tool's background checks on. Removed when Jira no longer has the object, and within a day after the checks are turned off. Limits is an exception: its latest counts, by Jira's id and with no name, stay while Jira has the space or scheme, also after the checks are turned off. Another is the history of a custom field's names (keyed hashes, used to repair a renamed field in a filter): 400 days after the name was last seen, also for a field Jira has deleted, and removed within a day after the Fields checks are turned off.
Histories of those readings: each count on the days it changed, the change history (kind, Jira's id and day), and Jira points by day	400 days.
The record of changes a clean-up tool made in Jira: who, when, what kind, how many objects, the result and until when it can be undone; for a deleted status, a keyed hash of its name and description; for a deleted workflow or workflow scheme, how many workflows or statuses the delete left unused (counts); for a repaired filter, keyed hashes of its JQL before and after	The change: 400 days. Each object of it, with what an undo needs: 30 days. A change left open, that nobody finished or stopped, is closed by the daily maintenance 30 days after it started (a week for a merge of schemes or for a change its tool's Changes page closes, an hour for the deletion of a permission scheme copy or the removal of an open grant), and its objects go as above.
A label change's old and new label (the labels' text, 255 characters at most each) and the ids of the work items it changed	30 days, so that Undo and Carry on need no file. Then deleted by the maintenance run (the work item ids of a change left open go 30 days after each was recorded, once the maintenance has closed the change). Never written to a log.
A merge of one field into another, and each preparation of the field to keep (options, spaces of a context, screens added): the ids of the two custom fields, counts, and the ids of the work items, options, spaces or screens touched, each with a code for Jira's answer. Never a value, a field's name, an option's text or a work item's key or summary	The run and its counts: 400 days, with the record of the change. The ids of the work items, options, spaces and screens: 30 days. Never written to a log.
How far a label change has got: the keyed hashes of the old and new label, its state and counts, and the id of the last work item it handled	400 days, with the record of the change. The id of the last work item it handled: cleared when the run stops, and in any case after 30 days.
Attachments readings: counts by space, file type and month, and the 100 work items with the most attachment bytes, by id	A reading of picked spaces: 90 days. A whole-site reading: the last finished one.
How an archive or stale-backlog run was started: its mode and, for a stale backlog, the space ids, a day and a status id (the run's work items are in the record of changes above)	Until the run ends. For a run that nobody finishes or stops: until 400 days after it was last written. Its work item ids go as in the record of changes above.
The automatic scan: a one-way hash of the key's secret; the parts of a push in progress, which hold the flows as the sender sent them (names, the account ids of owners, actors and the people the steps name, redacted steps); a record of each push in progress or just ended (its id, start time, state and counts); and the last result (counts)	The key's hash until a Jira admin replaces or turns off the key. A push's parts are deleted when it ends; the daily maintenance removes those of a push that never finishes once it is an hour old (three hours if the app had begun to save it, 26 hours if the sender asked to keep it open). The record goes with them. The last result stays until the next push.
Runs and steps a month measured for some flows (typed by a person at the Manage level, or counted from an audit log): the flow's id, the numbers, where they came from and the day measured	Until a person at the Manage level removes them. The daily maintenance removes a count 90 days after the day measured once the last scan no longer has the flow.
How a scan's flows are linked (which can start which, copies, shared triggers, loops), by flow id, and how far the comparison of a scan with the one before has got (scan ids, a flow id, counts)	Removed with their scan.
For a trial: the id of the one flow Optimize may prepare a fix for, a fingerprint of its structure and the scan it was chosen from; and how many objects each clean-up tool has changed	As long as the app is installed: nothing removes them earlier.
Site health: for each day the tools home was opened, the whole numbers of the tools' cards (objects and findings counted by tool and severity, and the share of the nearest limit)	400 days.
The background checks' bookkeeping: for each check, its state, where it stands (Jira's ids and offsets), counts, Jira points and times, and the short code of its last failure; and, for each day, what it did (passes finished, tries that failed, points spent). No name and no account id	A check's row stays while the check exists. The rows for each day: 14 days.
Account ids the app stores, with when each was last stored and reported to Atlassian	While any record holds the id. An id Atlassian reports as closed is erased from all records, and the bare id is kept about one more reporting cycle (7 days unless Atlassian names another).
App logs	See Data Logging.

The app stores Atlassian account ids to record who scanned, who saved a setting, who owns or runs a flow, who was told and who made a change. It stores no names or email addresses; it asks Jira for them when it needs to show them. The texts people wrote that it does keep are flow names, and the texts in the table: the old and new label of a label change (30 days), the settings, naming conventions and guidance a Jira admin typed.

How data is deleted

Delete a scan. A person at the Manage level (a Jira admin, or a member of a group a Jira admin allowed at that level) can delete any scan on the History page, which removes its flows, readings and kept structures. A scan that a newer scan pushes out of the last 24 is removed by the daily maintenance.
Daily maintenance. A daily job removes what has expired or what nobody can reach any more, in batches, picking up where it stopped the day before. Jira admins can see the last run on the Maintenance page and run it on demand.
Turning a tool's checks off. When a Jira admin turns a tool's background checks off, its readings are removed within a day, and so are the watch list rows for its fields, spaces or filters. The exceptions are in the table above.
Closed accounts. The app keeps Atlassian account ids, no names or email addresses. It reports the ids it stores to Atlassian once for each reporting cycle, as Atlassian requires of apps. When Atlassian says an account was closed, a daily run erases that id from every record that holds it, usually the same day. In a kept flow, the id and its placeholder are removed. Deactivated accounts are left as they are.
Changes in Jira. What a Jira admin deletes in Jira through the app (a field, a filter, a status and so on) is deleted by Jira, under its own rules. Where Jira has a trash or an archive, the app uses it. Where it has none, the app first gives the admin a record file to save.
Uninstall. The app has no code that runs at uninstall and keeps no copy outside the installation. When an admin uninstalls the app, Atlassian soft deletes its stored data for the site, keeps it for 30 days, and then permanently deletes it. A reinstall is a new installation, but a request made to Atlassian within 21 days of the uninstall can relink it to the old data. An admin can also keep the app until the end of the billing or trial period plus 60 days before it is removed, or remove it at once. These periods are Atlassian's: see Atlassian's page for site admins and its data lifecycle page for Forge-hosted storage, which prevail if they change.
Copies Atlassian keeps. When the app deletes data while it is installed, Atlassian removes it from primary storage and keeps a soft-deleted copy so that an accidental deletion can be undone. Atlassian destroys that copy, and backups taken before the deletion, at the end of its retention period.
Site deletion. When a Jira site is deleted, the site and the app's data stay recoverable during Atlassian's soft delete period. Once Atlassian removes the site permanently, the app's data is deleted at once.
Record files and exports. A record file, a download of findings or a fix file is saved wherever the person chooses, and Plugincraft never receives it. A record file holds the names of what it records, so it should be stored safely. Deleting data in the app does not delete files that were already saved.
Your automation export and user export. The files are read in the admin's browser. The app keeps only what the table above lists.

Requests about personal information