nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

A dedicated product access role for internal customers in Jira Service Management

Ash Young

We are taking another step forward in helping you manage your customers in JSM. We have created a dedicated product access role for Internal Customers.

To recap, there are two types of customers in JSM.

Internal Customers – Typically employees, or those inside your business.
External Customers – People outside your business, your customers or prospective customers.

If you have not seen our best practice article, we recommend Internal Customers are given Atlassian Accounts and not Portal-only Customer Accounts, which should be reserved for External Customers. If you’re unfamiliar with the difference between Atlassian Accounts vs Portal-only Accounts, we recommend checking which account type is best for you first.

What we've solved

Previously each JSM Help Center was accessible by any Atlassian Account within your organization. Unfortunately, this did not provide Administrators enough flexibility to control who should and shouldn’t be customers for any given JSM Help Center.

With this change, you will be able to select the appropriate product access role for new and existing users, allowing them to be either a “User (Agent)”, “Customer”, or “None”.

Administrators will able to explicitly set granular permissions to control access.

HAA 1.png

Frequently Asked Questions

Which roles will have access to a Help Center?

To access a JSM Help Center with an Atlassian Account a user must have either the:

“User (Agent)” product access role, or
“Customer” product access role

“None” will no longer be able to access the Help Center.

What will I need to change for existing users?

Existing users will continue to have the same JSM experience they have today. These changes are behind the scenes and simply regroup existing users into the “Customer” product access role.

Our aim is to preserve the current experience your users have today.

We will be migrating existing users in the following ways:

All current Atlassian Account users in “User (Agent)” will remain the same
All current Atlassian Account users in “None” will migrate to the new “Customer” product access role

What will I need to change for new users?

If you rely on Atlassian Access to SCIM sync users into "groups", you will need to ensure each "group" is configured to provision the new "Customer" role. This will ensure all new users have access to your JSM Help Center.

You can find instructions for configuring product access via "groups" here

When and why should I use "Customer" product access?

Assigning the "Customer" product access role represents an Administrator's decision to grant a user access to a specific JSM Help Center.

Administrators are able to assign "Customer" product access per JSM site. As each site has its own Help Center - access can be granularly managed.

When and why should I use "None" product access?

Assigning "None" represents an Administrator's decision to restrict a user's access to a specific JSM Help Center.

Administrators are able to assign "None" product access per JSM site. This action will restrict the user from accessing all JSM features for the site.

Setting the correct product access for new users

For new users, you can define which role they should get based on their email domain.

"User (Agent)" is a billable user that uses JSM to provide service
"Customer" is a non-billable user that raises requests via a JSM Help Center
"None" is an employee that does not need access a JSM site

We’ve written up a guide on how to control which users get access to which products in case you need a reminder.

Where Admin approval is required to create accounts - users can continue to sign up, but won’t be assigned a role until an Admin has reviewed their request.

HAA 2.png

For Help Centers using Approved Domains to create Internal Customers, the new “Customer” role will be assigned to your customers rather than inheriting access settings from other products and making inferences for Jira Service Management.

Will these changes increase the amount I pay for JSM?

The new "Customer" product access role is non-billable. This change does not increase the cost JSM

Atlassian Accounts assigned the "Customer" product access will not incur a cost.

Customers are unlicensed users who send requests to your service project through the portal, email, or widget. For example, employees who raise requests to an internal service desk will have access to the portal with no product access to the project are usually internal customers.

You can refer to this page for more information about the different roles in JSM.

You can refer to this section for more information about licensed vs unlicensed Atlassian Accounts.

If you have any questions or would like to provide feedback, please leave a comment below.

Update on timelines:

New JSM sites created from April 2023 will have the "Customer" role
Existing JSM sites will gradually migrate in the subsequent months. There will be no disruption to how your existing customers/users use your Help Center

Comments

Murthy A M

Hello,

When can we expect these changes to roll out and available to sites? Is there an EAP that we can sign-up.

Regards,

Murthy

Ash Young

Hi @Murthy A M

I've updated the article with our timelines for new sites and existing sites.

There won't be an EAP for these changes - you'll be migrated eventually in the coming months

New JSM sites created from April 2023 will have the "Customer" role

Existing JSM sites will gradually migrate in the subsequent months. There will be no disruption to how your customer use your help center

Kristján Geir Mathiesen

