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.