This is becoming increasingly challenging to deal with, especially for the sites created due to a single character typo offset in the name, and is leading to admin interface challenges with that typo being so slight that we end up in the wrong site domain when trying to administrate or do any work related to our actual site domain.

Users are creating one of these by mistake every two weeks and it leads to a cluttered admin interface trying to delete all wronly created sites.

this is critical to solve, Please implement this as soon as possible .....

Hello,

For our company we would like to have control of the users from our domain and billed for users of our own company sites created by our org admin. We do not want to be billed for users using our company domain for independent sites created by anyone and out of our control. We understand that the point of Atlassian Guard is more control and security.

Hello Atlassian Team,

This situation is causing an increase in the use of Atlassian Guard (License increaseing). Until this issue is resolved, you should make the "Atlassian Guard" licenses free of charge.

Note: When you export the Discovered Products data, Atlassian Guard billing shows "Yes." Please resolve this issue or exclude the free sites created by users from "Atlassian Guard."

Best regards.

Please Please Please implement this.  the process removing a new org and product that someone has added that shouldn't have is very annoying.

There have been complaints and similar issues about this problem for YEARS now. It's clear that Atlassian DGAF about all of our concerns or effort required to clean up these rogue and pointless cloud sites.

Look at the Jira product tier comparisons on the pricing page. Enterprise licenses have the option to manage "product requests". The page says the product requests feature enables "... admins to manage how and when managed users create Atlassian products."

This feature request sounds a lot like that feature. If that's correct, the feature is available, but only for the Enterprise tier.

On top of this, when my users subscribe, even on a free product tier, I get hit with an Atlassian Guard license charge for the user that signed up and any other users that they add to their unauthorized environment.

Essentially, Atlassian's greed is the only thing keeping this feature from being rolled out. They don't want to lose the revenue of end users opting into added expenses for their paying orgs in the form of added Atlassian Guard subscriptions. And if we, the paying orgs, want to prevent the security concerns of shadow IT, well, we can just fork over more $$$ for their Enterprise plan.

yes this is a HUGE security issue and takes forever to get these deleted.  i still have several that have not yet been fully deleted and one was set up today, on a billing cycle, with our company name.  by no way should users be allowed to create new products using a company related email address already a user in that company's domain.

I want to high here that this should be addressed not as feature "gathering interest" but a design flaw that leads to a privilege escalation security vulnerability. We have users with standard access that are able to perform administrative level functions that incur real costs to the parent company to mitigate and have the potential for privacy violations and data leakage. There is no other way to frame this issue besides being a security vulnerability.

Other issues related to this issue:

https://jira.atlassian.com/browse/ACCESS-1468 "Allow Administrators to control managed users' associated sites and products" This one is linked to this issue but was closed / split without actually dealing with the underlying issue. Closing this issue dilutes urgency of the issue as it negates the 1611 votes and the age (30/Jan/2020) of the original request related to this problem.

https://jira.atlassian.com/browse/ACCESS-1135 "Need to control or manage; users or user group from creating products"

https://jira.atlassian.com/browse/CLOUD-10325 "Allow non-Enterprise administrators to control managed users' associated sites and products" Updated after ACCESS-1468 was closed to refine the issue since the ACCESS-1468 did not fix the problem of managed users being able to recreate new orgs and hence new products.

Users are creating sites by 'mistake'... seriously?

I do not see any scenario why a standard user would ever be required to create a site within the organisation. I think it is a pity this has never been addressed as this just seems like basic User Access Control to me. Seeing the amount of comments and duration that this ticket is already open, I think this reply won't change much...

The lack of this feature is everything from the total pain of cleaning up products made by mistake to a serious security breach. Right now a user with a company domain email can create their own unauthorized product and then add unauthorized users to to create a fake impression that this product belongs to the company.

It should be one of the basic features for managing users' accounts.

This is truly a PITA, and completely annoying that Enterprise customers can easily prevent the problem while lowly non-Enterprise customers cannot. This is an awful way to treat customers.

I see this issue is assigned to an inactive people, i don't know in this way how it could be delivered

The customer experience is currently deceptive

If the feature to control creation of new cloud sites is available to Enterprise customers, it should be relatively trivial to make the control available to ALL customers. I also agree with some comments above that the default should be the controlled option, not open slather

I would also like to have the feauture as Org Admin. Users regularly open new sites with us and want to work together with other teams.

this feature prevents any governance that aims to converge usage towards authorized sites
This adds a monitoring and cleanup burden to which we must add a waste of time for users who create sites that we then ask them to delete.
the best practice would be to make it compulsory to validate the creation of a site on a verified domain.