Hi @Ash Young and thanks for this article. Since this change is not live yet, could you maybe provide actual pictures of how this looks like (not just the mock up)?
That way we can better understand the change and hopefully internalize it.

Also, what does "subsequent months" mean - next couple of months? After 6 months?
Just so we can anticipate and plan better.

Thank you again, KGM

Jamie Sawyer (Adaptavist)

Don't suppose this is a lead-in to allowing Organizations to contain Groups for internal customers - would be useful to give a "Share with <your team or department>" that's been defined in our group management system, which derives from our HR system...

Milad Sayad

Hi @Ash Young,

Great work, and thanks for the article. Eagerly waiting to see more details.

If I understand this correctly, this change means that we are going to have Atlassian user accounts with the role of the customer as well as Portal customer accounts. In this way, the same name (i.e, customer) is used for two different attributes: one refers to the role of an account, whereas the other refers to an account type which could be confusing.

The situation would be something like this (one internal customer and one external customer):

Email Account type Role
interal.cusotmer@acme.org Atlassian Customer
external.cusotmer@gmail.com Customer ??????

I remember the first time that I needed to grasp the concept that an Atlassian user with site-only access is also a customer (which was not clear), and I kept reminded of that every time I needed to explain it to others. A contributing factor (apart from naming convention) is that there is not a consolidated list that captures all customer accounts in one place, regardless of whether they are Atlassian users or portal customers. All of these make your work difficult because you need to keep explaining these using community articles or through support tickets raised to Atlassian.

I hope the new UI and design help to intuitively relay that there are two ways to have a customer.

Regards,

Milad

Ash Young

Hi @Milad Sayad

I can appreciate that there is mental model with a learning curve for our Altassian/JSM Admins.

I've written up a little more clarification about account types for you.

Different types of access to JSM

I'll elaborate on your example:

Example Email	Account Type	Future Possible Roles
Internal.customer@acme.org	Atlassian Account	None Customer User (agent)
external.customer@gmail.com	Portal-only Account

Account access

Account Type	JSM Access
Atlassian Account - None	Is an employee - does not require access to JSM Cannot access Help Center Cannot access Agent View
Atlassian Account - Customer	Is an employee - requires access to raise tickets Can access Help Center Cannot access Agent View
Atlassian Account - User (agent)	Is an employee - requires access to work on tickets Can access Help Center Can access Agent View
Portal-only Account	Is not an employee - requires access to raise tickets Can access Help Center Cannot access Agent View

Migrating from Portal-only Accounts to Atlassian Accounts

If you find that a user has been provisioned a Portal-only Customer Account. Admins are able to follow these instructions to migrate the account to an Atlassian Account. After migrating you will be able to change a user's role type to either: "None", "Customer" or "User (agent)".

Thanks,

Ash

Maximilian Brand_ne8cer

Finally! We have been missing this feature for so long!

Aaron Kraft_n6qd0g

Are you going to charge us for internal customer because they now have atlassian accounts and not portal only accounts? This will break everything we have just set up in the last couple of months.

Chris Purser_zpblti

Hi @Ash Young and thanks for the update.

Do you see this getting us closer to (or does it include) being able to have customer-accessible Confluence spaces that do not require Atlassian seats nor require spaces be simply public?

The ability for us to lock out non customers (general public) from our (non-employee) knowledge bases, for example.

This too has been missing forever, and would be great to hear there is progress on that front.

Cheers.

Darren Pegg

They are not Agents, I would assume pricing wouldn't be affected.. I hope.. Data Center would end up cheaper 😆

Charles Gage

What is the pricing structure going to be after this update is put into effect?

We are considering creating an internal ticketing system for usual administrative requests. JSM is one of the tools we are looking at. We already are using JSM in the typical Agent/External-Customer mode and it works great. If we create another JSM project, accessible by our internal non-Agent Customers, will a license fee be incurred?

Our internal Customers, like our external Customers, will not need Agent-level access.

And, another question: Suppose we have Developer who has a regular Jira license for the Jira Software product, but not for the JSM product. His license cost will continue for his primary Jira Software product. He already exists under Managed Accounts. How can/should he obtain an internal-Customer role for the JSM instance? Will there be an additional cost for him? Can he be a Developer within Jira Software and an internal-Customer within JSM?

Thanks.

Betsy Edson

