Data Processing Agreement
Effective [date of publication]
The short version
- This agreement applies to the personal data TuneCraft processes for a customer, and forms part of the terms of service.
- The customer is the controller. Plugincraft is the processor, and processes the data only to provide the app.
- TuneCraft runs entirely on Atlassian's Forge platform. Plugincraft operates no server that receives the customer's data and has no access to the data stored on the customer's site.
- Atlassian is the only sub-processor. Plugincraft tells the customer at least 30 days before adding one.
1. Parties and scope
This agreement is between the customer that installs TuneCraft: Automation & Site Cleanup on its Atlassian site (the "Customer") and Plugincraft Software Inc. (in French, Logiciels Plugincraft inc.), a corporation incorporated under the Business Corporations Act (Québec), Québec enterprise number (NEQ) 1182711235 ("Plugincraft"). It applies to personal data that TuneCraft processes for the Customer, and forms part of the terms of service under which the Customer uses TuneCraft.
2. Roles
The Customer is the controller of the personal data. Plugincraft is the processor and processes it only to provide TuneCraft, on the Customer's documented instructions, which are the terms of service, this agreement and the Customer's use of the app's settings.
3. What is processed
| Item | Details |
|---|---|
| Data subjects | The Customer's users who own, run or scan automation flows on its site, or whose flows a sender the Customer runs pushes; the people a flow's steps name (for example an assignee, a watcher or a recipient, Jira Service Management customers included); the people a notice tells (a flow's owner or actor, or anyone active on the site whom someone the Customer allowed to manage TuneCraft picks) and the people who send notices; the people a Jira admin picks for the usage alerts to mention; the Jira admins who set up alerts, type usage counts, send test alerts, change settings, set the status of an action on the To do page, or read Jira's report of the work items near its caps; the people at the Manage level who save the cost model; the owners of filters and dashboards, the Jira admins who change them and the new owners they pick; the people a permission scheme grants something to by name, active or not; the Jira admins who ignore a proposal, put an object on watch or set a target for a check, and the people they ignore; the Jira admins who start an Attachments reading or an archive; people removed from a group and the Jira admins who remove them; and the people who hold a paid seat in the user export a Jira admin uploads. |
| Personal data | Atlassian account ids, including those a flow's steps name (kept beside the flow's redacted structure, for scans a Jira admin starts). For each account id kept, whether Jira said the account was active when TuneCraft last asked, and when. For each paid seat in an uploaded user export: the account id, the last day the person used the product and whether the person is a product admin. For a To do action: the account id of who set its status and the key of the Jira work item linked to it. The account id of the owner of each filter and dashboard (with whether the account is active), of a space's lead while Jira says the lead is inactive, of each person a permission scheme grants a permission to by name (with the permission's key), of the Jira admin who ignored a proposal, put an object on watch or set a target for a check, of a person who is ignored, and, for an Attachments reading of picked spaces, of the Jira admin who started it, and of the person who last saved each setting (a Jira admin or, for the cost model, a person at the Manage level). The record of each change a clean-up tool made (who made it, the new owner, each object's owner before, and the account id of each person removed from a group, with the group's Jira id). While they wait to be saved, the flows that a sender the Customer runs pushed to the automatic scan: their names, the account ids of owners, actors and the people the steps name, and the redacted steps. Names of automation flows, the text a Jira admin types as a setting (naming conventions, the two numbers of days of Sprints left behind, targets, guidance for a check) and, for a label change, the old and new label for 30 days (text the Customer's users wrote, which may contain personal data). |
| Not stored | Email addresses (TuneCraft drops any Jira returns with a person's name). The texts of automation flows' settings (JQL, web addresses, headers, smart values, custom field names, values compared, comments, secrets), which never reach the app: each is replaced in the uploading person's browser, or in the Customer's own sender, by a keyed hash, except an account id, kept beside the flow. A flow's JQL goes from that browser only to the Jira of the site the flow comes from, as that person, to be checked and counted there; the app keeps only the counts. The work items that Jira's per-work-item limit reports and the search that leaves the done ones out return (their ids, keys and spaces) are shown to the Jira admin who read them and never kept. The same goes for the sample an Archiving search shows and for the file names of attachments, which an Attachments reading compares in memory. The names and email addresses in an uploaded user export stay in the Jira admin's browser. |
| Purpose | Reporting on the Customer's automation flows, the automation steps they spend, proposed fixes and savings; forecasting the month's automation usage; checking and cleaning up the Customer's Jira configuration, with the Customer's Jira admins confirming each change; telling the people a flow concerns, through Jira work items created as the person who sends them; and alerting the people a Jira admin picks when the forecast nears the allowance, through Jira work items TuneCraft creates as the app (Jira shows the app as their reporter) in the project and work item type that admin picked and may create in; and, if the Customer turns it on, receiving the redacted scan that a sender the Customer runs pushes to the app (the automatic scan). |
| Duration | While TuneCraft is installed. Scans beyond the last 24 are removed, except that, while none of the last 24 kept what its flows name, the latest scan that did is kept too. A notice's record (whom it told, who sent it) is removed after a year. Automation usage counts (and the one time of a log's newest run, which stays until the next scan of a log that lists every run and ends the same day or later replaces it), readings' histories, the record of each change and of each alert sent are removed after 400 days; each changed object after 30 days, and a label change's old and new label after 30 days; a merge of one field into another (the two field ids and counts) after 400 days, with the ids of its work items after 30 days; a label change's run (keyed hashes of its labels and counts) after 400 days, and the id of the last work item it handled when the run stops or after 30 days at most. 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; the criteria of an archive run left open stay until 400 days after they were last written. The people alerts mention are removed when they are no longer picked. The ignore and watch lists are kept until a Jira admin stops them, an ignore's days are up, or Jira no longer has the object (for a flow, once the last scan no longer has it and the ignore is more than 30 days old); a watch also goes within a day when the checks of its tool are turned off. A target for a check is kept until a Jira admin removes it, and 400 days after it was met. An Attachments reading of picked spaces is kept 90 days. An uploaded user export's seats are kept until the Jira admin uploads a new file or removes it, and in any case 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. The parts of an automatic-scan push are deleted when the push ends or, for a push that never finishes, by the daily maintenance 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); until the scan is saved, the account ids in those parts are not yet on the list the app reports to Atlassian. |
| Location | Atlassian's Forge hosted storage for the Customer's site, in the site's data residency location. |
4. How TuneCraft runs
TuneCraft runs entirely on Atlassian's Forge platform. Its processing and storage happen on Atlassian's infrastructure under Atlassian's own terms with the Customer and with Plugincraft. Plugincraft operates no server that receives the Customer's data and has no access to the data stored on the Customer's site.
If the Customer turns on the automatic scan, one thing is added: a Forge web trigger that takes the redacted flows that a sender the Customer runs pushes to it (section 6). The sender runs on the Customer's own systems or as a scheduled job in ScriptRunner Cloud, a script app from another publisher that the Customer installed on its site. It is the Customer's own sender, not a sub-processor of Plugincraft: it reads the rules with the Customer's own Atlassian API token, which never reaches TuneCraft or Plugincraft.
5. Plugincraft's obligations
Plugincraft:
- processes the personal data only as described in section 3;
- ensures that its people who work on TuneCraft are bound by confidentiality;
- builds and maintains TuneCraft with the measures in section 6;
- uses no sub-processor other than Atlassian's platform on which the Customer installs the app, and informs the Customer at least 30 days before adding one, so the Customer can object;
- helps the Customer answer requests from data subjects, mainly by providing the app's own means to view and remove data;
- informs the Customer without undue delay, and within 72 hours where possible, after becoming aware of a personal data breach affecting TuneCraft, and reports it to Atlassian as Atlassian's Marketplace rules require;
- helps the Customer with data protection impact assessments where TuneCraft is concerned;
- makes available the information needed to show compliance with this agreement, and answers reasonable audit questions in writing.
6. Security measures
- Every text in an automation flow's settings is replaced in the uploading person's browser, or in the Customer's own sender, by a keyed hash before anything is sent; no such text is ever stored. 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 (an account id or an email address) is never hashed into the record of what each flow uses. The app stores a flow's structure only so redacted, checks it again and refuses one that isn't, and no page is given its hashes, only numbered chips.
- Access to the app is checked on the server for every request: Jira admins, groups the Customer allows, and project admins for their own projects only. A check that cannot complete refuses the request.
- The app requests the fewest Jira permissions it needs, declares no egress, and receives or stores no password or Atlassian API token. For the automatic scan it has one web trigger, which takes a POST only with the key a Jira admin made, answers with fixed replies and refuses any flow that is not redacted. It keeps only a one-way hash of the key's secret, made with a secret of the app's own held in an encrypted Forge variable. The key also carries the site's scan key, the key behind the keyed hashes, because the sender needs it to make the same hashes: whoever holds the whole key can push scans to the app and test guesses against a keyed hash, so the Customer keeps it as a secret. Replacing the key or turning the automatic scan off stops its secret at once; the scan key does not change.
- Logs hold ids of the app's own records, counts and error codes only.
- Code changes are reviewed, tested and scanned for secrets before release; vulnerabilities are fixed within the deadlines of Atlassian's Marketplace security bug fix policy. See the Security overview.
7. End of processing
When the Customer uninstalls TuneCraft, Atlassian deletes the app's stored data under its data retention rules. Plugincraft holds no copy to return or delete.
8. Transfers
Plugincraft does not transfer the personal data: it stays in Atlassian's hosted storage in the site's data residency location.
9. Contact
Privacy questions: write to the President of Plugincraft Software Inc., the person in charge of the protection of personal information, at info@plugincraft.ca.