Use email domains to restrict external customer sign-up for your Jira Service Management

[#1]

This feature is progressively rolling out starting Tuesday 24 May 2022. If you are a Premium customer using Release Tracks then it will be available in your next release window.

We are excited to announce the release of Domain based allow lists for External Customers. This feature is a follow-up to the recently release Domain base sign-up for Internal Customers.

Not wanting to sound like a broken record, but… 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.

This feature focuses on the latter, but provides an important control for disabling External Customers all together, which is a must for organisations using a strict Internal Strategy.

How it works

You will notice a few changes to the Customer Access page. This is where you can control which email domain will be able to sign up to your help centre.

These controls only apply to new customers signing up to your help centre. Existing customers will not be impacted.

Enabling/Disabling external customer accounts

Under the External heading you now have the option Allow portal-only accounts to be created for new customers accessing the help center. This determines if External Customer Accounts (also referred to as Portal-only accounts) are able to be created for your JSM site. Unchecking this field will prevent them from being created via portal sign-up, email, or by Agents in the Customers page.

If you are using an Internal Strategy, it is recommended you uncheck this field.

Adding an allow list for External Customer accounts

The next checkbox in the External Customer section Only allow account creation for customers with specific email domains let’s you define the email domains which will be allow to create new accounts via portal sign-up, email, or by Agents in the Customers page.

Once enabled you can add domains in the Enter a domain field.

Hybrid Customer Management Strategy

If you are working with Internal and External Customer Accounts and use approved domains as well as an allow list, then the former will take precedence. This means we will always create an Internal Customer account first whenever possible.

Customer experience

If a customer tries to sign-up to your Help Centre using an email domain not on the allow list they will be presented the following error message.

Emails sent to a portal email address from an unknown customer will be ignored if their email domain is not on the allow list.

[Antonio Rodriguez]

I don't understand the difference from what was enabled a few months ago (approved domains) 🤔

[Ingo Wenke]

I'm a little bit lost.

This sound like a system wide-setup.

We have a couple of Service Management Projects.

Category A) only internal Customers allowed (verified, multiple domains)

Onboarding as of today:

Add a new internal customer by adding an Atlassian account with no licenses

Add new user to specific group, which has customer portal role access to this specific project.

Add mail address as customer to the project, inside the correct organization.

Category B) External, known customers for a restricted Support Portal

Onboarding as of today:

Add a new customer by Agent to trigger the invitation

Hope, that those customers have not tried to send mails before they have been added to the portal as customer.

Do a regular sanity check of the mail log file to find out which Mails have been blocked

Category C) External customers, open to the world

Onboarding as of today:

Allow self-registration and accept every mail (if not on the blacklist).

How does those new features help me to streamline the onboarding in category A, or B?

[kt.bel]

If we could customize per project, this would be a huge help.

[Ingo Wenke]

unfortunately, this is a system wide setup, not a setup per project. (was clarified by @Benjamin Paton )

So, in-mixed mode no progress.

[Benjamin Paton]

There is one more piece of the puzzle coming later this year, which uses domains to automatically add customers to organisation groups. It sounds like this is the part you are looking for, for controlling access to individual projects.

The major capability this feature brings, is the ability to restrict your whole help centre to a list of know domains, or prevent the creation of external customers altogether.

[Thomas Griem]

@Benjamin Paton is there any article or ticket-ID I can follow to see, when this feature will be available? unfortunately without the implementation to organization group, this feature is useless in our company.

[kt.bel]

@Benjamin Paton

For the domains, please consider the use case where a company may have multiple atlassian instances ( xxxx.atlassian.net and yyyy.atlassian.net), but all company users have the same domain email address.   Also, users may need access to both xxxx.atlassian.net and yyyy.atlassian.net.

[Michael Wood]

Having followed the steps above users are still able to sign up with a non-approved domain. Does this take time to take effect?

[Benjamin Paton]

@Thomas Griem https://jira.atlassian.com/browse/JSDCLOUD-4519 this is the best place to watch.

@Michael Wood if you are able to add the domains then it should take effect immediately. If it is still not working I suggest raising a support request.

[Mo Bhimji]

@Benjamin Paton Are we able to bulk load permitted domains? I mean, I don't want to sit there and "manually" have to enter dozens of domains when I could easily upload them via CSV.

[Nikolas Falco]

> The major capability this feature brings, is the ability to restrict your whole help centre to a list of know domains, or prevent the creation of external customers altogether.

What is not clear is why if we have a JSM project configured with customers added by agents or admins only, the customer email they use in the creation is subject to something that in the site configuration page is clearly bound to the portal access option (in fact the option is disabled when the portal only option is disabled).

JSM projects handled by email collector and customers created by agents fights with JSM projects relates to a company with a specific contract (portal access restricted to a specific email domain).
So domain configurations blocks customer creation by agents. If no domain configurated for portal access, anyone can register to the company specific assistance portal.

[Ruby Domanico]

We've set up multiple projects with multiple portals. One of the portals is only used internally, whereas others are for external clients. If we allow external domains, external users will be able to see the portal used internally, which contains sensitive information, and this is not ideal.

We could hide all the portal from the main Help Centre page, and provide our external clients with the link to the portal they need, but this won't prevent them seeing the other portals if they (somehow) have the link to them (or change the link themselves).

Is there a workaround for this?

Adding users to groups would not work, we ideally need certain domains to only access certain portals.

[Benjamin Paton]

@Ruby Domanico have you seen this article https://community.atlassian.com/t5/Jira-Service-Management-articles/Choosing-the-right-approach-to-Customer-Management-in-Jira/ba-p/1970761?

Sounds like you re a hybrid use case. If you restrict internal projects by groups, then your external customers wont be able to see them.

[Adam McDowell]

When is Atlassian planning on splitting email permissions from customer permissions. ?
We desperately need the ability to configure these settings at a project level, instead of global.

There are hundreds, if not thousands of customers who need different settings on a project by project basis.
Enforcing this setting at a global setting introduces unnecessary risk and exposure to organisations who use JIRA.
Today we received a ticket from the general public, which they raised via the company portal, and the ticket contained a sexually suggestive image.

This needs to be resolved !

[Rob Di Toro]

We've turned this feature on for our domain in order to grant internal users access to our Internal IT JSM project – but we primarily use JSM for external support requests.

It seems to behave okay if the customer creates a request through the portal, but if an agent adds an external customer through the (external) service project's Customer tab ({domain}.atlassian.net/jira/servicedesk/projects/SR/customers),

they start appearing in our users list under the site management.  And, don't get created as a portal-only customer.

The product access permissions for any domain were set to:

(with users on our own domain getting different product roles).

Trying to work backwards to remove this and set things back to normal, but will likely have to raise a support request very soon.  Just wanted to give everyone else the heads up.

[Jordan Wilkinson]

Is there a way to manage the list of domains via API?

[Arnout Angenent]

Does the external 'allow account creation' option also allow for using wildcards? It seems it doesn't, but might benefit from such an option.

As an example:

*.atlassian.com

would allow jira.atlassian.com, confluence.atlassion.com, etc.