Like a few others above, I am also interested to find out if creating internal customer accounts will alter the seat count. We like having the ability for our business users to have portal only accounts that we do not need to pay for. My assumption would be that Atlassian Accounts that only have JSM access as "Customer" will not go towards our seat count/invoice. Is this a correct understanding?

gstoesz

For those asking about the Atlassian accounts if it costs. We already have this setup so that we can use Single Sign On. We only pay for the active licenses assigned to these accounts. Think of it like when you have an employee that leaves the company, you likely just revoke access, but they continue to have an Atlassian ID/ profile in your system. I hope this helps.

My question on this new feature is, will the new internal "customer" profile make it easier to assign users to a profile to allow for searching in the portal? Right now it's BRUTAL to add internal customers to the portal organizations.

April Villone

Do the new internal customer roles cost anything or are we still only charged for agent roles? Are you saying that this new change will allow us to hide certain projects from the help desk portal for external customer roles or any customer role? Because we haven't opened the portal to external staff for just the reason that we can't hide our internal infrastructure project from the portal. If this doesn't affect cost and solves that issue this will be a great improvement.

Luca Perri_ve4q2q

Hi @Ash Young, just want to confirm if external customers who are provided the "None" Role can still create tickets in JSM via email channels?

We are hoping this is the case, as we want them to be able to create tickets via email, but not be able to login to our JSM Help Center and submit requests using our forms.

Austin Songer_nd98jt

Why not just rename "Atlassian Account - Customer" to "Atlassian Account - Employee" lol.

It is silly keeping the "customer" name, it will continue to confused people.

Cristian Zuccalá_vjrtrz

Hi! JSM Enterprise..will you also have this update?

František Špaček _MoroSystems_

@Austin Songerbecause even internal customer is still a customer for the team. Internal customer does not always mean employee. It might be contractor or external vendor who you are cooperating with. Both will have ecosystem account (due to access to Confluence for example) but both might be just customers for your internal helpdesk.

Also Atlassian is otherwise making steps to not actually bill people who does not really access the tools from the inside directly. E.g. thats why JSM customers are not billed towards Atlassian Access eventho they can be provisioned and can use SSO and other features. Same goes with Confluence guests add just few months ago. You had to bill for those past 20 years but you can use those for free now.

Ash Young

Hi @Austin Songer @Betsy Edson @Charles Gage @Darren Pegg @April Villone @Aaron Kraft

I wanted to provide you a timely clarification as billing appears to be a top question and concern with these changes.

Will these changes increase the amount I pay for JSM?

The new "Customer" role is unlicensed. These changes do not increase the cost of JSM.

Atlassian Accounts assigned the "Customer" role do not incur a cost.

Customers are unlicensed users who send requests to your service project through the portal, email, or widget. For example, employees who raise requests to an internal service desk will have access to the portal with no product access to the project are usually internal customers.

You can refer to this page for more information about the different roles in JSM.

You can refer to this section for more information about licensed vs unlicensed Atlassian Accounts.

Andrey Kiyanovsky_l161i8

Could you please tell how this change will help us? Except having more monkey job to configure additional roles per every user (!) in addition to existing project roles/permissions. This phrase "Previously, each JSM Help Center was accessible by any Atlassian Account within your organization." is completely incorrect, I was perfectly fine managing access to any JSM by project roles/permissions.

1. What is the real reason for this change? I can't see anything that I couldn't have done earlier, or what simplifies our life or brings additional value. All I see - more complex configuring and debugging.

2. How existing project roles of Agents and Customer befriend with the new account role? What if they contradict each other?

3. Now I can configure the same internal account to be an agent in one JSM project and a customer in another JSM project. What will change?

4. When are you going to fix the bug that allows two active accounts (portal and Atlassian) with the same email to co-exist and break login?

5. When you say "All current Atlassian Account users in the "Agent"/"None" role" - what do you mean? Where is this role currently configured?

Thank you.

Austin Songer_nd98jt

I love how my 2nd comment above was deleted by Atlassian personnel where I mention how this new role could be a way of charging us for this new role later.

And this is just a way of slowly easing us into this new role before they add a price for this new role.

Austin Songer_nd98jt

I love how my 2nd comment above was deleted by Atlassian personnel where I mention how this new role could be a way of charging us for this new role later.

And this is just a way of slowly easing us into this new role before they add a price for this new role.

