Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Custom Domains in Cloud - Development Update

 Update May 15

Please see our latest update regarding the security consideration and the URL redirect feature. 

 Update Apr 4

To reiterate an earlier comment, thank you all for your engagement and feedback. 

We know how important it is for you to have a clear and detailed understanding of the technical reasons behind the constraints and how they enhance your security experience with custom domains. We will come back with a separate update addressing this soon, and will provide more details on the optional URL redirect feature. 

Hi everyone,

My name is Luke Liu and I am the Product Manager responsible for bringing support for custom domains to Atlassian cloud products.

To summarize, custom domains is the ability for an organization to select and implement their own, branded URL for an Atlassian product. Many of you have shown interest in this feature and we are very excited to share the initial designs and visually show-and-tell where we are in the journey!

Our progress:

Here is a sneak peek of how an Atlassian org admin would set up custom domains. Below you’ll see three preliminary designs that outline:

  1. Where this feature is located within admin.atlassian.com

  2. The four-step process to set up a custom domain

  3. Details on what that process looks like when you are specifying your custom domains URL

Screen 1. This capability is located within admin.atlassian.com, where you configure your Product URLs.

screen1.png
Screen 2. The is the four-step process to create a custom domain. First, choose the product, then specify the URL, add DNS records, and activate the custom domain. Atlassian would automate the certificate management on your behalf.
screen2.png
Screen 3. The guided flow to specifying your custom domains URL with 3 parts: a company-branded domain name, a list of options for the 1st-level subdomain keyword, and a 2nd-level subdomain at your own choice
screen3.png

We are excited to share these preliminary designs, which are subject to change based on customer feedback in the next few months. Please feel free to share any feedback; we are specifically interested in your thoughts on Screen 3, where you will see the mandatory two levels of subdomain names. If there are specific keywords relevant for your use cases, please share in the comments.

For example: help, support, or portal for JSM Help Center; jira, project, work for Jira Software; confluence, wiki, knowledge for Confluence, etc. These keyword (i.e. 1st level subdomain) would be part of the custom domains URLs like, for example, internal.support.acme.com, people.knowledge.acme.org, etc.

Thanks in advance for your engagement.

Luke

90 comments

Comment

Log in or Sign up to comment
Dave Mathijs
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Feb 28, 2023

Thanks for the update @Luke Liu  ,finally some progress! CLOUD-6999 has been created on 08/Jul/2011. 😲

The interface/wizard looks intuitive and promising.

🤞🏻 Fingers crossed for a release in the near future.

Like # people like this

Hi,

Having taken part in the customer interviews, I just want to re-state my reservations about this solution design.

I see no reason why the URL is required to have three parts; it's unusual for publicly available sites to use a three part domain, and this restriction means that URLs are unnecessarily wordy/duplicative and difficult for users to remember. If we were forced to use this structure we would have to make up a third part of the domain that actually makes the purpose of the site less clear.

No other SaaS service that we use enforces this structure - everything else allows us to use a subdomain like mycustomdomain.mycompany.com.

We'll be pretty disappointed if, after so many years, this is the best Atlassian can deliver.

Cheers,
Freddie

Like # people like this

Dear @Luke Liu ,

Thanks for this step ahead!

Having to choose the 1st level subdomain from a pre-defined list of options is a little akward but in my case this is not a big issue so I think you can go ahead with this proposal.

Looking forward to more updates on this topic.

Simone

Like # people like this

Hi @Luke Liu

 

I agree with @Freddie Joyce

 

What is the benefit of the subdomain keyword? What does this subdomain keyword achieve which you can't do if you enter the full custom domain? What is the reason behind this design? Technical limitations?

 

The usage of domains with more than one subdomain level is quite uncommon in the internet world, because nobody can remember them. Domains with multiple subdomain levels are mostly used for internal/intranet solutions.

 

As most of us want the custom domains for the customer-facing solutions, the design doesn't fulfill the requirements.

 

Patrick

Like # people like this

