Why is deleting Organisations so painful?

[#1]

As the main Admin for my organisation, I run into the same problem on an annoyingly regular basis: a user is invited to join our organisation, and at some point in the account activation process they manage to create a separate organisation by mistake.

Every time this happens, I have to insert myself into the organisation as an org admin (after checking that they did actually create it by mistake of course), remove the user who created it, remove all the app subscriptions that I am able to remove, wait the 90-day grace period, and then attempt to delete the organisation.

In just about every instance, I am thwarted at this point by being unable to remove Rovo, so I then have to raise a support ticket to get this removed before I can again attempt to delete the organisation. This seems ironically inefficient for a tool that is meant to promote efficiency.

From what I've seen around the Community I'm not the only one who encounters this issue, so...why is it still an issue? Surely there's an easy fix in there - either allow admins to remove Rovo (yes, yes I know - it's "integrated into the core architecture") or allow orgs to be deleted while Rovo is still active. Or am I being too naive?

Does anyone have a better way of dealing with this situation?

[Roberto Miasack]

up up up

[Jonathon Choy]

This is pain that I know all too well and sounds like experienced as frequently as yourself. The Atlassian solution as I am to understand is to purchase Enterprise. Though that in itself isn't really a solution per se. If you have removed users and spaces etc, the onus is still upon Atlassian support ticket to remove the apps added in the Organisation. This may be a strategic although still rightfully painful way of doing things. As a free, standard or premium tier; you will not have the ability to set policy to block Shadow IT creation and the response I've come to expect is a case of please be patient, sadly.

[Martin Runge]

Hi,

Do you use Atlassian Access with an authentication policy? If you enforce SSO via your identity provider, users get redirected through your IdP, and the Atlassian account creation flow no longer offers them the option to create a new app and organization, as far as I know.

If your organization is on an Atlassian Cloud Enterprise plan, there is a built-in safeguard for this: the Shadow IT settings in admin.atlassian.com > Apps > Shadow IT allow you to automatically claim or block new apps created with your company's email domain, preventing these accidental creations.

[Sonal Malik]

Hi  

If you want to turn off Rovo AI features like Agents and Chat entirely, you can deactivate the AI-enabled apps.

In Atlassian Administration, navigate to Apps > AI settings > AI-enabled apps

Core Rovo features like Search and Studio are part of the Atlassian platform and cannot be disabled independently, but deactivating AI for all apps will disable Rovo Agents and Chat

[Tim Martin]

Does anyone have a better way of dealing with this situation?

I find a strong drink and some time outdoors helps...

I still have demo orgs from years ago that I've been unsuccessful in getting removed, even after support tickets. Perhaps one day I'll create a throwaway gmail and assign it as org admin of them all and kick out my real account. 

I'd like to see more controls in Guard - tied to domain based polices. And better messaging/direction when someone tries to sign up for a new site from a managed domain (both to the person, and org/security admins).

Guard (maybe Premium) should be what decides what someone can do with their account outside of the walls. If Enterprise licencing is involved, let people sign up for app instances within the walls. 

[Greg Tucker]

This has happened to me once, and I still haven't jumped through all the hoops to delete it. 

An equal question is why is it so easy for our users to create new organizations. I have also not jumped through all the hoops to prevent them from doing this, if it's even possible. I have a lot of other roles in our small organization beyond "full time Jira admin". 

[Alex Ortiz]

I ran into this exact problem today. . . .Atlassian really does need to fix this.

[James O_Connor]

@Jonathon Choy I did see that the controls around controlling shadow IT are in Enterprise, but unfortunately it's just not an option for us.

I think you're right - I just have to be patient (and blow off steam by moaning about it in the Community of course 🤣)

[James O_Connor]

@Martin Runge We do enforce SSO but it doesn't seem to make a difference - users still manage to create external orgs. I've even tried sitting with several users when they're activating their accounts and there was nothing obvious that I could see which would lead them in that direction (those users didn't end up creating their separate orgs). My next move is to try and provide some guidance using an onboarding video to see if I can catch it before it happens.

[James O_Connor]

@Sonal Malik Unfortunately, that doesn't really solve the problem. In order to delete organisations, Rovo has to be removed not just disabled, and the only way that can be done is by the Atlassian support team. 

[Christian B_]

I feel exactly the same—there are always colleagues who either accidentally or on purpose spin up a new organization instance or, just as annoyingly, send requests for yet another app. We're enforcing SSO, but that does not help.

Example: In our case, we already have a highly integrated wiki system, and the company has made it very clear that Confluence is not to be used. And yet… the same requests keep landing in my inbox. At this point, I’ve reached a zen-like admin state where I simply ignore them and hope they go away on their own. 

