A new easier way to get employees into your Jira Service Management Help Centre

[#1]

Starting this week (16 March 2022) we are rolling out an exciting new feature that will help welcome Internal Customers in your help centre.

Just to recap for those at the back 😜, there are two types of customers in Jira Service Management (JSM)

• Internal Customers - Typically employees of your company. Where a service is openly provided by one or more teams to the members of your company.

• External Customers - Users who are outside of your company. Often a subset of the general public. Where your company provides a service to external individuals/groups maybe known as clients or customers.

If you have not yet seen the Customer Management best practise article you can find it here. For Internal Customers you should be using Atlassian Accounts. There are a lot of advantages like business account sign-on (e.g. Google, Microsoft, Slack etc), password policies, group memberships, collaboration across other products; which is why we promote it as the best practise… Seriously, check out the best practise article it will be worth your time.

Until today, any customer who emails or signed up via your help centre was given an External Customer Account (also referred to as a portal-only customer account).

Fortunately now you will be able to selectively provide the right account type to would be Internal Customers based on their email domain matching a corporate domain you have specified.

Internal Customers using Atlassian Accounts are FREE!

It is a common misconception that using Atlassian Accounts for Customers will incur costs. This is absolutely not the case. Cost is only incurred if a user is granted a product license (e.g. Jira / Confluence), with no product licenses a user can still be a JSM Customers and not incur any costs (this includes Atlassian Access too which only bills for licensed users).

How it works

This feature utilises an existing popular feature for welcoming licensed product users into your Jira / Confluence sites.

Preparation

Using access settings a Site Admin can identify domains that can added to the approved list. These domains are used to allow employees to self sign-up to Atlassian Product, and now your JSM Help Centre.

Atlassian Admin > Site access	Atlassian Admin > Products > User access settings
Current experience	New experience

Default product access

It is important consider the default product access for your site. Any new user, including the Internal Customer Accounts created with this feature will be provided your default product access. Depending on your needs you can set set no default products which will ensure your Internal Customer Accounts are free. Learn more.

Enabling in JSM

Simply navigate to Settings (Cog) > Product > Customer access. You will notice a new option under Internal. Check this box to use approved domains to grant internal access to the help centre with Atlassian accounts.

Now any user who emails or signs-up to your help centre who provides an email address that matches the email domains on your approved list, will be provided an Internal Customer Account (also referred to as an Atlassian Account). Given that these users are invited into your organisations, for your security we will ask them to verify their email address before they can start interacting (if their engagement is via email, we will hold their request until they have verified).

We want to hear from you!

If you jump onto this feature, think it might be for you, or just want more information. We would love to hear from you. We have started a dedicated Community Group for Customer Management in Jira Service Management. Come join us if you would like to join the conversation.

[Matthias Ortner]

Yeah, this is great. We use JSM exactly as described for not only IT issues, but for all other departments (finance, logistics, HR,....)
Highly recommended :-)

[Antonio Rodriguez]

Nice! finally!

You should note that a (internal) user cannot sign up from the /servicedesk URL. It has to be from the root domain.atlassian.net > sign up > verify email > "your domain has been approved. Join company" > User goes into Service Desk Portal.

A Sign Up button in the Service Desk login page is necessary, otherwise the user experience is basically broken. But it's a great first step!

Edit: turns out this page exists: https://yourcompany.atlassian.net/servicedesk/customer/user/signup

However, any email (approvd domain or not) shows: Signup is not currently available

So I guess the feature is in the works? :) Or is that for when "Allow customers to create accounts" is checked (which it must not be in an internal help desk)? This should allow only approved domains then.

[Oliver H]

Hi @Antonio Rodriguez

You are correct.  A Service Desk Sign Up button is available if the site's Customer Access settings "Allow customers to create accounts".

The recent changes to the Customer Access settings page (shown in the last screenshot in this blog post, under Enabling in JSM) hint at further changes coming to allow finer control over external customers, including disabling them altogether, which I believe will complete your use case.  :)

You can follow https://jira.atlassian.com/browse/JSDCLOUD-868 for progress on these further changes.

Thanks for your feedback.

Oliver

[Adrian]

When can we expect to see the new experience?

I can't see the User Access Settings menu under Atlassian Admin > Products

[Oliver H]

Hi @Adrian 

