Guide to Customer Access & Organizations for Jira Service Management

Customer Access & Organizations shows which customers can raise requests in each Jira Service Management (JSM) space and in each Customer Service Management (CSM) customer experience, how they got that access, and what changed over time. It also helps you manage organizations in bulk.

Where to find it

Tip: Bookmark the pages after the first visit. The Apps section in Space settings starts collapsed.

This guide is also available at the foot of each of the app’s pages, under Help: read the guide.

First steps

1. Open Access report in a restricted service space, and click Build report. Most spaces take under a minute to build. A space with tens of thousands of customers can take a few minutes.
2. Look through the tabs:
   • People lists every customer who can raise requests, with how they got access (through an organization or added directly), account type and status, request counts, and the date of their last request.
   • Organizations lists each linked organization with counts for its members, deactivated members, members with hidden emails, and requests.
   • Changes shows what changed since an earlier snapshot. It appears after the second build.
   • Domain suggestions lists people whose email domain matches an organization they are not in yet.
   • Agents and admins lists the people who work on the space: who can work on its requests, who can administer it, and the roles and groups that access comes through.
3. Export any tab to CSV for your access review. Each export starts with a summary block (space, build time, who built it, and totals).
4. Turn on Automatic snapshots (weekly or monthly) so the Changes tab is ready for your next review.

How access is worked out

• Everyone in an organization linked to the space can raise requests, so every member of a linked organization is included.
• Customers added to the space directly come from JSM’s customer list for the space.
• JSM’s own customer list can take hours to update after organizations or members change in bulk. The report reads memberships directly, so it is accurate as soon as it is built, and it tells you when JSM’s list has not caught up.
• Spaces open to anyone have no list of people to review, and the report says so. Who “anyone” is depends on the site’s customer access settings (anyone on the web, approved domains, or existing accounts).
• Restricted access covers the portal, the widget, and email, but not chat. Someone who raises a request from Slack or Microsoft Teams is added to the space as a customer by Jira and then appears in the report as added directly.
• When you revoke a portal customer’s access, Atlassian hides their organization memberships so they drop out of the report. If you restore the customer’s access, their organization memberships reappear. The Changes tab shows both.
• The report follows Jira’s customer settings.
• In CSM spaces, access is set per customer experience. Use the Customer experiences tab of the Customer access overview page for those.

Snapshots and changes

• A snapshot is a report built at a specific time.
• The 12 most recent snapshots per space are kept, and the older ones are deleted automatically.
• Automatic snapshots run on behalf of the admin who turned them on, with that admin’s permissions. If that admin can no longer administer the space, automatic snapshots pause and the page explains how to resume.
• The Changes tab lists who gained or lost access; whose organizations changed; deactivated or reactivated accounts; and which organizations were linked, unlinked, or renamed. You can compare with any kept snapshot.

Bulk organization changes

1. Switch to Bulk organization changes at the top of the page.
2. Upload a CSV or paste text. Download template shows the format. Actions are:
   • Add member.
   • Remove member.
   • Link to this space.
   • Unlink from this space.
   • Create organization.
3. Click Check changes. Each row is shown as Ready, No change, or Error. Error rows will include a reason. Ready rows also say whom they affect, how many people a link or unlink covers, and every space where a member change adds or removes access.
4. Review, select the confirmation, and click Apply. Only the person who ran a check can apply it, and a check more than an hour old must be repeated first.
5. Download the results. The last 20 applied batches are listed under Recent bulk changes.

Rows are applied in the order of the file. A row that repeats an earlier one changes nothing the second time, and the check shows it as No change. For example: add, remove, add leaves the person added.

Organizations are shared across spaces. Adding or removing members changes access in every space an organization is linked to. Spaces whose links you cannot see are noted in the check.

Undoing a batch

The Undo feature works by preparing a new bulk organization change. Click Undo these changes after applying, or click Undo next to a batch under Recent bulk changes. This loads a file that reverses the applied rows, newest first, and it goes through the same bulk check process before anything changes. Organizations and customer accounts that the batch created are not deleted. Jira can take a minute to show applied changes, so wait a moment before rebuilding the report or checking an Undo file.

Preparing the file

The app expects normal CSV formatting.

Files separated by commas, semicolons (as Excel saves CSV in many regions), or tabs all work. You can copy cells straight from a spreadsheet into the paste box.

• Excel: Save As → CSV UTF-8 (Comma delimited).
• LibreOffice Calc: Save As → Text CSV (.csv).

How organizations and people are found

Organizations are matched by name, ignoring capitals and extra spaces.

People are matched only by exact email address or account ID. Someone who hides their email address in their Atlassian profile cannot be matched by email. Use the Account ID column for them.

Agents and admins

An access review usually asks about both sides of a space: the customers who can raise requests, and the people who can work on them.

Each person is shown as an agent, an admin, or both, with the roles they were given by name and the groups their access comes through. Above the list are the roles and groups that give access in this space, with how many people each holds.

Jira is asked who holds each permission, so the list is Jira’s own answer, not the app’s reading of your settings. That means:

• The list is usually longer than your licensed agents. It is everyone Jira lets work on the space. Jira admins, and anyone that a role, a group, or the permission scheme lets in, are counted whether or not they have a Jira Service Management license. Licenses are listed in Atlassian Administration.
• Someone in a role who has no access to Jira Service Management is not listed. They cannot work on requests.
• A deactivated account that is still in a role, or still in a group that gives access, is listed and marked. It has no access now but would have it again if reactivated. Remove it from the role or group if it should not have access.