First - glad to see some progress 👌

Second - I’m guessing 99.99999999% of everyone wanting this feature want “BLAH.SOMECOMPANY.TLD

They really, really, really, really, really do not want BLAH.SAFEWORD.SOMECOMPANY.TLD that you propose in the screenshots.


Please don’t ruin it for us.

pls fix kthx 

Like # people like this
Alex Cumberland
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Feb 28, 2023

@kajtzu is exactly right.   Under server we have tied our domain for our customers using same as our company website.

 

So ours works out to  jira.companydomain.com.

It is easy for our customers to remember and is not overly complicated like the proposal being suggested.

Like # people like this
David at David Simpson Apps
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
Feb 28, 2023 • edited

Hi @Luke Liu 

First thank you for an update on CLOUD-6999.

Let's just start by reviewing what the scope of the issue is.

People want to be able to have a custom URL of https://mysubdomain.mycompany.com/ where mysubdomain is a custom subdomain that could be anything and mycompany.com is my company's domain name.

That is the sole requirement to this issue which is almost 12 years old, have over 1400 comments, 7700+ likes and 2500+ votes.

So I'm really glad that you've spared the time to share your initial designs to the problem stated above.

Let's just repeat what the requirements are here to be absolutely clear:

People want to be able to have a custom URL of https://mysubdomain.mycompany.com/ where mysubdomain is a custom subdomain that could be anything and mycompany.com is my company's domain name.

So how does the initial design solve the problem? It does not. It completely misses the point.

Nobody asked for example.keyword.domain. No one. No one. 

If you want to allow multiple levels of subdomain, just support all levels of subdomain, e.g.

  • a.mycompany.com
  • a.b.mycompany.com
  • a.b.c.mycompany.com
  • a.b.c.d.mycompany.com
  • ...
  • a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.mycompany.com

and so on. Add the CNAME record and let's go.

David

Like # people like this

Good to see some action on this old request.

Regarding the mandatory two-levels of subdomain.

Please feel free to share any feedback; we are specifically interested in your thoughts on Screen 3, where you will see the mandatory two levels of subdomain names.

This seems unnecessary to me. I think a single field to enter the subdomain name is sufficient. DNS type A records just contain a text string - right?

Admins can then choose something logical for their situation. For us the following patterns would make sense:

  • wiki.acme.com (Confluence)
  • support.acme.com (JSM)
  • jira.acme.com (JSW)

Admins that need a 'multi-level' domain URL, can enter a two-part subdomain:

  • "internal.kb" to get "internal.kb.acme.com"
  • "internal.support" to get "internal.support.acme.com"

Your post does not explain why a second level needs to be enforced (mandatory). What is the business case or need for this? I'm guessing this might be related to the way SSL certificates are managed.

I assume you are only allowing ONE custom domain for each cloud app instance (e.g. Confluence). So you could not have a single Confluence instance with different URLs for external users and staff.

Dwight

Like # people like this

@Luke LiuThanks for the update - glad to see progress!

I'd echo the feedback from @Freddie Joyce and others here - forcing two levels of subdomain (with one of those being selected from a predefined list) doesn't make sense to me, and is inconsistent with pretty much every other cloud service I've used.

For us specifically, forcing two subdomain levels won't work for our use case - we'll have to move to a different product instead of moving from Confluence Server -> Confluence Cloud.

Zach

Like # people like this

Thank you Luke for the details on that. I know a lot I customers that are waiting for this feature.

Hey @Luke Liu and the team behind the scene!

Kudos to y'all. Really appreciate the effort of this feature, which has been a long time coming. I can also appreciate the sentiment from the majority of the comments.

Can I clarify the differences between a single-level custom domain (help.company.com) and a two-level one (help.support.company.com)? For example, does it have a different effect on SEO?

As a customer, it would be helpful to understand if this decision will have any negative impact on us apart from the reality of living with a much longer URL. 

Ivan Lobotka
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
Feb 28, 2023