We just ran across this as well where a user spun up a trial and started creating live content in the space.  It would definitely be nice to be able to block users from creating trials on these products with their org email.

This has become a pain point for our org - having to export data, remove users, and shut down rogue sites on a regular basis. 100% of the time it was users trying to create a new conf space or Jira project and not an entirely new site. Bad UI and bad management tools. 

Much needed on our site as well. Users seam to create own Organisations by error, that we then have to clean up.
it would be nice if the users would be prevented from doing this error.

Much needed!!!!!

This is a much needed feature we are chasing users who made an honest mistake all the time because of this. 

It almost seem like Atlassian found a way to charge companies via mistakes of their users, without them understanding what are the implications of clicking "yes & start using Jira" ... 

Hopefully it will be fixed soon, as I am sure Atlassian has no intention to "deceive" its customers. 

Users keep creating products by mistake. This should be much easier to manage.

The main ticket data, whether in the description or another field, should be updated to state that this is available but currently only for Enterprise plans.

I disagree that this ticket should be resolved, though, as it concerns managed accounts, not Enterprise accounts - and not every org has Enterprise needs or funding.

No work has been logged on this issue since 2021. When I talk to our enterprise advocate reps, they direct us here. There are numerous posts here, on Atlassian Community, and elsewhere that all talk about this being a significant painpoint for your customers. It frankly boggles my mind that: 1) the default isn't to DISABLE this behavior, 2) that it's gated not behind standard or premium but ENTERPRISE, 3) that no work has been done on this and it is assigned to an inactive user, 4) that communication around this from Atlassian's perspective is so poor, and 5) that the manual disabling process is so clunky and time-consuming when to enable an outside org/instance takes a user a few clicks.

I am trying to push for my company to invest further in Atlassian for other reasons–but the decision-makers are not impressed by how gated key and crucial features of the apps' security and administration are.

I noticed the Assignee is listed as: "Yiting Jin (Inactive)" Does "inactive" mean no longer active with Atlassian? If so, can this be reassigned to an active Atlassian?

This feature should not be paywalled behind enterprise as its more of a security and billing concern rather than a enhancement.

It adds unnecessary overhead for administrators when users 'accidentally' create sites 

This possibility really lead to the problem with creating non-control sites outside the organization. Most times users have not clue about and what they requested. 

This is very important.  As organizations scale, having users be able to automatically graft paid plans into our Atlassian ecosystem without compensating controls is worrisome.

to anyone who is impacted:

Trish Y. at advocates@atlassian.com has triggered some expedited process to shut down those 'accidental' websites.

In few days it was down.

HTH

Hi,

Adding on Bret's frustration, for me in the past 3-4 months, my users opened 44 sites, most being to demo the product .

However, they start that way by their administrator, followed by ignorant end users with regular content, and followed by:

• I didn't know, sorry,
• Can you migrate these spaces now, because we thought... bla, bla

My team is not staffed to deal with anything like this, in fact leadership is calling me out, with:

• You wanted to go SaaS, why do you need so many people?

In the past month, two of our users have "accidentally" created new Jira sites using their corporate credentials. Of course they tell me that they had no idea how this happened or even where they were prompted to create a new site. I am truly stunned that this is even possible for normal users without any admin rights using a corporate domain login which is already verified and controlled on an active Jira site. When I try to cancel this accidental sites I am forced to wait 30 days while the product is in a cancelling state, which leaves the site just sitting there unable to be deleted. This is incredibly frustrating and nearly impossible to give a good answer to leadership on how this is even allowed.

It's look's like Atlassian are trying to be "Enterprise" only with prices within their products..

these features should be default to all tiers.

users should not be able to freely do actions that could end up as unexpected bill to the company!

See also https://jira.atlassian.com/browse/ACCESS-1135?focusedId=3425851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-3425851 and https://support.atlassian.com/requests/JST-968487

Only available for Enterprise users.  This shouldn't be resolved until the feature is also available for Jira Standard and Premium users.

Why is this still considered unresolved when this article says in Enterprise plans you can block sign up for new products under managed accounts?
https://support.atlassian.com/organization-administration/docs/update-product-request-settings/

FYI, I just found out that this feature is available to Enterprise users: 

https://support.atlassian.com/organization-administration/docs/update-product-request-settings/

This request should be updated to allow this type of setting to be available to us Premium users too. 

We have had 4 "Accidental" org or product creates in the last 6 months alone. It is time consuming and dangerous for us. Not having controls in place to prevent unsanctioned products and orgs buy users in a managed domain is irresponsible. Fix the loophole please.

