How Customer Access & Organizations for Jira Service Management handles data
Summary
- The app runs entirely on Atlassian’s Forge platform and is eligible for the Runs on Atlassian program. It does not send your data to any server outside Atlassian.
- The app stores data only in Atlassian-hosted Forge storage, which follows your site’s data residency location.
- Only space administrators (and, for the Customer Service Management page, Jira administrators) can view reports or make changes. Jira itself refuses the pages for other users, and the app checks permissions again on every request. The dashboard widget’s counts are also shown to the space’s agents.
What the app reads
The app reads data on behalf of the administrator using it, with that administrator’s permissions:
| Data | Why |
|---|---|
| Service spaces, their linked organizations, and their customer lists | To work out who can raise requests |
| Organization names and members (name, email where visible, account ID, and active status) | To list people and how they got access |
| Requests in the space (reporter, status category, and created date) | To count requests per person and find the last request date |
| For the dashboard widget: requests per organization, SLA status, and satisfaction rating | To count requests, SLA breaches, and ratings per organization |
| The space’s roles, its permission scheme, who holds the agent and administrator permissions, and the members of the groups that give those permissions (name, email where visible, account ID, and active status) | To list the people who work on the space and how they came by that access |
| Customer Service Management customer experiences and their organizations | For the customer experience access report |
| The administrator’s own permissions and display name | To confirm access and record who built a report |
What the app changes
The app changes something in Jira only when an administrator explicitly applies a checked bulk change file: creating organizations and portal customers, adding or removing organization members, and linking or unlinking organizations to the space. Every applied batch is logged with who applied it and when.
Building a report changes nothing, but one of its questions to Jira is worded as a removal. Jira has no way for an app to ask whether a space is open to anyone or restricted. So the app asks Jira to remove a made-up customer who cannot exist (for example, an account ID of all zeros), and reads which refusal comes back. Jira refuses the request either way, and no customer is removed.
What the app stores
| Stored data | Retention policy |
|---|---|
| Report snapshots per space: people (name, email where visible, account ID, account type, and status), organizations, request counts, access paths, and domain suggestions | The 12 most recent snapshots per space are kept |
| With each snapshot, the people who work on the space: agents and administrators (name, email where visible, account ID, status, and the roles and groups their access comes through) | Deleted with the snapshot |
| Customer experience report | The latest report only |
| Bulk change files, checks, and results | The latest check, plus the last 20 applied batches |
| Automatic snapshot schedule (frequency, the administrator who set it, and next run) | Until changed or turned off |
| Dashboard widget counts: organization names and numbers per organization (no people) | The latest count for each set of widget settings, deleted when nobody has viewed it for 30 days |
| The app’s own bookkeeping: which spaces use it, how much it has done this hour (for its limits), and when the weekly privacy run last ran | While the app is installed |
All stored data is in Forge-hosted storage on Atlassian’s infrastructure, in your site’s data residency location.
Diagnostic logs
Like every Forge app, this app writes technical log lines to find faults. Atlassian keeps them, and the app’s developer can read them. They record what kind of job ran, for which site and space (by their IDs), how many people or rows it handled, how long it took, and what kind of error stopped it. They contain no names, email addresses, or request contents. Account IDs and addresses that appear in an error message are masked before it is logged. Atlassian shares these logs with the developer by default. A site administrator can stop that in Atlassian Administration: open the site’s Connected apps, choose Customer Access & Organizations, and turn off Logs access on its Details tab.
A few actions that tell the developer where the app needs attention are logged the same way, by site and space and never by person. They are a snapshot schedule being changed, an undo file being made from a bulk change, a space’s app data being reset, diagnostics being downloaded, and the app being opened on a site whose license has ended.
The app also logs which of its parts are used, so its developer can see what is worth improving. A line says that a page, a tab, an export, or the guide was opened in a space that day, with the site’s and the space’s IDs and the state of the site’s license. It does not say by whom or by how many people, how many times, or what was looked at or exported. No usage data is sent anywhere but these logs.
If a page of the app fails in your browser, it shows a message saying so. One more log line is then written: which page, the kind of error, and the first words of the error’s own message, with any email address or account ID in it masked. Nothing the page was showing is sent.
Support details and diagnostics
Each page offers Copy support details, and a space’s page also offers Download diagnostics. The app sends neither anywhere. They are for you to send to support if you choose. The support details are a few lines naming your site, the page, the space, and the report, with any message showing on the page. The diagnostics file describes one space as numbers, times, and settings. It gives how many customers, organizations, roles, and groups there are, the sizes of the organizations and groups, and the state of the report, the schedule, and the last bulk change. It holds no names of people, organizations, roles, groups, or spaces, no email addresses, and no account IDs.
Deleting a space’s data yourself
An administrator of a space can delete everything the app has stored for it, at any time, with Reset this space’s app data at the foot of the space’s page. Nothing in Jira is changed. Uninstalling the app deletes what it stored for every space.
Closed Atlassian accounts
Every week the app tells Atlassian which accounts it holds data about, as Atlassian requires of apps that store personal data. When Atlassian reports an account closed (for example, after a request to be forgotten), the app erases the person from everything it stores:
- Closed accounts are removed from people lists in every kept snapshot and in the customer experience report, and their totals are recalculated. They do not appear as a change between snapshots.
- Domain suggestions no longer list closed accounts.
- Bulk change records keep what was done but show Closed account instead of the person. Undo files leave out those rows.
- Where a closed account built a report or applied a batch, Closed account is shown instead of their name. If they set up automatic snapshots, the schedule is paused until someone chooses a frequency again.
This usually happens within a week of the closure. Atlassian sets how often apps report, and may lengthen it. A person named in one space only by email, and known by account in another, can take up to two weeks. To find those rows, the app keeps a one-way fingerprint of a closed account’s email address (not the address itself) for 60 days, then deletes it.
Changed names and email addresses
A snapshot is a record of the day it was built. When someone changes their name or email address, snapshots already kept still show the earlier one until newer snapshots replace them (the app keeps the 12 most recent for each space). Every new report and snapshot reads the current name and email address from Jira.
When a space is deleted
If a space is deleted in Jira, the app keeps what it stored for that space during the period when Jira could still restore the space. Once the space has been gone from Jira for 90 days and nobody has used it in the app for 90 days, the app deletes everything it stored for that space. This covers reports, snapshots, bulk change records, widget counts, and the snapshot schedule. An automatic snapshot schedule for a space that cannot be found is paused immediately.
When you uninstall
Atlassian soft-deletes the app’s stored data when it is uninstalled and permanently deletes it after 28 days. If you reinstall within 21 days, the previous data can be restored on request. Otherwise, the reinstalled app starts empty.
Automatic snapshots
Scheduled snapshots run on behalf of the administrator who turned them on. Before each run, the app confirms that the administrator still administers the space. If not, it pauses the schedule instead of running.
Exports
CSV exports are built inside the app on Atlassian’s infrastructure and downloaded directly to your browser. They contain only data you can already see in the report. Values that start with =, +, -, or @ are prefixed so spreadsheet programs do not treat them as formulas.
Reporting a security issue
Write to security@kingstonfalls.com. Reporting a security issue says what to include and how quickly we respond.