Why?? Atlassian, why?? Is this some kind of grand plan, to squeeze out just more app sales while driving your already-paying users slowly into madness?

(Ups, sorry, this thread is about deleting Organisations, but I'm just oh-so annoyed)

[Dirk Ronsmans]

Indeed, this used to be a lot easier before Rovo. 

Now it seems the only way is to raise a billing support ticket to have it fully deactivated and then you can try and remove it.

My workaround tends to be a generic email address and pass on the organization admin to that one. This way it's no longer on my main account and it's just an orphaned organzation.

Not the cleanest way but at least it no longer bugs me.

[Richard Scholtes]

YES! 100%, yes! This is a pain. I still have a corpse of an org in my list, that a support ticket couldn't get rid of. We will be on Enterprise soon and I hope this will give me the big hammer to squash this one at last.

But in the end, this is WAY too painful of a process and WAY too easy for users to accidentally cause the problem without any control possibilities for us admins other than educating the users.

I mean, can't orgs just have a self-delete, when they're not used for 90 days or something like this?

And of course, we have SSO in place and it doesn't prevent the problem.

[Thorsten Letschert _Decadis AG_]

I'm currently trying to get rid of some old testing org's as well and as of now my support experience sounds quite promising. Fingers crossed and I'll share the results here.

[Nikola Perisic]

Cancelling every app, removing users from all groups, the grace period...I mean I get it. Atlassian does this for governance purpose. However, this needs to be much more easier for us admins. Plus why the grace period is so long? I have a test instance with more than 20+ organizations. I want to delete most of them, but I need to go through this tedious process. 

Atlassian, please react.

[Frank Kulla]

Honestly, I can’t understand it either. Luckily our users don’t accidentally create shadow sites very often – but still, every time it happens, the procedure stretches over weeks! And even then, you still have to create a support ticket because you can’t get rid of Rovo. On top of that, it seems that only Enterprise customers are able to prevent the creation of unwanted sites – instead of giving all company customers the ability to block additional site creation by non-admin company users.

Right now, I take over control of the site, remove the products, and immediately open a ticket with support.

And regarding your initial question about why deleting organizations is so painful – well, the sarcastic part of me has a strong opinion about why.

[John Wignall]

100% agree, this is a pain. 
For those pointing to Shadow IT, it requires a higher level of license than my organization was willing to pay for  to block new orgs. Just one way for Atlassian to pressure us into spending more money. 
I've made my feelings clear in the support tickets, but we really need some significant pressure on Atlassian to either make clearing these out easier or make it harder for users to accidentally create new organizations without even realizing it. 

[Bill Goetz]

If I already have managed accounts already tied to an existing Org, then there is no way users should be able to spin up new Orgs, without some sort of approval. Atlassian needs to address this!

I usually just leave the current Org up and remove user access, that way it couldn't be spun up again if it was deleted. I've already been down that road.

[Carla]

From another community post I saw earlier this year a user shared they submit a support ticket with the following. I've had great success and am able to delete the org within a few weeks instead of months. 

Due to our security protocols new orgs and sites outside of (ORG) are not permitted with a (company name) ID. These are often created in error but we are unable to restrict this event.

Please expedite the removal of all apps and deletion of
org ID- 
org name- 

We understand and agree with the implications of this action. Please let us know when the org will be available for deletion.

[joao zampa]

This is a weekly issue for us, and having the solution behind a paywall is not ideal since we don't see much value on the Enterprise plan when we evaluate the cost of it. 

TL;DR: We are stuck with manual admin tasks that is a pain to deal with.

[Darryl Lee]

Here's the wording similar to what I use in every Support Ticket going back to when we first ran into the problem of accidentally created sites way back in April 2024 (shortly after migrating from on-prem to Cloud):

---

Summary:

Please expedite deletion of #accidentalit created site COMPANY-team-RANDCHARS.atlassian.net/

Description:

Please expedite deletion of COMPANY-team-RANDCHARS.atlassian.net which was once again created by #accidentalit where a user was simply trying to log into our real site (COMPANY.atlassian.net) and instead got funneled into creating a new site by mistake.

---

I don't usually ask about deleting Rovo specifically.

They usually get back to me in a day or two to confirm:

If you decide to expedite the deletion of your cloud site COMPANY-team-RANDCHARS.atlassian.net, note that while we can initiate the deletion process, it will take 14 days for your site to be fully deleted. This is because we are required to retain your data during this period before it is permanently destroyed.

When the deletion process is completed, the site results in the following:

• Users will no longer be able to log in to the site

• Data will be immediately and permanently deleted

• The site URL will become available for anyone to claim after 45 days

• This action cannot be undone

Taking these actions will remove the app from your cloud site and permanently delete all of its data which is IRREVERSIBLE. We ask that you BACK UP YOUR DATA first before we proceed.*

If you wish to rename your current URL or swap the URL with another cloud site, respond with any of the following:

• I would like to rename my site to exampleurl.atlassian.net

• I want to swap my current URL exampleurl.atlassian.net to this site exampleurl.atlassian.net

Please note: If deletion is processed, the URL can only be reclaimed after 45 days.

To expedite the process of site deletion for roku-team-wptbn7ts.atlassian.net, we require your written confirmation. Acknowledge your understanding of the implications of this action by responding with either "YES" or "I AGREE". This will serve as your consent to proceed with the deletion process.

I have to remember to reply YES, I AGREE.

They usually reply within a few days that the deletion process has been initiated. I always ask them what the date of the site deletion will be, and then I ask them to freeze the ticket until that date.

Usually I miss the replies, and there's sometimes a delay from Atlassian, but looking at my logs (an Excel sheet)  it seems like it still takes at least a month from when we make the request to when the org is deleted/deleteable. Sometimes it's a little less than a month.

@Martin Runge we've had SSO since day 1 of being on Cloud. It does not prevent this, because creating a new site does not require authentication, and in fact, it recognizes your existing authentication tokens and cookies and welcomes you back by name.

This recently started happening again with Atlassian Service Collection, where it would recognize your name, but still invite you to create a new Service Collection. Very similar to what I documented two years ago (sigh): Why is Atlassian promoting Shadow IT? Or Accidental IT? 

[Darryl Lee]

@James O_Connor I went back and read a bit more deeply. If your users are following the links to join sites they've been invited to, and still end up creating new sites by accident, something is very broken indeed.

I would open up a Support Ticket and ask them to escalate it to the team that handles invitations, as this should NOT be happening.

So to clarify:

• Your organization has claimed your company's domain, and any login attempts get re-routed to your IdP for SAML SSO?
• Not all users in your company are in Jira and/or Confluence, so you have to "manually" invite them? (So you are not provisioning all users using SCIM?)
  [It's been a while since I set this up, and then we switched from SCIM to Azure AD for Nested Groups, so it's different.]
• Or are these users external to your company? No, that wouldn't make sense because you wouldn't see them in your Org.

I think the invitation bit is throwing me off. What do you mean by that? Using the "Invite Users" button from the Atlassian Admin hub? Because you also mention sitting with users while they activating their accounts, and I guess that's depends on the SSO JIT bit here: https://support.atlassian.com/atlassian-cloud/kb/what-is-just-in-time-provisioning-and-how-to-set-it-up/

But I thought that means that everyone with a verified domain gets provisioned, and there is no "invite" process.

Like what happens if one of your users who is not "invited" simply goes to https://YOURSITE.atlassian.net/ and types in their company email address?

[James O_Connor]

Hey @Darryl Lee,

Yes, that's correct - we've claimed the domain, everyone gets rerouted through SSO, and we manually invite users using the 'Invite users' button. I sat with a user a few months back and watched him click on the link in the "You've been invited to Jira" email and go through the initial steps, and nothing blindingly obvious stood out in terms of links to create separate orgs so I couldn't see where anyone could go wrong, and every time it's happened the user just claims that the steps just led them through the creation and they can't remember any detail.

We're on the Teamwork Collection and I do wonder if it's maybe something like other admins are inviting users to a single product - say Jira - and then they're getting a link to say "Hey you should also try Confluence!" or something, but I haven't been able to prove that.

We've got a new team member coming on board in the next couple of weeks so I might use them as a guinea pig and try a few different things to see if I can reproduce whatever's happening - if I can at least get an idea of the exact cause then I can put an onboarding guide together to help them avoid it.

[Gary Spross]

I completely agree that this is an issue that Atlassian should address. Fine if you want to have some overly elongated process for deletion of a site, I get it, but the ability to block users from creating sites should be included with a standard Guard subscription. Having Guard is what allows you to claim ownership of a domain, so that is what should be the gatekeeper of the ability to block accounts aligned to the owned domain from creating new sites. 

Enterprise licensing to individual apps should NOT be the gating mechanism for access to this feature. We have Jira Enterprise, so I'm able to block the creation of Jira sites, but we have the Premium plans for Confluence and JSM, so we can't block the creation of new sites for those apps. Make it make sense!!!

[Sebastian Wigge]

We are also struggling with Shadow IT and accidentally created orgs by users a lot. It's incredibly time consuming to get rid of those orgs. This has to improve. 100% agree with you all.