Hi,

I would like to suggest that maybe a simple "warning/info" dialog with the existing site link and admin contact is displayed, before the new sites are created.

In my case most new employes don't even bother to check with IT first.

I have requested this enhancement more than two years ago.  Nothing has changed since.  Although more users are requesting the same feature, Jira has done nothing about it.  It's frustating that this is not on their roadmap but don't hold your breath.

I have to add a vote on this as well, my company has sensitive data on many products they are developing that we need to tightly manage, and we don't need users creating "Free" sites to skirt the controls we have in place in order to post content in a product that's "more convenient" to them, and then try to keep this data from inadvertently getting pushed out to the public.

Yes, there are controls in Confluence to restrict access but all it takes is someone with too much admin privileges and not enough knowledge of the product and its controls to hand sensitive info to the world through "Public sharing" and "Public links".

This is a major headache for us to monitor on top of our other duties.

There seem to be a bunch of tickets for this feature floating around...this comment was originally seen on CLOUD-10325 but re-posting it to try and get any scrap of attention I can on this:

I can't imagine that the income gained from these instances is really all that much, and while I acknowledge I have no idea what's going on under the hood, I have to believe this isn't SO much work to implement...so what IS the rationale here?

I get not investing in things like "bulk updating" or "group renaming" to make Jira easier to manage at a day-to-day level...I mean, if Atlassian didn't give us mountains of endless, pointless, and repetitive busywork just to get basic activities accomplished, what would we do all day? However this problem is (as so many others have pointed out) a security risk thing. We spend countless hours and dollars securing and maintaining our corporate instance specifically so Bob in accounting can't accidentally leak PII.

Now I know that Atlassian thinks we're all just vendor-locked at this point and that moving to another tool would be even more painful than putting up with all the garbage they feed us. And you'd be right about that. Today. But it'll be interesting to see what happens when a viable option appears.

It's a huge headache (and time-consuming process) to reach out to our users who create rogue instances with our domain. 

I need to walk them through adding me as an admin, then go through and find out what projects and tasks were created in Jira, any docs in Confluence, all the stuff that they do in there by the time I catch it needs to be transferred to our main instance. 

Please at least make it easy to move those projects or spaces into our main instance without all of the other steps. That would be awesome. 

We've had managed users do this more than once, and resolving it isn't exactly a parade down main street either. 

Welp that's me being dumb. Thanks and sorry 23ef3e30d63c!

Hi 78a5cd2342f3 this ticket has been reopened since 14/Dec/2023.

Hi 23ef3e30d63c I will reach out to support as well, but this ticket should be reopened because this ask ("Allow admins to prevent creation of new instances using managed domain emails" is not actually covered by CLOUD-11072. That ticket seems only include half-measures and other not-very-useful stuff.

Thanks very much e41fee99e9e9.

I recommend that watchers of this issue vote on and watch the issue CLOUD-11072 – Allow Administrators to control managed users' associated sites and products which is older and has more votes. So that votes aren't split, I believe this ticket should be closed, but I will wait a week before taking any action in case anyone thinks both issues should continue to exist. Thank you!

I believe this issue might be a duplicate of CLOUD-11072 – Allow Administrators to control managed users' associated sites and products. Could the watchers of this issue let me know if they disagree? Thank you.

Hi all,

we would like to prevent users that are assigned to our org, of creating new sites, and becoming Org admins to this sites,

it's a process then to disable and delete those sites.

Still don't understand how this is not an implemented feature. Why is it called Atlassian Access if you can't control the access for one of the biggest "moves" that an end-user can make - that is creating a separate cloud site. Anybody can create their own cloud sites within the org without permission - that can get too messy and overhead would be too much to organize. 

Please allow a feature to prevent users from creating cloud site using a our verified domain

Also would love to see this implemented. Thanks!

Kieren, 

Inability to moderate new product creation on a verified domain is inflating our Atlassian Access bill projections. 

This is a severe limitation for us in expanding our footprint with-in the Atlassian eco-system. 

Like others have said on this thread, this should not be considered a feature request but a defect fix in the workflows for new product creation. 

Thanks, 

Nas Raja 

When is this going to be implemented. This should have been rolled out when verified domains was released.

This should not be considered a feature addition, this should be considered a bug fix. I cannot believe that this is the default behavior and there isn't any mechanism to prevent managed users from spinning up new Atlassian instances.

Kindly implement this control feature for managed users ASAP

This is increasing unwanted work for Atlassian admins in respective organizations and even for Atlassian cloud support