Can you see Site Access under Atlassian Admin > Products?

If so, you are still on the current experience (the left screenshot in this article) and you don't yet have the new experience (the right screenshot in this article).

The functionality, as far as the concepts explained in this article, is the same and you can configure and enable Internal Customer Accounts as described with either experience.

Regards,

Oliver

[Adrian]

Hi @Oliver H 

If I go to Atlassian Admin > Products > SITES AND PRODUCTS <my organisation> > Site Settings > Site Access I get the left screenshot.

How do I get the new experience?

I have followed the article and turned on the "Use approved domains" but still have an issue where internal staff members can't lodge an internal service request if I have "Customers added by agents and admins" configured in the service project.

[Oliver H]

Hi @Adrian 

The new experience is rolling out progressively, I'm sorry it's not my team so I don't know the exact timelines.

If you have "Allow customers to create accounts" selected under "Portal access" (in the Customer Access settings page), then internal customers will be able to sign up via your portal.

But if your service project is set to "Customers added by agents and admins" then those accounts will still need to be manually given access to your project or an organisation that has access to the project.

You can follow https://jira.atlassian.com/browse/JSDCLOUD-4519 for updates on future work we're planning to make that step easier.

Hope that helps. 

Regards,

Oliver

[Adrian]

Hi @Oliver H 

I think I may have misunderstood the feature.

I am trying to achieve the following.

I have two service projects. One for customers and one for internal staff.

I need customers to be able to sign up via the web or by sending an email.

I need internal staff to be able to do the same.

The problem is that both service desks portals are visible to the customer and they accidentally lodge tickets into the internal service project.

I was hoping for a way to restrict access/sign up into the internal service project via domain.

I thought "Approved Domains" would be a way to achieve this.

Any ideas on how I can achieve this?

[Oliver H]

Hi @Adrian ,

You haven't misunderstood, but "Approved Domains" is only one piece of the puzzle you need unfortunately.

Allowing sign up via the web or by sending an e-mail, and ensuring that those who sign up get the appropriate account type is what you can now do with "Approved Domains".

The next piece for your use case is assigning the appropriate project permissions to new users.  Currently this is manual (i.e. when a user is created, an agent or admin needs to add them to an Customer Organisation that has permissions to the right projects) but we have features planned that will make it easier to assign new users on creation.  You can follow https://jira.atlassian.com/browse/JSDCLOUD-4519 for updates.

Once new users can be automatically added to Customer Organisations, you should be able to restrict access to your internal service project to just the Customer Organisations containing your internal users.

Regards,

Oliver

[Adrian]

Hi @Oliver H 

Thanks for the clarification.

That's what I thought the "New Experience" did. It looked like in the screenshot you could apply a domain to a Project. But I guess it is applying a domain to a Product.

I look forward to https://jira.atlassian.com/browse/JSDCLOUD-4519 being implemented to resolve my issue.

Until then is there any notification you can set up so that when an email request has "Failed" because

Signup is not currently available or You don't have permission to access this service project.

Then my team can be notified and add the user.

[Oliver H]

No problem @Adrian , happy to help.

A project admin can view the e-mail logs to see e-mails that weren't processed for any reason.  See https://support.atlassian.com/jira-service-management-cloud/docs/about-email-logs-in-jira-service-management/

[Adrian]

Hi @Oliver H 

It seems that you have to manually monitor the email logs.

Is there any way to get a proactive notification so I don't need someone checking them every day?

[Oliver H]

Nothing as part of the product @Adrian.

[Ingo Wenke]

Feature seems to fill the current gap while using JSM for internal und external customers. Still waiting for the feature availability.

[Sebastián Gonzalez]

Nosotros tenemos un problemas, nos aparecen nuestros clientes con 2 cuentas utilizando un mismo correo, (gmail), que podremos hacer? 

[Lars Stuber]

@Oliver H@Benjamin Paton , I have one question. We want to use JSM as our internal service desk. We have our company domain approved. But users, who want to access a JSM Portal the very first time, will enter their email address but then are asked for a password. For users which were already using Jira or Confluence, for them they will be redirected to a single-sign button. 

Our first-time users experience a very bad authentication flow, because they first need to go to our xyz.atlassian.net domain, generate an account via the single sign on and then move back to the JSM Portal.

