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

[#1]

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.

---

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.

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

[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 S_]

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 S_ 

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

[mb]

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

[Aaron Kraft]

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]

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]

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]

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á]

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]

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]

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]

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.

[Deleted user]

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:

1. 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?
2. 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.