Hi @Luke Liu 

I fully agree with @Freddie Joyce third level of the domain is enough.

There is no reason to have a "subdomain keyword" ... which is by the way not familiar with DNS standards and domain name hierarchy (the subdomain keyword is not representing the level of hierarchy).

The "only" selectable subdomain keyword (from a predefined list) is hard to understand...

And not to be "negative" I really appreciate the possibility to create a separate third-level domain name for each product. 

The question just popped up Can I have one common third-level domain name for all products?

kind regards

Ivan

Like # people like this

Finally some progress well done! I have a request for a keyword. Please add NULL as one😁.

Like Yorick Matthys likes this

Great feature! When is the release scheduled for?

Hi,

If we're limited to a series of predefined 'subdomain keywords' that is by no means a 'custom domain'.

Our clients and audience are native spanish speakers, and so by no means we want our subdomain keyword to be help, support, or whatsoever english word. We could be fine with soporte.compania.es, but not support.compania.es.

Besides, forcing the domain to be 3 dots is crazy!! it.support.compania.es... Really, George?? Again, what about any other languaje speakers, where the word order is different? soporte.informatico.compania.es could be fine, but by no means informatico.support.compania.es.

The way it is exposed right now this feature does not fill our requirements.

Like # people like this

Which hallucinating marketing executive thought this up?

Forcing an extra subdomains is ridiculous and not at all what people are waiting/hoping for, not at all what many other companies with similar "bring-your-own-domain" schemes require. I cannot fathom the reason why this extra complexity was invented.

Atlassian is really discrediting itself with this fiasco so far, why make it worse?

Are there practical or security implications that forced you to adopt this design? As a product manager and security officer this just looks like corporate hubris of the highest degree.

Can someone please elaborate? Maybe there are convincing arguments on why this was done.

Like # people like this

Luke, please don't make us sad with that keyword whim.
There is already enough suffering in the world.

Like # people like this

To echo what many others have said.. the additional keyword is unnecessary, let us set our own domain, be it one, two or x sub-domain levels deep, we will create the CNAME that suits our business and away we go. Don't force us to have something we don't want and no-one asked for. Do better!

Like # people like this

Hi @Luke Liu ,

I will not re-iterate what has been raised already with this keyword, as you are not fulfilling the actual requirement for custom domain. 

For me - when do we finally get it ? GA Release date ? 2024 ? 2035 ?

Personally - i see no progress nor commitment from Atlassian to deliver that anytime soon

Like # people like this

Please please listen to everyones feedback above. We all agree and nobody wants the additional keyword. Like Dwight puts it, this is all we want:

  • wiki.acme.com (Confluence)
  • support.acme.com (JSM)
  • jira.acme.com (JSW)
Like # people like this

Hi @Luke Liu 

I have to echo what everyone is saying, especially @Freddie Joyce and @Dwight Holman

Having an obligatory keyword just makes the URL unnecessarily tedious for end users to remember. It would be great if this could be reconsidered.

Like # people like this

I only want these 5 things.... Please!!!!!!

  • No 2nd level subdomain requirement
  • No 2nd level subdomain requirement
  • No 2nd level subdomain requirement
  • No 2nd level subdomain requirement
  • No 2nd level subdomain requirement
Like # people like this

Who at Atlassian thought this is what people wanted? It's more complicated for end-users to remember two subdomains. This isn't what your users wanted. 

As @Dwight Holman said, this is all we want: 

  • wiki.acme.com (Confluence)
  • support.acme.com (JSM)
  • jira.acme.com (JSW)
Like # people like this

Thank you for providing an update. We are grateful for the progress.

In regards to feedback on Screen 3, we see no valid reason to have 2 levels of domain names. 1 is what is expected.

ourchoice.ourdomain.com is what we expect and need.

Like # people like this

This this doesn't enable it all the ability to use a custom http root path. Such as:

acme.net/jira
Like # people like this
TAGS
AUG Leaders

Atlassian Community Events