Is it not possible to directly initiate the SSO Flow from the email input in the JSM Portal? This would increase the user experience sooo much in internal company processes.

[Yev]

@Lars StuberThat is the same gripe I have with the product. The way I get it working (without needing any user interaction) is first go to the customers section in your JSM settings, click add customers and enter their email (I personally turned off the email notification to customers, but that's up to you).

Then go to the administration section of Jira, Manage users, and you'll see Jira Service Management (aka Portal-Only users). From there you can click the ... on the right-hand side and "migrate to atlassian account"

Now the SSO will work as expected, and although the customer experience is good with the above method, the management steps needed for the admin is not a good experience.

[Lars Stuber]

@Yev thanks for your quick comment. However this only works if I know the emails. Our company is quite big and imagine if a new user joins the company and the next day want to use the Jira service management (because there he might be able to order something), and then he will face this issue. 

Since I do not know who is joining the company or who will use the JSM tomorrow, I cannot predict all potential internal customers. And user provisioning unfortunately does not work for us. 

All I want is the same behavior as we have for Jira and Confluence. User can simply sign in via SSO. No admin required, no additional user steps required.

[k_lamontagne]

It's not a misconception that internal Customer accounts can incur costs. With "Atlassian Access", if they use free Trello, they become billable accounts.

[Benjamin Paton]

Hey all, 

Thanks for all the feedback here it is great. I have been working to pull together our dedicated Community Group for discussing all things Customer Management in JSM.

We have a thread there seeking further feedback on this feature, and we will be exploring topics more broadly from the recent Best Practise / Vision article. 

You can join the conversation here - https://community.atlassian.com/t5/Customer-Management-for-Jira/gh-p/customer-management-jsm

Cheers, 

Ben.

[Benjamin Paton]

@Lars Stuber by the sounds of it, this feature will help you achieve what you need. When those from the approved domain visit the portal they will have an Atlassian Account created for them, which will push them down the same flow as you mention for users with existing accounts. This also works via email. Both scenarios require the user to verify their email address before proceeding.

@Yev you too should be able to use this feature to address your workaround

Atlassian Access to synchronise your customer accounts is also an option for you both and might be more like what you need if your organisation is large

@k_lamontagne you are right, there are a lot of gotchas here, but the point I am trying to call out is that it is possible to have Internal Customer accounts that are not billed. We are working to make this better in the near future and will have a dedicated role for Internal Customers to better avoid confusion.

[Lars Stuber]

@Benjamin Paton thanks a lot for your reply. However your described flow is not available for JSM (while it is for Jira & Confluence). We did heavy testing on this. Also the Support confirmed that this behavior is "intended". Our current workaround is, that I wrote a script that will invite bulk people without any product access, so that they are in our tenant. Afterwards they can use the normal Single-Sign-On flow as described by you. If they do not have an account however, they face the issue I have described (they need to enter a password, which they do not have). Really unsatisfying in an enterprise context, where seamless user experience is required.

You can easily reproduce it:

1. Have a tenant with an approved domain & SAML (e.g. Azure AD/Okta)
2. Let a user, which does not have an Atlassian Account, but with an approved email domain, try to sign into a portal address (e.g. https://XYZ.atlassian.net/servicedesk/customer/portals) 

The result will be that the email will not be recognized as Single-Sign-On and will ask the user for password, which (as we are using SAML) he does not have.

[Adam England]

@Lars Stuber I'm seeing exactly the same thing.  Approved domains, creates an external customer account with the portal.

@Benjamin Paton can you advise please, we're just in the process of configuring our "internal customers" and your advice doesn't seem to correlate?  Bearing in mind our internal customers do not have any sort of Atlassian product and just need access to JSM and confluence knowledge base articles.

[Benjamin Paton]

@Lars Stuber @Adam England are your instances using Release Tracks? Its possible that this feature was not deployed for you at the time of writing. It should be available now. You will know by visiting the Jira Admin > Customer access page. If you have the option to check approved domains for Internal Customers then it is available. If you are still having issues I would like to chat with you. Let me know and I can reach out directly.

[Lars Stuber]

@Benjamin Paton , thanks for your response again! This setting is already active since a couple of weeks:  I would appreciate if you can reach out to me and I can showcase you what I mean with my problem/issue.