TuneCraft privacy policy
Effective [date of publication]
The short version
- TuneCraft runs on Atlassian Forge and keeps its data in Atlassian's Forge storage for your Jira site, in your site's data residency location. It declares no outside network access and sends nothing outside Atlassian.
- Plugincraft receives none of the data the app reads or keeps. What it can read of the app is technical: the app's logs, and the usage metrics that Atlassian shows a publisher for each site. As for any paid app, Atlassian's Marketplace also gives it your licence and its contact details. An admin can choose to send us a support bundle.
- TuneCraft stores no email address and no text from your automation flows' settings. The texts people wrote that it keeps are the names of flows, what a Jira admin types as a setting, and, for 30 days, the old and new text of a label change.
- If a Jira admin turns on the automatic scan, a sender the customer runs pushes the redacted flows to the app's one web trigger, with a key. Section 6 says what it sends, what the app keeps and who holds the key.
- We don't sell personal information, use it for advertising or use it to train any model.
- Security, logging, data handling, AI and the data processing agreement are in the Trust center.
This policy explains what TuneCraft: Automation & Site Cleanup ("TuneCraft"), an app for Jira Cloud made by Plugincraft Software Inc. ("Plugincraft", "we", "us"), does with data. It covers the app only. Atlassian's privacy policy covers Jira itself, and the privacy policy of this website covers plugincraft.ca and the support we provide.
Plugincraft Software Inc. (in French, Logiciels Plugincraft inc.) is a company incorporated on October 26, 2026 under the Business Corporations Act (Québec) (CQLR, c. S-31.1). Its Québec enterprise number (NEQ) is 1182711235. We follow Québec's Act respecting the protection of personal information in the private sector and, where it applies, Canada's Personal Information Protection and Electronic Documents Act (PIPEDA).
Who to contact
The President of Plugincraft Software Inc. is the person in charge of the protection of personal information. For any question, request or complaint about your personal information, write to the President at info@plugincraft.ca. Put "Protection of personal information" in the subject line.
Roles
Your organization decides how TuneCraft is used and is the controller of the personal data in it. Plugincraft provides the software that processes that data on your behalf, as your processor. Our Data Processing Agreement sets out the terms. Atlassian hosts the app on its platform and is its only subprocessor (see Subprocessors).
1. What TuneCraft reads
Unless a line says otherwise, the app reads Jira as the person using it, with that person's own Jira rights.
- Your automation export. A Jira admin, or a member of a group that a Jira admin allowed at the Manage level, picks the export file in their browser, which reads it. A project admin sees the flows of their own project but cannot scan. Every value people wrote in a flow's settings (JQL, web request addresses and headers, email addresses, smart values, custom field names, values compared, comments and secrets) is replaced in the browser by a placeholder made with a key, and never reaches the app. The one exception is an Atlassian account id that a flow's steps name (an assignee, a watcher, a recipient, a Jira Service Management customer): for a scan a Jira admin starts, it is kept beside the flow, reported to Atlassian and erased when the account is closed.
- What a sender you run pushes. If a Jira admin turns on the automatic scan, the app's web trigger takes what the sender pushes to it: for each flow, its id, name, owner's and actor's account ids, project ids, its steps with every text replaced by a placeholder, the account ids those steps name, Jira's ids, keyed hashes and counts. The app reads nothing from Jira for it. See section 6.
- Your flows' JQL, and the work items they would process. After a scan, the browser of the person who scanned sends each flow's JQL, and each scheduled flow's search, to the Jira of the site the flow comes from, as that person. Jira says whether it accepts the JQL and how many work items the search finds now. A flow from another site's export is not sent. The app keeps only counts: the number found, and how many of a flow's JQL texts Jira refused or could not check. Never the JQL or Jira's words.
- Who you are and what you may do. When you open TuneCraft, it asks Jira whether you are a Jira admin or a project admin, and which groups you belong to.
- Names, as Jira shows them to you. The pages ask Jira for the names of the people, fields, statuses, spaces, versions, components, work types, groups, roles, schemes, filters, dashboards, boards and sprints they show, and search Jira for a name you type. They are shown to you and never stored. An email address that Jira returns with a person is dropped.
- What your flows name, and whether it is still there. Once a day, when a Jira admin has turned on the Automation tool's background checks, the app reads, as itself, the site's configuration that your flows name (fields and the field trash, statuses, spaces, versions, components, work types, priorities, resolutions, link types and filters) and whether each flow's owner and actor, and each account a kept flow's steps name, is still active (the actors of flows that are turned on are asked again every day, the other accounts every week). It reads no work item. It keeps what is broken, by Jira's ids or keyed hashes, and each account's last answer (active or not, and when) beside its account id.
- Your site's configuration and counts, for the clean-up tools. When a Jira admin turns a tool's background checks on, the app reads Jira as itself, in the background, within a budget of Jira points: configuration and counts only, never a work item. The tools are Limits, Fields, Spaces, Filters, Schemes and Workflows. The People tool has no checks of its own: it uses what Filters, Schemes and Spaces keep. Labels and Boards keep no reading of your configuration: they read Jira, as a Jira admin, when that admin has their pages open. (Attachments and Archiving read work items, as a Jira admin: see below.) They read, for example, spaces with their last update, custom fields with what Jira says of their use, filters and dashboards with their owner, last use and kind of share, permission schemes and their grants, workflows, and Jira's approximate counts of work items. Names are read in memory. What is kept is ids, counts, days, Jira's own vocabulary and keyed hashes; a filter's JQL is kept only as a keyed hash. The tool pages in the manual list what each one keeps. Where the app may not read something itself, a Jira admin's open page reads it, as that admin.
- Merging fields. To merge one custom field into another, the Fields tool reads both fields' contexts, options and screens, and the work items that hold a value, as the Jira admin who works on the page. To copy, it reads a work item's two values and writes the second, one work item at a time, without Jira's notification emails; the values stay in the app's memory for the seconds between and are never stored or logged.
- Changes you make with TuneCraft. When a Jira admin confirms a change in a clean-up tool, the app reads the objects again from Jira and makes the change as that admin, so Jira's audit log shows them. An undo is made the same way. The changes are: a filter's or a dashboard's owner, name, JQL (Filter repair, which writes a field's id in place of a name Jira no longer accepts, as the filter's owner, when that owner is the person confirming; taking a filter from its owner to repair it is not offered yet) or sharing (taking out sharing with anyone on the web, with every signed-in person or with a space Jira no longer shows); a custom field's values copied into another custom field (Merge fields), after the field to keep is prepared (options, spaces of a context and screens added to it); a custom field moved to Jira's trash, restored or deleted, and the options of a select field disabled or enabled; a space, a version or a component; a permission scheme or a project role; a status, a workflow or a workflow scheme; a sprint (renamed, closed with its open work items added to the next sprint or a new one, or deleted) or a board; spaces put on another work type screen scheme; work items archived, restored or moved to another status; a label renamed, merged or removed; attachments deleted; and people removed from a group. Some cannot be undone (deleting an attachment, a filter, a dashboard, a status, a workflow, a workflow scheme, a project role, a permission scheme copy, a version, a component, a board or a sprint; closing a sprint; deleting a field for good; and moving work items to another status) and the page says so before it asks. Before it deletes or renames an object (a filter, a dashboard, a status, a workflow, a workflow scheme, a project role, a permission scheme copy, a version, a component, a board, a sprint, a field to be deleted for good or an attachment), it reads what a record file holds and passes it to the admin's browser, which saves the file on their computer. The app keeps none of that.
- Labels. To rename, merge or remove a label, the app reads the site's list of labels and Jira's approximate count of the work items that carry each one shown, and searches the work items that carry the label picked. To change it, it edits their labels, as the Jira admin who confirms and without Jira's notification emails. It keeps the old and new label, and the ids of the work items it changed, for 30 days so that the change can be undone or carried on without a file. It also keeps, for 400 days, the labels as keyed hashes and the counts, and, while the run is open and for 30 days at most, the id of the last work item it handled.
- Attachments. To total the space that attachments take, the Attachments tool searches the work items that have attachments, as the Jira admin who has its page open: in the spaces that admin picks or, once a Jira admin turns the whole-site reading on, in every space that admin can browse, one space at a time, carrying on at the next visit. It reads each attachment's size, type, file name and date. It compares file names in memory to find copies and never keeps one. It keeps counts and sizes by space, file type and month, the ids of the 100 work items whose attachments take the most space, and, for a reading of picked spaces, the account id of the Jira admin who started it. Space names and work item keys are read from Jira when they are shown. To delete attachments, see "Changes you make with TuneCraft".
- Archiving. To archive old work items or close a stale backlog, the Archiving tool searches work items as the Jira admin who uses it, by a Jira filter that admin picks or by JQL that admin types, and shows a count, a sample and the spaces they are in. The sample is shown to that admin and never stored. The admin saves a record file, with the keys and summaries, before anything changes. When the admin confirms, the app archives the work items, unarchives them on undo, or moves them to a status the admin picked (a move cannot be undone), in batches and as that admin. For a stale backlog it checks each batch against Jira again just before it writes. The app keeps the ids of the work items and their state for 30 days after the run ends, and the run's counts and the admin's account id for 400 days. Until the run ends it also keeps how the run was started: its mode and, for a stale backlog, the space ids, a day and a status id. If nobody finishes or stops a run, the daily maintenance closes it 30 days after it started, and the work item ids go 30 days after each was recorded; how the run was started stays until 400 days after it was last written. It never keeps a filter's JQL or a work item's key, summary or text.
- Members of groups, and deactivated people. On the Groups page the app asks Jira for the first 50 members of each group a permission scheme grants something to, and for a group's members (up to 500) when you look for its deactivated people. They are shown to you and never stored. If you remove deactivated people from a group, the app removes them as you and keeps, for 30 days, their account ids and the group's Jira id so that you can add them back.
- Jira's audit records. When a Jira admin presses "Who did it" on the Change history page, the app reads Jira's audit records for the days they picked, as that admin. They are shown to that admin and never stored.
- What a work item type requires. In the forms that create work items, the app asks Jira which fields a work item type requires in the space you picked. It shows them to you and keeps them in memory for up to a minute. On the To do page, the values a Jira admin types or picks go through the app on their way to Jira, which creates the work items as that admin. They are never stored or logged.
- Work items near Jira's caps. When a Jira admin opens the Limits tool's page for work items near caps, at most once a day for the site, the app reads Jira's reports of work items over or near the caps, and searches those work items by id to leave out the ones that are done. They are shown to that admin only and never stored. The app keeps how many there are for each cap, and that admin's account id with the day.
- A user export, for paid seats. On the Seats page a Jira admin picks Atlassian's user export in their browser, which reads it. Only each paid seat's account id, the last day the person used the product and whether the person is a product admin reach the app. Names and email addresses stay in the browser.
- Your site's address. Before it creates an alert, the app asks Jira for your site's address, to link the alert to TuneCraft's Usage page. It is never stored.
- Your licence. The app reads your site's licence for TuneCraft from the context Atlassian passes with each request.
2. What TuneCraft stores, and why
The app stores the following in Atlassian's Forge hosted storage for your site. Names and texts that a line does not list are not stored.
| Data | Why |
|---|---|
| For each flow scanned: its id, name, trigger type, project ids, creation day, Jira's setting for its failure emails, for a scheduled flow its runs a month by its schedule (estimated), the Atlassian account ids of its owner and actor, a fingerprint of its structure, its score and its estimated step counts | To list findings by flow, tell owners, and recognize the flow in later scans |
| For each scan: the account id of the person who made it (or the app, for an automatic scan), when, and its totals | To show the history of scans |
| For a scan a Jira admin starts: each flow's structure (its steps, their order and settings), every text replaced by a keyed hash; in clear only numbers, true or false, the export's own words (an advanced schedule's cron included), Jira's own field names, project ids, and a basic schedule's frequency, start and end. Beside it, the account ids its steps name | So Jira admins can optimize a flow or all flows at once, and follow a flow from scan to scan without choosing the export again |
| For each flow of the last finished scan, and of the one being made: what it uses (the fields, options, statuses, projects, versions, components, work types, priorities, resolutions, link types, labels, filters and groups it names), each by Jira's id or by a keyed hash of its name, and how it uses it; counts for governance (web requests, credentials, fixed email addresses and those outside your organization's domains, whether a scheduled flow searches and how many work items it finds, a missing owner, an actor who is a person); what it names that Jira no longer has; how many of its JQL texts Jira refused. Never an address, a host, a header, a value or a JQL text. A keyed hash is a pseudonym, not a secret from whoever holds the database: the key is kept in the same storage, so a short name can be found again by trying candidates. A value that looks like a person is never hashed into this record | So Jira admins can see which flows use something before they remove or change it, review credentials, email and owners, and fix flows that fail or never act |
| From the automation audit logs chosen with the exports: for each flow, numbers and calendar days only (runs and how they ended, steps billed, run time, the day of the last run and of the last failed run); the site's runs and steps a day, by product; and, from a log that lists every run, the time of its newest run: one time for the whole log, with no flow, run, person or work item beside it, kept only when that log's last day is the day of the scan | To show which flows fail, are stopped by Jira's limits, run without doing anything or no longer run, to show usage beyond the 90 days Jira's log holds, and to forecast the month |
| For each paid seat of a user export a Jira admin chooses: the account id, the last day of use and whether the person is a product admin | So Jira admins can see paid seats nobody uses and product admins who have not been active |
| For each action on the To do page: its status, the account id of the Jira admin who set it, and the key of the work item a Jira admin linked to it | So Jira admins can track the clean-up they decided on |
| For each notice sent to a flow's owner: the flow (for a filter whose JQL Jira refuses, the filter's Jira id), when, the key of the Jira work item, the account ids of the person told and of the person who sent it, and what it was about. Not its text, which is in Jira, where everyone who can browse the project can read it | To list the notices sent about a flow |
| For each alert sent: its key (which kind of alert, for which product and period), when, and the key of the Jira work item. No account id. Not its text, which is in Jira, where everyone who can browse the project can read it | To list the alerts sent, and so that no alert is sent twice |
| Settings a Jira admin enters: the plan, number of users, the groups allowed, your organization's email domains, the alert settings (project, work item type, language, flow names or ids) and the account ids of the people alerts mention, naming conventions for filters, dashboards and sprints, the two numbers of days after which Sprints left behind counts a sprint as left behind, targets for checks (a number, with the account id of the Jira admin who set it) and guidance for checks (text the admin typed, 500 characters at most); the cost model's values, which a person at the Manage level may also save; and, beside each setting, the account id of the person who last saved it | To compute estimates, decide access, tell addresses inside your organization from those outside, create alerts, and record who last saved a setting |
| For the clean-up tools, while a Jira admin keeps a tool's checks on: configuration and counts by Jira's id (never a name), with when each was read, a row for each day a count changed, and a code made from a name with your site's key where copies must be found (custom fields, statuses, work types, priorities, resolutions, link types, workflows), and, for a custom field, the codes of the names it has had. For a filter or dashboard also its owner's account id and whether that owner is active. For a space's lead, the account id, only while Jira says the lead is inactive. For each person a permission scheme grants a permission to by name, active or not, the account id and the permission's key | To show what is unused, copied, broken or near a limit, and when a count would reach Jira's cap |
| The record of each change a clean-up tool made in Jira: the tool, when, the kind, the account ids of the Jira admin who made it and of a new owner, how many objects, the result, and until when it can be undone; for each object, Jira's id, its state and what an undo needs (ids, never names; for a rename, keyed hashes of the old and new name; for a deleted status, a keyed hash of its name and description, made with your site's key, so that a status renamed since it was confirmed is left as it is; for a deleted workflow or workflow scheme, how many workflows or statuses the delete left unused, as counts; for a repaired filter, keyed hashes of its JQL before and after, made with your site's key, never the JQL) | So Jira admins can see what TuneCraft changed and undo it while Jira allows |
| For each label change: the old and new label (the labels' text, 255 characters at most each) and the ids of the work items it changed | So the change can be undone or carried on within 30 days, without a file |
| For each merge of one field into another a Jira admin makes (Fields > Merge fields), 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 it touched, each with a code for what Jira answered. The values a merge copies pass through the app's memory and are never stored or logged; no field name, option text or work item key or summary is kept | So the change can be carried on, checked and undone; kept as the record says in section 5 |
| For each label change, how far it has got: the keyed hashes of the old and new label, its state and counts, and, while the run is open, the id of the last work item it handled | So a label change can run in slices, be stopped, carried on or undone, and show its counts; kept 400 days, except the last work item's id, which goes when the run stops and in any case after 30 days |
| For an Attachments reading: counts of work items, files and bytes by space, file type and month, the copies found on one work item (counts), the ids of the 100 work items whose attachments take the most space, and, for a reading of picked spaces, the account id of the Jira admin who started it. Never a file name, a work item's text or a space's name | To show where attachments take space and which work items hold copies |
| While an archive or stale-backlog run is open (if nobody finishes or stops it, until 400 days after it was last written): how it was started, its mode and, for a stale backlog, the space ids, a day and a status id. The work items' ids and states are in the record of changes above. Never a key, a summary, a filter's name or a JQL text | So the run can be stopped or carried on, and each batch of a stale backlog is checked again before it is written |
| The ignore list: for each proposal a Jira admin chose not to see again, the tool, the kind of object and Jira's id (for a flow, its id and the finding), the account id of the Jira admin who ignored it, the day, a reason code and the day it ends, if it has one; for a person who is ignored, that person's own account id. Never a name | So an ignored proposal is not made again |
| The watch list: for each field, space or filter a Jira admin put on watch, its kind and Jira's id, the account id of the Jira admin who added it, the day, 30, 60 or 90 days, the last day it was seen used and the day of the last check. At most 100 rows. Never a name | So a Jira admin can see whether something is still used before removing it |
| The change history: for each change a background reading saw in Jira's configuration, the kind, Jira's id and the day. Never a name, a query or a value | So Jira admins can see what changed on their site, and when |
| For 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 (see section 6); a record of each push in progress or just ended (its id, start time, state and counts); and the result of the last push (counts) with the time it was saved | To accept a push only from a sender with the key, to save the scan, to answer a part sent again without saving it twice, and to show a Jira admin what happened |
| The account ids the app stores, with when each was last stored and reported to Atlassian | For Atlassian's personal data reporting (section 5) |
| 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 | To use real numbers in place of estimates |
| For each fix that a scan confirmed: the flow's id, the finding, the steps saved, the day, the ids of the scan that confirmed it and, if one did, of the scan that found it undone, and the flow's name while the scan that confirmed it is kept | To show the steps that fixes saved, and which fixes a later scan found undone |
| For each scan: how its flows are linked (which can start which, copies, shared triggers, loops), by flow id; and how far the comparison of the scan with the one before has got (scan ids, a flow id, counts) | To show how flows relate, and to tell which fixes a scan confirmed or reverted |
| 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 | To keep a trial within its limits |
| 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). Numbers and days only | So the Tune score can be compared with the day before |
| For each background 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 | To carry a check on from where it stopped, keep to the points budget, and show a Jira admin what the checks did |
| Counts of the app's own maintenance runs, and its own Jira points a day by kind | To keep the app's storage tidy and show an admin what the app costs |
Flow names are text your team wrote. They are kept so that reports can name the flows. Kept flows are for Jira admins only. TuneCraft does not use your data for anything else, does not sell it, does not use it for advertising, and does not use it to train any model.
3. Where it is kept
All the data the app stores is in Forge SQL, Atlassian's hosted database for Forge apps, which belongs to your installation. It stays in your Jira site's data residency location and moves with the site if an admin changes that location. The app declares no outside network access, no remotes and no external fetch, and has no MCP tools and no REST API other than the automatic scan's web trigger. Its one remote entry point is the web trigger of the automatic scan (section 6). Plugincraft has no servers of its own. See Data Handling: Retention and Deletion.
4. Who can see it
In the app. The people your admins allow: Jira admins, members of the groups they allow, and a project's admins for that project's flows only. The clean-up tools are for Jira admins only. Jira's permissions apply to everything the app reads or changes in Jira as a person.
In Jira. The app creates Jira work items for alerts, owner notices and the To do page. Alerts are created as the app (Jira shows the app as the reporter), in the project and work item type that a Jira admin picked and may create in. Everyone who can browse that project can read them. They mention the people the admin picked, so Jira notifies them, and only those who can browse the project. By default they name flows by their ids only; a Jira admin may turn names on. Owner notices are created as the person who sends them, who needs the Manage level, and the To do page's work items as the Jira admin who confirms them.
Plugincraft. Plugincraft receives none of the data the app reads or keeps. What it can read of the app is technical, and it is more than the logs:
- the app's logs, which Atlassian keeps and Plugincraft can read to fix problems (section 7);
- the usage metrics that Atlassian shows a publisher for each site where the app ran: calls, errors, response times, query times and database size, with the site's address;
- your licence and its contact details, which Atlassian's Marketplace gives a publisher for any paid app;
- a support bundle, only if a Jira admin chooses to send us one. It holds versions, the licence state, table sizes, counts and the last maintenance runs, never flows or people.
A site admin can turn off the publisher's access to the app's logs in Atlassian administration.
Requests from authorities. Plugincraft holds no copy of the data you store in TuneCraft: it stays in Atlassian's storage for your Jira site. If a court, the police or another authority asks us for that data, we refer the request to you or to Atlassian. If a request concerns you, we tell you before we answer it, unless the law forbids it, and we disclose only what the law requires.
5. How long
- Scans. The last 24 scans are kept and, while none of them kept what its flows name (a sender that sends summaries only, or a database nearly full), so is the latest scan that did. The daily maintenance removes older ones, and a person at the Manage level can delete any scan sooner on the History page. What flows use, and the governance counts, are kept for the latest scan that kept them and for the scan being made; the daily maintenance removes them from older scans. The counts of a scan that kept no references stay as long as that scan, among the last 24. A kept flow stays while a scan that names it is kept.
- Fixes. A fix that scans confirmed stays as the record of what was saved (the flow's id, the finding and the steps). The flow's name is removed once the scan that confirmed it is no longer kept.
- Counts and histories. Automation usage, the alerts sent, the history of findings, Limits history, the change history and Jira points a day are kept 400 days (the one time of a log's newest run, until the next scan of a log that lists every run and ends the same day or later replaces it). Run health is one row for each flow, replaced by each newer audit log and removed once the flow is no longer in the last scan and its row has not been replaced for 90 days; the days the logs covered are kept 400 days. A tool's readings of Jira are kept while a Jira admin keeps its checks on, removed when Jira no longer has the object, and removed 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. Two more readings follow their own rules. The codes of the names a custom field has had (they let Filter repair point a filter at a renamed field) are kept until 400 days after the name was last seen, also for a field Jira has deleted, and are removed within a day after the Fields checks are turned off. What the Automation tool's Broken flows reading found (what a flow names that Jira no longer has) is kept with its scan, and is not removed when the checks are turned off.
- Records of changes. The record of a change is kept 400 days, each of its objects 30 days, and a label change's old and new label 30 days. A change that was started and never finished or stopped (a tab closed halfway through removing people from a group, or changing a label) 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, with the work item ids and the account ids in them, go 30 days after each was recorded. An archive run left open also keeps how it was started until 400 days after it was last written. A label change's run (the keyed hashes of its labels and its counts) is kept 400 days, with the record of the change; the id of the last work item it handled goes when the run stops, and in any case 30 days after it. A merge of one field into another keeps its run (the two field ids and its counts) 400 days, and the id of the last work item it handled 30 days after the run.
- People. Owner notices are kept a year. The people alerts mention are kept while they are picked. The seats of a user export are kept until a Jira admin uploads a new file or removes it, and at most 90 days after the upload. A To do action's status and the account id of who set it are removed 400 days after a reading confirmed it done, or once no reading has seen its problem for 400 days; an action that was ignored, or marked done without a reading's confirmation, stays while a reading still shows the problem.
- Ignore and watch lists. Kept until a Jira admin stops them, until the days an ignore was set for are up, or until 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. The account ids in them are erased when an account is closed.
- Targets. A target a Jira admin sets for a check is kept until the admin removes it, and 400 days after it was met. The account id of the admin who set it is erased when the account is closed.
- Other records. Measured run counts are kept until a person at the Manage level removes them, and are removed 90 days after the day measured once the last scan no longer has the flow. A scan's links and the progress of its comparison go with the scan. The site health numbers are kept 400 days, and the background checks' daily figures 14 days. The one flow a trial may optimize, and the trial's count of changes, stay while the app is installed.
- Attachments readings. A reading of picked spaces is kept 90 days. A whole-site reading is kept until a newer one finishes.
- Automatic scan pushes. The parts of a push are deleted when the push ends. A push that never finishes is removed by the daily maintenance once it is an hour old, three hours old if the app had begun to save it, or 26 hours old if the sender asked the app to keep it open for several runs (see section 6).
- Closed accounts. The app reports the Atlassian account ids it stores to Atlassian once for each reporting cycle (7 days unless Atlassian names another), as Atlassian requires of apps. When Atlassian says an account was closed, a daily run removes that account id from all the app's data, usually the same day, and keeps only the bare id for about one more cycle so that it is not reported again.
- Uninstall. When you uninstall TuneCraft, Atlassian deletes the app's stored data under its data retention rules. It keeps the data for 30 days, then permanently deletes it, and can relink a reinstall to the old data on request within 21 days. We keep no copy. See Data Handling.
6. The automatic scan
A Jira admin may turn on the automatic scan. Then a sender, a script the customer runs, reads each rule's real text with the customer's own Atlassian API token, redacts it on the customer's side by rules at least as strict as the browser's, and pushes the result to the app's web trigger, in parts of at most 58,000 bytes. A rule the sender cannot redact is not sent and is counted. The app records such a scan as made by the app, not by a person, and keeps what it receives as it does for a scan a Jira admin starts.
The customer chooses where the sender runs: on its own systems, or as a scheduled job in ScriptRunner Cloud, a script app from another publisher that the customer has installed on its Jira site. In that case ScriptRunner reads the rules' real text and holds the customer's API token, under the customer's own agreement with that publisher, before anything reaches TuneCraft. The token never reaches TuneCraft or Plugincraft.
What the app receives. For each flow: its id, name, whether it is turned on, the account ids of its owner and actor, its project ids, its steps with every text in their settings replaced by a placeholder, the account ids those steps name, Jira's ids, keyed hashes and counts. Flow names are text your team wrote; they are kept and shown as written. The app never receives a text from a rule's settings: it checks every flow when it arrives and again before it saves the scan, and one flow that is not redacted refuses the whole push, with nothing of it kept.
The web trigger. It is the app's one remote entry point. It takes a POST only, with a key in the Authorization header, and answers with one of ten fixed replies (accepted, unauthorised, unlicensed, too large, bad request, out of order, replayed, limit, try later, error), never with data. It refuses a push without a licence for the app (a trial counts), more than 6 pushes a day for the site, more than two open pushes at once, a request over 150 KB, and a push of more than 800 parts or 20,000 flows.
The key. A Jira admin makes the key on the Automatic scan card of the Scan page and sees it once. It has two parts. One is a secret that the sender sends with each push to show that it may; the app keeps only a one-way hash of it, made with the site's id and a secret of the app's own that is held in an encrypted Forge variable. The other is the site's scan key, the key behind every keyed hash in this policy, which the sender needs to make the same keyed hashes as the browser; the app also keeps it in its storage, and the browser of anyone who scans receives it. Whoever holds the whole key can push scans to the app, and can test guesses against a keyed hash (a pseudonym), so keep it as you keep the API token, in the sender's secret store. Replacing the key or turning the automatic scan off stops the old secret at once. It does not change the scan key.
While a push is under way. The parts of a push wait in the app's storage until the last one has arrived and the app has saved the scan; then they are deleted. A push that never finishes (a sender that stopped) is removed by the daily maintenance once it is an hour old, three hours old if the app had begun to save it, or 26 hours old if the sender asked the app to keep it open for several runs. The waiting parts hold the same data the saved scan will, including the account ids of owners, actors and the people the steps name. Those ids are added to the list that the app reports to Atlassian when the scan is saved: for the hours a push waits they are not on it, and a push that never finishes is deleted without having been reported.
7. Logs and support
Atlassian keeps the app's technical logs, which Plugincraft can read to fix problems. They hold ids of the app's own records, counts, states and error codes only, never the content of your flows, names or email addresses. Atlassian keeps app logs under its own retention rules (its documentation says logs are available for the past 30 days). See Data Logging.
When you write to us, we keep your message, your email address and anything you choose to include, as the privacy policy of this website describes. Each admin decides whether to send a support bundle.
8. AI features
On a site with Rovo, TuneCraft has an AI helper, the TuneCraft helper, that a person opens from an Ask Rovo button. It is Atlassian's Rovo: the model is the one Atlassian provides on its platform, and TuneCraft sends nothing outside Atlassian. The prompt from the button names what the person is looking at by its id (a flow, field, filter or space number, never JQL, a label's text or a secret). To answer, the helper asks TuneCraft for what the person may see: counts, ids, the findings and savings of the last scan, and names the person's own pages already show. Those answers go to Rovo and are shown to that person only. The helper never changes Jira. On a site without Rovo, the app has no AI feature. See the AI Usage Policy.
9. How we protect it
Access to our accounts and records is limited to the people who need it and protected with strong passwords and two-factor authentication. The app relies on Atlassian's security for everything it stores. To report a vulnerability, see the Security overview. How we handle incidents is in Incident Response.
If a confidentiality incident involving your personal information creates a risk of serious injury, we will tell you and the Commission d'accès à l'information du Québec promptly, as the law requires. We keep a register of every incident.
10. Your rights
Requests about personal data in TuneCraft (access, correction, deletion) go to your organization's Jira admins, who control the data. They can view it in the app, and a person at the Manage level can delete scans on the History page. We help them as your processor.
For personal information that Plugincraft itself holds, you can ask us to tell you what we hold about you and give you a copy, to correct anything that is wrong, to delete what we no longer need, and to stop using it for a purpose you agreed to. Write to info@plugincraft.ca. We may ask you to confirm who you are. We answer within 30 days, and it's free. If you aren't satisfied with our answer, you can complain to the Commission d'accès à l'information du Québec or the Office of the Privacy Commissioner of Canada.
11. Children
The app is meant for businesses and is not aimed at children under 14. We don't knowingly collect their information.
12. Changes to this policy
If we change this policy, we'll update the date at the top of this page. If a change is significant, we'll also announce it on this page before it takes effect, and in the app's "What's new".
13. Language
This policy is available in English and French. Both versions have the same value.