Data Handling: Retention and Deletion

Effective October 28, 2026

App	TreeCraft: Issue Hierarchies, a Jira Cloud app built on Atlassian Forge
Marketplace listing	Coming. TreeCraft 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/2f99b935-aba0-4b23-8784-05691aaac4b9
Vendor	Plugincraft Software inc., Québec, Canada

The short version

All the data the app stores is kept in Forge storage, in your Jira site's data residency location, and moves with the site. The one exception is a small search token that Jira keeps on work items when search is turned on for a hierarchy.
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.
Hierarchies are kept until a person deletes them. Short-lived records are removed by the app on the schedule below.
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, and in Forge key-value storage (only for timeline baseline snapshots). Both belong 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.

Jira itself keeps the search tokens the app writes to work items as properties when search is turned on for a hierarchy.

The app declares no egress, so there is no data sent outside Atlassian whose retention could be described here.

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

Data	Where	How long
Hierarchies and what is in them: rows (work item ids and positions), folders, memos, planning items, rules and their output (ids only), notes and app field values, labels	Forge SQL	Until a person deletes the hierarchy. Archived hierarchies are kept until deleted.
Views, saved columns, transform and rule presets, shared links, favorites, recent and clipboard rows	Forge SQL	Until the person who made them removes them, or the hierarchy they belong to is deleted. Share links and favorites stay until removed.
Change history and write-back runs with their changes	Forge SQL	One year. The app deletes older entries every day. This is on by default, and an admin can turn it off, in which case history is kept until the hierarchy is deleted.
Settings, permissions, app admins, limits and license state	Forge SQL	Until changed, or until the app is uninstalled.
Who someone is in Jira (group ids, Jira admin, project roles) and each project's schemes, shared between the app's instances	Forge SQL	Minutes: a person's groups and roles at most 5 minutes, visibility answers a minute.
Which work items Jira's events said changed: numeric ids and times only	Forge SQL	One day. A daily job removes older marks.
Names of the site's statuses, priorities, issue types, resolutions and link types, by id	Forge SQL	Until the app is uninstalled. The app refreshes them.
Assets objects that work items in hierarchies name: name, key, type, Assets' updated date and some attributes (text cut at 100 characters, numbers, dates, statuses and similar; never an email address or a hidden attribute)	Forge SQL	An object is dropped when no hierarchy names it. A hierarchy's note that it names an object goes after 7 days with no page naming it, or at once when the hierarchy is deleted. A hierarchy names at most 10,000 distinct objects by default.
Teams and capacity: teams, members (Atlassian account ids), positions, weekly hours, time off (days and hours only, no reason) and commitments	Forge SQL	Time off is cleared two years after it ends. The rest is kept until deleted. A deleted hierarchy's commitments are removed by daily maintenance.
Hours set by hand, holiday calendars, placeholder people, dependency types and lag, links for planning items	Forge SQL	Until a person deletes them or the hierarchy they belong to is deleted.
Baselines: name, who saved it and when; and the dates each item had, with an issue's remaining estimate in hours	Forge SQL and Forge key-value storage	Until someone with Edit access deletes the baseline (at most 10 per hierarchy). When a hierarchy is deleted, the daily job removes its baselines' stored dates and rows.
REST API: calls per caller and per site each minute (account ids and counts)	Forge SQL	Deleted after an hour.
REST API: for each idempotency key, a fingerprint of the request and the first answer, which can hold a hierarchy's or folder's name	Forge SQL	Deleted after 24 hours.
Search tokens on work items	Jira work item properties	Kept with the work items by Jira. The app removes a hierarchy's tokens when its search is turned off or the hierarchy is deleted.
Messages between the app's own functions, and live update hints	Forge platform	Short-lived. They hold ids, job kinds and times; a live hint holds at most 100 numeric work item ids.
Display choices such as text wrapping and the last hierarchy opened	The person's own browser	Until the person clears their browser data. They are not sent anywhere.
App logs	Forge logs	See Data Logging.

The app stores Atlassian account ids to record who owns a hierarchy, who has access and who made a change. It does not store people's names or email addresses; it asks Jira for them when it needs to show them. What people type into notes, memos and fields is stored as they wrote it.

When an Atlassian account is closed or deleted: the app does not yet remove or replace the account ids it holds for that account. Atlassian's personal data reporting API lets an app find out which of the account ids it stores belong to accounts that were closed or deleted. Support for it is being added to the app. Until then, the app does not do this by itself. An account id alone is not a name or an email address, and the app stores neither.

How data is deleted

Delete a hierarchy. Someone with Control access deletes it from its settings. This removes its rows, rules, write-backs and their records. Its baselines go with the next daily maintenance run. It cannot be undone. Work items stay in Jira. Archive a hierarchy instead to keep it out of the list without deleting it.
Daily maintenance. A daily job clears what nobody can reach any more: rows left behind by a deleted hierarchy (in two steps, so a hierarchy being made or copied is never touched) and replaced rule results. Admins can see the last run and run it on demand.
Old history. Change history and write-back runs older than one year are deleted every day, unless an admin turned that off.
Individual items. The person who owns a view, a saved column, a preset or a baseline can delete it.
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.
Backups and exports. A Jira admin can save a backup file, and anyone can export to Excel, CSV or JSON. The file is saved wherever that person chooses, and Plugincraft never receives it. A backup holds the private content of every hierarchy (rules, JQL, notes and who may see what) and never work item details, so it should be stored safely. Deleting data in the app does not delete files that were already saved; the person who saved them controls their retention.
Restore. A restore makes new hierarchies next to the existing ones and replaces nothing.
Imported spreadsheets. The file is read in the admin's browser and never sent anywhere. The app stores only the hierarchy made from it.

Requests about personal information

The data you created in the app is in your Jira site, so your site admins can export, change or delete it directly. For questions or requests about personal information that Plugincraft itself holds, see the privacy policy or write to the owner of Plugincraft Software inc., who is the person in charge of the protection of personal information, at info@plugincraft.ca.