Why is deleting Organisations so painful?

[Becker_ Rene]

When I asked the support to delete those user created sites (I do so every few months) I asked for escalation. When I got someone to respond besides regular support, I asked, why this is indeed so painful and why it is even allowed for users. I very nice lady explained to me, why that is. That's the response I got (excerpts).

Title: Atlassian added Billing Role; Shadow IT Instances add user that created the new instance; Original Org Admin cannot gain Billing Admin permission; Cannot cancel subscription that were created inadvertedly

---

Question:

Options to keep users from creating new sites, aside license upgrade

Answer: 

Option 1: Introduce a firewall rule in your corporate network/VPN to restrict network access to the following addresses:

https://admin.atlassian.com/o/create

https://www.atlassian.com/try

https://www.atlassian.com/try/*

By doing this, your managed users will not be able to create Atlassian organizations themselves and open the pages that allow starting their own site subscriptions.
Please note that such a network rule will not block you from adding additional products/sites to your current organization but will be a blocker you legitimately require to create another cloud site for your company in a separate Atlassian organization.

Comment: Not helpful. Only works when on company network

Option 2: Send internal communication requesting the managed users in your company to stop creating sites using their corporate accounts in Atlassian Cloud

Comment: Very funny

-------

Question: 

What is the thought behind letting users from company-controlled accounts create their own subscriptions? So far I did not learn, that that ever lead to sustained subscriptions (following the community threads and other exchanges). Also, if I look at the company tenant, I could have users trial these products there and make an informed that way. So … I do not understand the strategy here. Where’s the benefit for either side? If you could explain … I really am interested in understanding. 

Answer:

Why can users with company‑controlled (managed) accounts create their own Atlassian Cloud subscriptions?

By default, Atlassian accounts are owned by the individual user. Even when those accounts become managed accounts under a verified company domain, they can still:

use their Atlassian account to access multiple sites and products (even outside the “main” corporate tenant), and

start trials or new product instances on their own (unless restricted by specific Enterprise controls).

This design is intentional and has a few goals:

Empower teams to move fast: Teams often need to experiment with new tools or products without waiting for central IT or procurement. Letting users quickly spin up a trial helps them validate whether a product actually solves their problem before involving central admin and budget.

Support organic adoption (bottom‑up): A lot of long‑term Atlassian usage starts from small teams trying something out, then standardizing once it proves its value. Allowing self‑serve trials is part of that bottom‑up adoption model.

Keep identity consistent across products and sites: The same Atlassian account can be used for many different environments (your main tenant, test sites, partner sites, etc.). Managed accounts + domain verification simply give your org more control and security over those accounts.

You’re absolutely right that, from an admin perspective, it can feel like these user‑created sites don’t always lead to long‑term, centrally managed subscriptions. They are often:

short‑lived test/trial environments, or

“shadow IT” instances created by enthusiastic teams trying to solve an immediate need.

That’s also why Atlassian has invested in Enterprise‑level controls to manage this behaviour rather than removing self‑serve entirely.

“If we already have a company tenant, why not just trial everything there?”

You can definitely have users trial products on your main tenant, and many organizations prefer this. However, separate user‑created sites can still be useful in some situations, for example:

Isolated testing / experimentation: A team may want to test a configuration, app, or workflow without touching production or cluttering the main environment.

Department‑ or project‑specific sandboxes: Some teams like to maintain their own isolated “playground” or POC instance to experiment freely.

Early exploration before centralization: A small group might spin up a site to try something quickly, and only once it’s proven do they approach central IT to bring it under governance.

That said, you’re right that this flexibility has a downside: it can create fragmentation and “unsanctioned” sites if it’s not governed.

Where’s the benefit for the company? Where’s the benefit for Atlassian?

From the company’s side, the benefits are:

Speed & autonomy for teams – they don’t have to wait weeks for approvals to run a small proof‑of‑concept.

Innovation at the edge – teams can try new tools and approaches that central IT might not prioritize yet.

Option to add governance later – with domain verification and managed accounts, you still get visibility and can bring accounts/sites under control later.

From Atlassian’s side, the benefits are:

Lower friction to adopt products – a single user can try something in minutes without needing a big project to get started.

Natural upgrade path – successful trials often grow into centrally managed, paid subscriptions when the tool proves its value to the wider team or organization.

What if we don’t want users to create their own sites/subscriptions?

This is where governance features come in. For organizations that see this as a risk rather than a benefit, there are ways to tighten control:

On Cloud Enterprise, you can use Product Requests / App Requests to prevent managed accounts from signing up for new product instances or apps without admin approval. This is specifically designed to reduce shadow IT

Even without Enterprise, you can use network / firewall rules and internal policy to restrict access to sign‑up URLs like.

Those controls don’t remove the underlying self‑serve capability from the platform, but they allow you to decide locally whether users can exercise it.

---

So make of it, what you want. But I guess the answer is pretty clear.

---