I keep trying to post but it seems like Atlassian is literally preventing me from posting.

unknown

this is only for "cloud" edition?

@Ash Young

František Špaček _MoroSystems_

@Ash Young I dont share the problematic view of the people here and I am rather thrilled with this change. My only questions are these:

Will it possible to assign "Customer" role for ecosystem accounts through groups? E.g. if accounts are provisioned from AAD or other tools, will there be a possibility to precisely set with a group, who is a portal customer and who is not?
Will it be possible to set default state for the instance? Instances that does not have any external account management might want to select whether each new account will be a Customer or not. This might come handy as a security "check" - each account created without license will be of type "None" by default, but can easily be (possibly also with bulk change) changed to "Customer" and vice-versa. While some other companies will want all newly created account to gain "Customer" role immediatelly.

Thanks!

Humberto Gomes

@Andrey Kiyanovskiy

Can you share how to do it:

"3. Now I can configure the same internal account to be an agent in one JSM project and a customer in another JSM project..."

Thanks.

Nic Brough -Adaptavist-

@Austin Songer - two accounts is a bit of a red-flag to the anti-spam bots, and I think they hit you with it. I've pulled one of your posts out of spam because it's simply not.

I also wanted to reply to your first post. I'm not saying I've got a better name for customer accounts, I really don't, but I do think we need a way to have different names for the two types of customer, Agents and developers. We're already charged for "internal" customers (as they're developers or agents already), I would not expect Atlassian to impose another charge band on them.

Grant Adkins

We currently have all of our staff in the "Service Desk Team" role so that they can navigate to our service desk project: https://[instance].atlassian.net/projects/[service-desk-project-key] in order to add internal comments. Most of our staff don't have the Service Management product toggled on, only agents are licensed that way.

With this change, will our unlicensed staff members still be able to view that project and view tickets via https://[instance].atlassian.net/browse/[issue-key] rather than being forced to view tickets via the customer portal https://[instance].atlassian.net/servicedesk/customer/portal/[portal-id]/[issue-key]? That's pretty important for them being able to add internal comments and to see additional fields that are hidden in the customer portal.

As an aside, we currently also share some filters with an external consultant who has a Jira account in our instance but has no permissions to the service desk other than via the customer portal. That filter's results show links to service desk issues but the URL is not changed to the /servicedesk/customer/portal... URL for them based on their permissions but stays as /browse/[issue-key] so the link is useless for them. Can that be fixed (checking permissions and outputting the correct URL based on the viewers permissions)?

Phillip C

What about segregated customer permissions for each JSM portal? I don't want portal users to browser other JSM portals.

I use an internal JSM portal for staff and an external JSM in another project for external users to raise requests. I don't want these random external users being able to view the internal JSM portal. If i butcher the project permissions for the external JSM, it disables email requests from vendor/supplier/any 3rd party unknown accounts for my internal JSM project.

Previous question answered explaining gap of issue: Solved: how do i restrict customers access to specific pro... (atlassian.com)

Dave_goio7w

@gstoesz Re Revoking Users

We revoke the User when they leave our company so we stay with in the 10 licenses we have, (small part of our company using this instance of JSM). I discovered just last week that when I revoked my old manager from JSM, last October, that they were still in a Group. - it still doesn't consume a license, but I would have thought that they would have been removed from everything to do with our JSM instance.

Dave_goio7w

We currently have

10 x users who consume a license - it bounces around 8-10 and 45-ish Customers who are in groups

Can you please confirm that they will remain in the current groups that restricts what they can see with these changes.

What do I need to do?
Can I do nothing?
Do you have a step by step guide of what I need to do with screen shots. ( I find JSM admin very difficult to find where things are located)

I need to advise my management of these changes and what 'Dollar Cost' it will be to us as company.

I currently have a ticket in for Tagging 'teams' in a comment with in JSM for example tagging a team called @Cup of Coffee , where I can tag unknown random teams made up by others not in my instance and who I haven't added to my Organization.
I've been told that these randoms can not see my data as it is now (I can't prove that they can't or can see my data) Atlassian advised that I'd need to grant permissions to the project etc etc for them to see my data. Has this been tested with these changes?

Cheers in advance

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

account

user

customer

user-management

role

atlassian-account

halp

jira-service-management-cloud

jira-service-management