Custom Domains in Jira Service Management Help Center

[#1]

Update as of November 28, 2023: Custom domains for all paid Jira Service Management Help Center customers are now generally available. Since announcing the open beta for this feature in August, we’ve been working to introduce more flexibility in how you implement your branded URL. Currently, you’re prompted to select from a list of keywords for your first level subdomain, but that part of the domain will soon also be free text.

---

As an organization, you can implement your own branded URL for an Atlassian product by leveraging custom domains in the Jira Service Management Help Center. Custom domains make it easier for your customers to find and recognize your brand. With this new personalization, you can enjoy stronger recognition for your site - boosting credibility and search engine optimization, making it easier to stand out from your competitors. Operationally, your customers will have an even more seamless experience getting the help they need from the right places. Greater discoverability enables more self-provisioned help and less time required for your team to manage requests.

As part of our mission to ensure that security and flexibility are maintained for all Atlassian teams, we have opted for a solution that will best protect your organization. We know that security is non-negotiable and we want every team to operate confidently and with trust. As such, our implementation of custom domains utilizes two-level subdomains to protect your organization and users from malicious actors. Check out an example of what your JSM Help Center custom domain could look like below.

Custom Redirects

We understand that discoverability is critical for your customers to ensure they can access your help center as easily as possible. As such, we also plan on offering better support for custom redirects if you wish to not have a fixed first-level subdomain for their Help Center. A tech-savvy IT admin can currently create their own redirect through their DNS which will remain unchanged. We will also be equipping everyone with the right tools to also create their own redirect through simple step-by-step guides, and in-product experiences to track the redirects.

Custom redirects would allow you to specify a redirect domain that, when accessed, will redirect the customer to the custom domain. For example, a Jira and Confluence site with a tenant of acme.atlassian.net could have a configuration as follows:

• Custom Domain - get.help.acme.com

• Redirect Domain - help.acme.com

When customers access the link “help.acme.com” in their browser, the request will hit our redirect service, sending them to “get.help.acme.com” which will be displayed in the user's browser. For example, your public communication, website, or even internal material could have links to help.acme.com, which seamlessly redirect users to the Help Center which is located at get.help.acme.com. This is to ensure that your customers have an easy, memorable, seamless, and secure help center experience.

Custom domain for JSM help center has no impact on your service project’s inbound and outbound email addresses. If desired, project admins can add a custom email account for email requests, and send notifications from a custom domain email address.

Launch

Custom Domains for Jira Service Management Help Center is generally available today for all paid Jira Service Management Help Center customers and now includes 3rd party marketplace applications. Find out more about what is not available here. As we continue to develop, the current capabilities will be refined to provide a more comprehensive end-to-end experience.

Please feel free to share any feedback, questions, or insights. We are super excited to bring one of our most highly requested features to you. We’re releasing custom domains support on a per-product basis. Please visit the Atlassian Cloud Roadmap to follow along on custom domains availability for Jira Software, the agent experience in Jira Service Management, and Confluence.

Thanks in advance for your engagement.

Martin

[Ben Salvage]

Hi Martin, is the link to the list of "what is not available" the correct one? It doesn't appear to be. 
Thank you

[Martin Ben]

Hi @Ben Salvage  

Thank you for that, the link has been updated to the correct one now! 

[Joseph Chung Yin]

@Martin Ben -

How can we participate the beta process for our JSM premium now?

Best, Joseph C. Yin

Viasat Inc. 

[Joseph Chung Yin]

@Martin Ben -

Nevermind, I got my solution.  It was located in the following post - https://community.atlassian.com/t5/Enterprise-articles/Custom-Domains-in-Cloud-Development-Update/ba-p/2283483

Best, Joseph

[Shan McQuown]

Awesome!

[Matthew Challenger]

I don't love the 2nd level sub-domain + redirect domain approach, but I hopefully it makes some customers happy. Watching to see if this evolves over time. 

[Mark Benson]

The solution delivered was not what was asked for by the majority of customers on https://jira.atlassian.com/browse/CLOUD-6999 

We originally ran self hosted jira.domain.com so that's what our users know. We just have a simple redirect in place now to the current cloud tenancy company.atlassian.net

This solution doesn't solve anything natively for us and doing something like jira.domain.com > support.jira.domain.com is honestly just going to confuse users even further.

You can mark 1 customer down in your beta adoption list for "very much knows about it but never bothered starting the process"

[Olivier LORY]

Hi,

Is there any plan to have this capability available for Datacenter version ?

Thanks

[pam]

I am new to Atlassian's open beta process. How do I opt in to this feature?

[Haddon Fisher]

I'm super happy to see some movement on this given that CLOUD-6999 is indelibly carved into my brain. Got some questions:

• You say "We know that security is non-negotiable and we want every team to operate confidently and with trust. As such, our implementation of custom domains utilizes two-level subdomains to protect your organization and users from malicious actors." Can you talk a bit about why is this true? It's been a while since I did any real networking work, but aside from the (I had thought) thoroughly debunked 'security by obscurity' concept, I can't think of any reason this would be.
• You say "When customers access the link “help.acme.com” in their browser, the request will hit our redirect service, sending them to “get.help.acme.com” which will be displayed in the user's browser. For example, your public communication, website, or even internal material could have links to help.acme.com, which seamlessly redirect users to the Help Center which is located at get.help.acme.com. This is to ensure that your customers have an easy, memorable, seamless, and secure help center experience." Can you articulate why this is more 'easy, memorable, and seamless' then just having it live at "help.acme.com"? I get that it is better than "mycompany.atlassian.net/somesuperlongstringofnotveryhelpfulstuff", but again, not really understanding how it's better than what's been asked for.
• I see in the last status update of CLOUD-6999 that your approach is going to be to "release custom domains support on a per-product basis for Jira Software, the Agent Experience in Jira Service Management, and Confluence." When can we expect support for Jira Work Management?
• This is less critical, but for those who need a different URL structure, when will we be able to put this at "www.mycompany.com/support"?

[Matt Richards]

@Martin Ben - Three questions:

1. How do we opt in to the beta?

2. Do we still need to have a Standard, Premium, or Enterprise plan?

3. When will you support a first-level subdomain without a second-level? (I.E. support.mycompany.com)

[Chris Cook]

I'm a little confused by this. The previous "communications" say this multi-subdomain style is done to detect and mitigate MITM attacks, and you understand this wasn't what anyone wanted so we have the option of using a marginally shortened URL that redirects to a different/longer URL. 

This kinda feels like what a MITM attack would look like as it happens. We're avoiding MITM by being the MITM??

Or you're using the AWS API Gateway service and whomever set it up named the stages in this way so instead of just openly saying that, Atlassian calls them "keywords" as if it helps someone in some unspecified way?

"Solution in search of a problem" is what I'm thinking, folks.

From @Haddon Fisher 's comment "mycompany.atlassian.net/somesuperlongstringofnotveryhelpfulstuff"
I would actually prefer the implementation to be like that.

"mycompany.atlassian.net/ProjectA" or more ideally "support.mycompany.tld/ProjectA"

"support.mycompany.tld" would go directly to the main portal page to select the project from (in JSM)

"wiki.mycompany.tld" would go directly to the main confluence page, etc etc

A regular Application Load Balancer can easily handle domain and/or path based routing. This all could have been completed years ago. ¯\(°_o)/¯

[Ubimet support]

• Is there any update on that for jira software & confluence cloud ?
• This is an very important topic for many companies as well, we need to redirect (CNAME) all links from our server instance to cloud otherwise we will have many requests/issues that jira/confluence is "not working"