If Jira will not show you a group’s members, the group is still named without showing the members. Seeing a group’s members needs Jira’s “Browse users and groups” permission. Apps that hold access are counted, not listed.

Export staff (CSV) downloads the list with the same summary block as the other exports.

Customer access overview

This page is for a Jira admin or an auditor who needs the whole site at once. Its first tab, Service spaces, lists every service space with the totals of its latest access report. For each space, it shows:

• Whether customer access is restricted or open.
• How many customers can raise requests and through how many organizations.
• How many deactivated accounts are still in organizations with access.
• How many people work on the space.
• When the report was built and whether automatic snapshots are on.

The number in parentheses after a space’s customers is how that count has moved since the previous snapshot.

Each number is as of the date in Report built, so check that column. A report over 30 days old is marked. The filter Needs attention shows spaces with no report, a failed build, or an old one.

Build the reports that need it starts a build for every space with no report, a failed build, or a report over 30 days old. A new site then does not have to be set up one space at a time. Each is built as you, in the background, exactly as its own Build button would. Some start at once, and the page says how many are left. A space you do not administer is left alone, for its own admin to build. Builds that find no room wait their turn and start by themselves.

Click a space’s name to open, build, or rebuild its report. Export overview (CSV) downloads the table.

Requests by customer organization (dashboard widget)

Add Requests by customer organization to any Jira dashboard. On new dashboards, it is a widget. On classic dashboards, it is a gadget. When editing or adding a widget, these are the settings:

• Service space: any service space you can see.
• Count each request under: the organizations its reporter belongs to (the default), or the organizations it’s shared with. Customers often do not share their requests with their organization, so the first usually gives the fuller picture. Only organizations linked to the space are counted.
• Period: the last 30, 90, 180, or 365 days, by date created.
• SLA: the SLA to report breaches for; for example, Time to resolution, or none.
• Organizations to show: the top 5, 10, 20, or 50, by number of requests.

For each organization it shows requests, open requests, SLA breaches (and their share of requests the SLA applied to), and average satisfaction, with how many ratings it is based on. A request with several organizations counts for each of them, and requests with no organization are counted separately. The SLA column is there only when an SLA is chosen in the settings, and the satisfaction column only when a request in the period was rated. The widget’s last line says when one is missing and why.

• The numbers are shown to the people who work on the space’s requests: its agents and admins. Dashboards are often shared more widely, so anyone else sees a note instead.
• On new dashboards, the filter bar at the top of the dashboard (space, creation date, and so on) does not change this widget. It always shows the space and period chosen in its own settings, which it names in its first line.
• Requests with an issue security level are not counted, so that nobody sees a total that includes something hidden from them.
• Refresh counts again straight away, at most once every 15 minutes. The first count of a large space can take a few minutes.

Known limits

Hidden emails

People with an Atlassian account can hide their email addresses. Their rows show name and account ID instead.

Last sign-in

Atlassian does not share when customers last signed in to the portal, so the date of each person’s most recent request is shown instead.

Request counts

A report counts the most recent 5,000 requests in a space. Requests with an issue security level are not counted, because the report is shown to every admin of the space and some of them may not be able to open those requests. If your space gives every request a level by default, the request columns say Not counted and the report explains why.

When the site is busy

The app limits how much one site can run at once and in an hour, and Atlassian limits how fast an app may read. When a limit is reached, the page says so and when it will carry on. A report waits its turn and is built by itself, so you do not need to keep the page open. Nothing is lost, and everything already built stays available.

Customers changing during a build

If customers are added or removed while a report is being built, the report says so. Everyone seen is included, so someone removed in those moments may still be listed. Rebuild when the changes are finished. This check is skipped for spaces with more than 2,000 customers on that list. The report says when it was skipped.

The Changes tab

The tab lists up to 5,000 changes at a time. Its totals and the export include every change.

Customer experiences

Customer experiences are found by checking one member of each organization, because Atlassian has no way for apps to list them. An experience that no organization can reach and that is not open to anyone will not appear. If Jira refuses the lookup for every member tried in an organization, the report says how many organizations could not be checked.

On a site with thousands of organizations, this can take a while.

If something goes wrong

At the foot of every page:

• Copy support details gives a few lines to paste into your message to support. They give the time, the app’s version, your site and its ID, the page, the space, which report is showing and what state it is in, and any message on the page. They name nobody: no customer, agent, or organization. With them, support can find what the app recorded about the problem immediately.
• Download diagnostics, on a space’s page, saves a small file describing that space to the app as numbers and settings. It gives how many customers and organizations, the sizes of the organizations, how many roles and groups give access, the state of the report, the schedule, and the last bulk change. It holds no names, email addresses, or account IDs, and nothing copied from a message. Attach it if support asks, or if the problem seems particular to your site.

Neither is sent anywhere by the app. You copy or download them and decide whether to send them.

Reset this space’s app data, at the foot of a space’s page, is for when the page keeps showing an error that rebuilding the report does not clear. It deletes what the app has stored for that one space, changes nothing in Jira, and shows exactly what will be deleted before you confirm. Download the diagnostics first to preserve those details before resetting.

Help

Write to support@kingstonfalls.com. The help page says what to include.