Adding to the long list of persons wishing they didn't have to regularly clean their organizations....

I realized how funny it is that anyone can create a product in the name of my company but instead me who is the admin am not trusted to take consciously the action of deleting the same and I need a grace period

Creating a support ticket to clean up doesn't address the source of the problem. There needs to be a means to restrict creation so it doesn't happen to begin with.

Forgot to add comment here in the last week. Other two occurrencies on my side.

Plus still a lot of old products waiting for the 90 days and need to check every now and then.

Plus some with errors that make it impossible to delete due to lost link with billing information....

Agree with Blake's comments about admins should be able to block organization creation.  Appreciate everyone's tip to submit support cases to delete them rather than walking the users through to delete it themselves.

Absolutely bonkers that this feature costs extra. Atlassian products are all about management and governance of sensitive corporate data, but unless you pay extra you have no real control. You're selling me the best deadbolt in the world for my front door, but if I want to close my garage it costs extra.

They didn't act on behalf of me. Only instructions as usual

9512ab241227 

just create an Atlassian Support Ticket. With text "Please delete organization [URL], that has been created on coincidence"

181ebff89f1d good idea. That could help me and also I like it as a strategy to push for the change on Atlassian side. Would you share the link to one of your request or paste the text and to whom you raised it so that I can mimic you.

The Atlassian Support ist eager to help out, deleting all the organizations created by coincidence Maybe if everyone creates support tickets for this case, and Atlassian will do a reporting on the amount of support tickets for this, it may increase the priority. 

The process for deleting is long and time consuming, so therefore I take every time a shortcut and create a Atlassian Support Ticket.

Users do not even know that they create an organization by coincidence.

Admins for managed domains should be able to block organization creation. Being notified after creation is helpful but not enough. I'm dealing with 3 organizations that have been created by accident. The users didn't even know they'd done anything. The process for removing these incorrectly created organizations is painful and long.

Today other two users created products in new spaces.

Is Atlassian planning to refund companies for the time wasted for addressing this issues as I am going to do now and as I am doing on a regular basis.

FYI: we are unluckily renewing your suite for this year but we will scout for alternative solution over the course of next year given this poor support on key issues like this

All users at my employer who have spun up products outside our org reported the same feedback to me: they weren’t aware of what they were doing as they were simply following instructions noted in Atlassian tutorials they found online. There are 3 things our company would greatly appreciate serious consideration of:

1. Updating your tutorials to add a disclaimer about the downstream effects of users spinning up these orgs and associated instances. It would be helpful to include:
   1. Describing in more detail what the user is setting up
   2. Cost implications
   3. Shadow IT implications
   4. Potential data compliance violation implications
   5. How involved the cleanup process would be for their employer if they proceed
   6. It would be great to preface any org setup steps in tutorials by saying something like “Please consult with your Atlassian administrators to ensure understanding of your employer’s policies before proceeding with this part of the tutorial.”
2. Shorten the timeframe to delete an org and its associated site(s) by doing one or more of the following:
   1. Shorten the product removal period to a week to complete it all from beginning to end: https://support.atlassian.com/organization-administration/docs/delete-your-organization/
      1. Shorten the cancellation process to 48 hours.
      2. Shorten product deactivation from 15 days to 5 days.
      3. This would allow the org to be deleted about a week after creation. That’s much better than several weeks.
   2. Add a button to the ‘Manage subscriptions’ page called ‘Expedite cancellation’. It would appear as part of the yellow ‘Cancellation pending’ prompt that displays once the subscription cancellation has been initiated. It would allow the user to either:
      1. Go through a series of prompts to complete cancellation in that moment. They could be required to input text that confirms they understand the implications, much like what I had to do above. You could add all disclosures to it about the risks of accidental data loss, etc.
      2. Create a ticket with Atlassian Support that includes all data your team needs to proceed with expedited cancellation/deletion, like hostname, org name, requester contact info pulled from the user’s profile, etc.
   3. Add the details about the remaining steps and their timelines to the ‘Delete organization’ section on the Settings → Details page under Atlassian Administration. I found it difficult to understand how the process works. Documenting it as something like a checklist would be clear. It could list all steps from beginning to end. Any steps the admin has completed are checked off. The remaining steps would note what they are, who is responsible, and the earliest those steps can be completed would be very helpful since currently, this process takes several weeks at minimum.
   4. Add a button labeled ‘Expedite organization deletion’ to the ‘Delete organization’ section on the Settings → Details page under Atlassian Administration. Clicking this would prompt either a:
      1. Series of prompts to complete org deletion in that moment, including any preliminary steps that must be completed. They could be required to input text that confirms they understand the implications as they complete each step in this process, much like what I had to do above. You could add all disclosures to it about the risks of accidental data loss, etc.
      2. Page noting that it will create a ticket with Atlassian Support for assistance and ask them to confirm if they’d like to proceed. If they do, then a ticket would be auto-created that includes all data your team needs, like hostname, org name, requester contact info pulled from the user’s profile, etc.
3. Allow Atlassian global administrators to enable or disable the ability for users to spin up separate orgs/instances. I think the https://admin.atlassian.com/ page is the most suitable location to add a toggle for this. It could be labeled something like ‘Allow users to create and administer products outside the primary organization(s).’ Ideally, there would also be a link there that takes the user to a page describing what this functionality entails, which users would have these permissions, and #1.1-6 above. By default, the toggle should be disabled, so that data compliance policies aren’t unintentionally violated. It should be a conscious decision that a company should make to enable this feature that allows end users to create new orgs/instances.

This is super frustrating, but clearly by design.

You know what I learned when I opened up a ticket with support to discuss?

There is no way to incur a financial charge unless your user opts-in, and supplies a payment method.  In my case, these users are ALL spinning these tenants up in error, thru no fault of their own, during a mobile login flow - While attempting to login to our production tenant.

So, when I get an alert that someone spun up a new tenant, I do the following:

• Link into the tenant
• Make myself the only admin/user (boot the user who created in error)
• FORGET ABOUT THIS

This is spinning up a new tenant, that is in-turn consuming resources that are being paid for by Atlassian (every time some one opens a new tenant, they get some compute, storage, networking, etc) in AWS.

Rather than set a reminder to circle back in 60-days and delete the instance, I leave it FOREVER so it bleeds money from Atlassian....

Your process, your problem Atlassian!

We've now had 4 separate instances created by users this week alone. This is unacceptable. Not only is it a horrible compliance and data security practice to not allow this to be controlled by org admins in all plan tiers but the length of time it takes to clean up these mistakes is asinine.

I've just spent more than 2 hours to try to delete these instances, but the system won't even let me. It's driving me f***ing insane. I refuse to keep professional my composure over this absolute nonsense. This is madness.

This must be the the most malicious feature I've ever seen created by a company.. smells like the handiwork of someone with an MBA degree. In other words, disgusting.

I am surprised that we need a feature request for this behavior that appears to be a lack of admin settings.

In our case multiple users inadvertently created workspaces and after few days they've been asked to pay because the trial of confluence premium (added by default) was expiring.

This looks like a malicious choice and it caused an escalation process in our company that led to re-examine the case of funding the renewal of Atlassian suite.

We are now in the position to identify acceptable mitigations for what we perceive as an unacceptable behavior of the platform. If the mitigations will not be accepted we will have to migrate to another vendor after years invested in customizing Atlassian suite.

That will be a loss for as as a customer and for Atlassian as a vendor. 

I expect a prompt solution of this before end of 2024 if Atlassian is serious with its customers.

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 was closed / split without actually dealing with the underlying issue, that being managed users should not be able to create new orgs.

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.