I've been talking with Atlassian support about accidental site creations. A new ticket has been created to reduce the chance that new sites will be created accidentally via the "sign-up" flow.

Note this new ticket is just about reducing the likelihood that new sites will be accidentally created, not preventing new sites completely. To quote the ticket description: "The intention of this Suggestion ticket is not to block new Cloud site creations, but to reduce the occurrences of accidental site creations".

I suggest you go and vote for / follow this new ticket: https://jira.atlassian.com/browse/CLOUD-12193

And as always I sent a reply I'm not happy with the 14/45 days deletion time ;

Thank you for sharing your concerns with us. I understand how frustrating this situation must be for you, and I truly appreciate your patience as we work toward a more permanent solution.
I would like to address your concerns and let you know that we value your feedback. We are actively engaging with our internal teams and directly expressing the frustration you are experiencing regarding this issue. Our goal is to provide enhanced shadow IT controls for non-enterprise customers, though I am unable to provide a specific timeline for when these improvements will be available.
Please note that I have initiated the hard deletion from my end to get the site "****" deleted and it will take around 14 days. I will soon share the final deletion date with you after I receive a confirmation from the internal team.
I sincerely appreciate your understanding and cooperation as we work together to resolve these issues.

Appreciate the perspective.  I think the point of frustration for a lot of us is, whether it can be deleted in 14 days, 45 days, or 1 minute, that this is entirely preventable by Atlassian and serves nobody's interest except Atlassian's interest in increasing their metrics and profit.  It is a frustrating and an total waste of everyone's time to have to deal with any of these sites being created by unwitting users who are misdirected by intentionally and poorly designed login pages.  The solution, according to Atlassian is, pay more.  I will happily pay more for other features that bring value to my teams, but this is a design decision by Atlassian to intentionally inflate their metrics and profit.  They would rather ignore the noise here than fix the problem, and the problem they have created is 101 security and manageability.  Its basic, not enterprise.   DO YOU HEAR US ATLASSIAN?   

0780f5450831 just wanted you and others know that as frustrating as this problem is (and I just had two new sites accidentally created in the last 24 hours, so it'd definitely still happening), you really can delete a site and the organization in less than 45 days (but more than 14). [Yes yes, it's a soft-delete, which I don't care about since it was an accidental site.]

Most recently, I had sites two Confluence sites created 20-Dec-2024. I cancelled them on 22-Dec-2024 and requested expedited deletion. On 10-Jan-2025 (20 days - maybe they took off Christmas and New Years), the sites were deleted, and I was able to delete the organizations as well.

Another more recent example: 5-Jan-2025 a Confluence site was created. It was cancelled 6-Jan-2025, and again after filing a ticket to request expedited deletion, it was finally deleted yesterday, 21-Jan-2025, and we were able to delete the org. That's 15 days exactly.

I wish I could automate this process. :-/

Hi all,

Indeed, we are all familiar with this typical repsonse by Atlassian support:

• When a site is marked for deletion, there is a 14-day period before you can proceed with deleting the organization. This time allows us to ensure that all necessary processes are in place to protect your data.You will be able to delete the organization 14 days after the deletion request is initiated. I will soon share the deletion date for your site after confirming with the internal team.
• Following this, there is an additional 30-day soft deletion window. This is part of Atlassian’s commitment to safeguarding your information against accidental loss. During this period, your data is tagged as "Soft Deleted" but not permanently erased. This provides a safety net in case the deletion was unintentional or if you need to recover any data.

What we really need is the same kind of responsibility and some proactivity (instead of reactivity) when a user is creating a site entirely by accident:

• We need the ability to control whether managed users are allowed (or not allowed) to request new sites or products
• When a user is allowed to request a new site or product, this must be subject to approval by an organization admin BEFORE the site or product is created!

This is the ONLY REASONABLE SOLUTION for this problem which is already lasting for way too long!

Stefaan

PS: for everyone following this topic, please also follow and vote for the below topics, because that's the only way to increase our visibility for this ENORMOUS PROBLEM with Atlassian products that have names or features like "PREMIUM", "MANAGED", "GUARD":

• https://jira.atlassian.com/browse/CLOUD-10325
• https://jira.atlassian.com/browse/CLOUD-12089
• https://jira.atlassian.com/browse/ACCESS-1135
• https://jira.atlassian.com/browse/ACCESS-1645
• https://jira.atlassian.com/browse/ACCESS-1468
• https://jira.atlassian.com/browse/ID-7697
• https://jira.atlassian.com/browse/ACCESS-1679
• https://community.atlassian.com/t5/Articles/What-s-the-word-I-m-looking-for/ba-p/2862486
• https://community.atlassian.com/t5/Confluence-questions/SECURITY-ISSUE-during-login-procedure-of-managed-users/qaq-p/2841895
• https://community.atlassian.com/t5/Atlassian-Account-questions/How-to-Prevent-Atlassian-Products-being-added-by-users-w-company/qaq-p/2401874
• https://community.atlassian.com/t5/Questions/Why-is-Atlassian-promoting-Shadow-IT-Or-Accidental-IT/qaq-p/2731538
• https://community.atlassian.com/t5/Enterprise-articles/An-update-on-product-requests-bringing-shadow-IT-controls-to/ba-p/2840760
• https://community.atlassian.com/t5/Articles/Proposal-to-prevent-Accidental-Site-Creations-accidentalit/ba-p/2867193#M558

 
It’s so easy for users to create new sites—why is it so difficult to delete them?

This week, another user accidentally created a site and submitted a support ticket to expedite its deletion. The response? 45 days. Even after requesting a shorter timeframe, the response remains the same: 45 days.

Thanks for getting in touch with Atlassian Support. My name is <..>, and I'm the support engineer who will be assisting you further with this issue.

I want to sincerely apologize for any frustration or inconvenience this situation has caused. We truly understand how important it is for you to resolve this quickly, and I'm here to assist you.

When a site is marked for deletion, there is a 14-day period before you can proceed with deleting the organization. This time allows us to ensure that all necessary processes are in place to protect your data.You will be able to delete the organization 14 days after the deletion request is initiated. I will soon share the deletion date for your site after confirming with the internal team.

Following this, there is an additional 30-day soft deletion window. This is part of Atlassian’s commitment to safeguarding your information against accidental loss. During this period, your data is tagged as "Soft Deleted" but not permanently erased. This provides a safety net in case the deletion was unintentional or if you need to recover any data.

We understand that waiting for this process can be challenging, but please know that it’s designed to give you peace of mind by allowing a recovery option if needed.

Hi team,

We’ve noticed a recurring issue related to the unintended creation of sites with URLs like "team-[random_string].atlassian.net," which are auto-generated by Atlassian when users sign up for new products. This appears to happen due to a UI flow where Atlassian suggests a URL based on the user's managed account status.

Although it was confirmed that this is an end-user-triggered process, it’s clear many users are unaware they’ve created a site, leading to unnecessary instances that benefit neither the user nor Atlassian.

We believe it would be valuable to revisit this case and -evaluate it.
Referred case: PCS-362222.

Personally I don't even mind if users can sign up for new products, as long as I'm notified about it. But stopping them accidentally creating new "sites" seems like a no-brainer (to everyone except Atlassian it seems).

I did a bit more investigation on the "sign-up" flows that result in accidental site creation. Every Atlassian product has a "Get if free" or "Try now" button on their home page, but the page they take you to is slightly different for each, and some are better than others.

The Confluence sign-up is the worst: https://www.atlassian.com/try/cloud/signup?bundle=confluence - this one pre-fills a new site name for you. The Jira one (https://www.atlassian.com/try/cloud/signup?bundle=jira-software) is the same.

However Compass (https://www.atlassian.com/try/cloud/signup?bundle=compass) and Loom (https://www.atlassian.com/try/cloud/signup?bundle=loom) do it right. For me at least, they pre-fill the "site" text box with our existing site, and make it non-editable. There is a small "Start new site" link, but users are unlikely to click that accidentally.

If Atlassian could just change the Confluence and Jira sign-up pages to work like the Compass/Loom ones then I think most of the problems we're all dealing with would go away.

SUGGESTIONS FOR ATLASSIAN...

Since Atlassian has locked out our ability to block creation behind an "Enterprise" paywall, then How about improving TWO THINGS: (1) The  ability to DELETE the sites, and (2) the Site creation process?

1. Please ADD A WAY to QUICKLY remove the product & site – an EXPEDITED removal process.

• Simply give us multiple confirmation prompts to ensure we know we're deleting the site – and then let us delete it, immediately! (Similar to how a "Product" is deleted.)
  • I understand the need for confirmation-delays, but ~90 days is excessive. 
  • The current deletion process in the “improved” billing experience takes almost 3 months. (The old way took 2 weeks!) Think about that for a second. I have to keep a trouble ticket open for 3 months to track the work on this. I have to show it in my stats for 3 months. I have to keep this on my radar for 3 months. All for a mistaken click from a user.
     

2. During CREATION, the Atlassian system should improve user prompts – Add CONFIRMATIONS.

• Confirm the user's actions with pop-ups/messages to ensure they know what they are doing.
  • Prompts like, “YOU ARE ABOUT TO CREATE A WHOLE NEW SITE…” and “YOU ARE ABOUT TO ADD A BILLABLE PRODUCT TO THIS SITE” and a confirmation, "CONFIRM: I AM  AUTHORIZED TO CREATE THIS NEW SITE AND ADD THIS NEW BILLABLE PRODUCT" and "CHECK WITH YOUR ATLASSIAN ADMINISTRATOR BEFORE CONTINUING" !!
  • This would reduce the accidental creations.
    • Every one of the site creations in my organization were created accidentally. This is 100% due to the way the system presents options for our users. The Jira App prompted it or the user wasn’t logged in and so they thought they were clicking into Confluence but they were actually creating a new site.

Respectfully,

Mark

Hi 7c3017d4daee and 7a79c351a973 - in the immortal words of John McClean, "Welcome to the party, pal!"

Unfortunately we mere mortals can't add images to tickets, so Charles, your screenshot is a broken image. But I've written all of this up (with screenshots) here:

https://community.atlassian.com/t5/Questions/Why-is-Atlassian-promoting-Shadow-IT-Or-Accidental-IT/qaq-p/2731538

The irony of this is that Griffin, the poor owner of this ticket, is a Product Manager for Atlassian Access Guard, which, yes, technically if you are on Enterprise Tier, then Access Guard can help prevent this issue.

But as we've made clear in all of our comments, this shouldn't really be put on Access's Guard's (or Griffin's) shoulders. The blame is 100% with whomever owns the Product Pages for Jira and Confluence.

In my follow up post and comment, I found that it looks like the Jira team is attempting to address this issue, looking at session cookies or something to pop-up showing your correct Jira instance if you are already logged in on the main https://atlassian.com page. And more recently, on the Jira product page (https://www.atlassian.com/software/jira), they put a huge box at the top linking to your existing site. Alas, the Confluence product team hasn't figured out how to do this yet. Here's some screenshots:

https://community.atlassian.com/t5/Articles/Proposal-to-prevent-Accidental-Site-Creations-accidentalit/bc-p/2917373#M596

Anyways, maybe that explains why the majority of my accidental site creations are for Confluence, not Jira. (On mobile devices, https://atlassian.com does NOT show the pop-up with your existing site, so that might explain why I'm still getting some accidental Jira sites.)

7a79c351a973 Exactly!  Such an easy fix. 

7c3017d4daee Thanks, that's really helpful.

I just went to https://www.atlassian.com/software/confluence entered my email and hit "Sign Up". This then prompted me to log in via our SAML SSO. After doing that I was presented with a screen prompting me to create a site! However if I go that URL and instead hit "Sign in" (top right) instead of "Sign up" then I just get redirected to our existing site as expected.

It feels like this is the real issue that should be fixed. The "Sign up" flow should revert to the "Sign in" flow once it's identified that the user is part of an existing SSO domain, NOT prompt them to create a new site.

7a79c351a973 it is easy to see why the average user would mess this up.  Either Atlassian are brand dead with their landing page UI design or they are very intentionally trying to get people to do this.  It is MOST confusing on the Google sponsored ad landing pages.  Example here: [Confluence | Your Remote-Friendly Team Workspace | Atlassian|https://www.atlassian.com/software/confluence?gclsrc=aw.ds&&campaign=18312196225&adgroup=138055852541&targetid=aud-2204202926820:kwd-22737151&matchtype=e&network=g&device=c&device_model=&creative=696317320971&keyword=confluence&placement=&target=&ds_eid=700000001542923&ds_e1=GOOGLE&gad_source=1&gclid=Cj0KCQiA1p28BhCBARIsADP9HrPuEoDnluTGoEgn9FeJonDvb1Wn1dhQxfza2iYbgElKde1iyGtZpZsaAr5kEALw_wcB].   They make this look like a SIGN IN page.  Someone enters their email address there and clicks sign up and it IMMEDIATELY spins up one of those new sites.  BRUTAL.  I've tried to identify as many of these URLs as possible and I have added them as an indicator of compromise in Defender to block our users from going to these sites.  The problem is, the URLS change frequently since they are paid ad landing pages so it's an exercise in futility.

Does anyone know exactly how users are managing to accidentally create these sites? The users tell me that they were prompted to do so when logging in somehow, but I haven't been able to replicate it. If Atlassian were able to fix whatever UI flow prompts the users to do this, that would go a long way towards mitigating this issue.

Indeed, no need to upgrade to "paid" site to get a site deleted, just create the ticket on your main site.

During some time I created tickets for multiple sites, but now I create a ticket for each site separately (I have a "template" for this kind of tickets, where I also explain that I don't agree with this practice).

Atlassian must feel how all customers are wasting their time on this stupid and shameful shadow IT practice, which also creates serious security issues!

Darryl Lee - just open a ticket on your main tenant.  We are going to do this every single time a user creates a new site/product.  Atlassian needs to fix this.

1ddde525104a and 7a79c351a973 - Yes, I open a ticket to expedite every time, but as I mentioned briefly, many of these sites are created as free, and there is no way to open a ticket for free sites. So ironically I have to "upgrade" these sites to paid plans before I can file tickets to have their deletions expedited.

27c4fad69a4e - I was told that "soft deletion" of an instance (Jira or Confluence site) will allow deletion of the Organization. This was proven to be true after a recent soft deletion where I was able to then delete the Organization. (Woe to the person who has to try to "undelete" a site after you've deleted the Organization.)

That’s a great point.  We too are considering opening a ticket to expedite every single time this happens.  This is ridiculous.  When we have to waste time on it, Atlassian gets to waste time on it.

I will add my voice of disapproval to the many here. We have users regularly accidentally creating new products/sites. It's such a waste of time and money to chase those up, disable them, wait a couple of months then delete them. Please make this setting available to non-enterprise customers - this is not an "enterprise feature", it's a basic IT governance control.

I'll try raising tickets with Atlassian support to expedite deletion of these every time it happens.

8f4050917dd7 Does this also account for the recent change I keep getting reference of when requesting accidental site deletes?

Unfortunately, there has been a change in our internal processes regarding expedite deletion.
The new process will take 15 days for the soft deletion, during which the instance will no longer be available in your org, but it will take another 30 days after the soft delete for the complete deletion, meaning the total deletion process will take 45 days.

8f4050917dd7 Interesting, I will try this. I did file a support ticket the first time, but it was unsuccessful.

I'll try replicate your steps and see if I can get the sites removed with expedition. 

Still won't fix the underlying issue that it's seems FAR too easy to accidentally create new workspaces connected to our email domain. All three have claimed they tried to log in to Confluence / Jira and accidentally ended up with a new space.

Hi 9f4060b22593 - I certainly don't want to make excuses for Atlassian, but their Support Team has been fairly responsive. It has typically been around a three week process where I have to keep up on tickets and scheduled deletion dates. Here's a recent process from start to finish.

• On 2024-11-26, I discover THREE new sites accidentally created on 2024-11-24 and 2024-11-25.
• Cancel sites (and I upgraded Free sites to Standard Plans so I can specifically select support for the "paid" site) - A recent example: 2024-11-26 
• File a support ticket requesting expedited deletion - I put all 3 sites in one ticket, filed 2024-11-27 - took the day off for Thanksgiving.
• Support will want to confirm that I REALLY WANT TO delete the site and NO I do not want to rename it. - 2024-11-28 - I replied the same morning
• Support will forward the request to the deletion team, and they say the site will be "soft-deleted" in 15 days. (Which is sufficient to be able to delete the organization.) - 2024-12-03 confirmed deletion request was sent. I requested exact date.
• Expected deletion date: 2024-12-18
• I will typically NOT allow resolution of ticket, and if they ask, instead request that the ticket be frozen until expected deletion date.
• Today was the day (2024-12-18). Sites were deleted as promised. I did NOT get any email confirmations about site deletions, nor was the ticket updated (so yes, this is another thing I have to check regularly).
• Deleted Organizations.

So yeah, not 75 days. But still hella annoying.

Came here looking for a solution to the problem, but only met with "Pay for Enterprise and this won't happen"? That's mind boggling!

In the last 2 months, we have had 3 separate users accidentally creating new Confluence workspaces when they meant to log in. It seems disturbingly easy to make this mistake for an unexperienced user.

And to add to it, there's a 75+ DAYS waiting time to fully remove a workspace, even if you act on it within minutes of creation. No words.

I'm thinking this is worthy of a class-action lawsuit. How many of us are paying for guard licenses which have just 'appeared' on our bills because our users accidentally sign up for trials, all the while they (Atlassian) have the capability to prevent it, but ignore it out of greed. Atlassian is not a company that lives by their values.

I'm not gonna point the finger at gjones@atlassian.com, moves like this smells like management/leadership forcing the issue & direct the underlings to gaslight customers with obfuscating claptrap and pass it off as a resolution. 

There is no way a managed user part of an authenticated domain should be allowed to create new product.  We pay for Premium and Guard for exactly that type of governance.

Charitably, this is a huge oversight.

Uncharitably, this feels like a bait-n-switch, shadow IT money grab.

Hi,

Please check this article (and scroll through the long history of posts):

• https://jira.atlassian.com/browse/CLOUD-10325

There are many articles about the same problem, these are just some examples:

• https://jira.atlassian.com/browse/CLOUD-10325
• https://jira.atlassian.com/browse/CLOUD-12089
• https://jira.atlassian.com/browse/ACCESS-1645
• https://jira.atlassian.com/browse/ID-7697
• https://community.atlassian.com/t5/Confluence-questions/SECURITY-ISSUE-during-login-procedure-of-managed-users/qaq-p/2841895
• https://community.atlassian.com/t5/Questions/Why-is-Atlassian-promoting-Shadow-IT-Or-Accidental-IT/qaq-p/2731538
• https://community.atlassian.com/t5/Enterprise-articles/An-update-on-product-requests-bringing-shadow-IT-controls-to/ba-p/2840760
• https://community.atlassian.com/t5/Articles/Proposal-to-prevent-Accidental-Site-Creations-accidentalit/ba-p/2867193#M558

Shame on Atlassian!

They couldn't care less about their customers!

Stefaan

Please make this available for all plans. We have users creating Atlassian Cloud product sites by accident and we can't do anything about it.

There is no development for the standard plan yet as far as I understand.
When will you solve this problem? If daily monitoring is not done because of this situation, it will cost us.
You are especially charging for users under the same domain that was previously set up for trial and not removed.
Please correct this mistake.
Explaining this situation during the renewal period harms your company and the our companie that use it.

This is not a resolution - this is a "solution" that simply brings Trello and Bitbucket into the Enterprise plan money grab.  We have problem "A".  You just solved problem "B."  Thanks for 

This is a disappointing and unacceptable response and is not customer-focused.  It would be one thing if this functionality didn't exist at all, but having it available and choosing to paywall it behind Enterprise goes away from a core Atlassian value: "Dont #@!% the customer"

Here's my vote - This IS unacceptable.  The only reason to reserve this admin functionality to Enterprise is to force orgs to upgrade.  Some people call this a money grab.  It is advantageous to Atlassian to do it this way - 1) It increases the user base and, 2) increases the probability that unwitting users become entrenched and add on paid products or, forces organizations to upgrade to Enterprise.    
As the person that sets the strategy for our organization, this makes me strongly consider other options.  

This is security 101.  Please enable this feature for all.  Do the right thing.

This is very bad business practise, Atlassian team!
It is security flaw what should not even be possible to allow non Admin users to create new instances without any validation and then automatically transfer those new sites under company billing plan. All my users who have created those sites (I'm dealing with a third case on this month) do not even realize what they have done as in their mind, they just logged in and then Jira started to ask some questions they just answered something to get in. To restric this from happening by hiding this under some paywall is cynical and not very professional way to handle this. This should be considered as a bug to be shamed of, not to promote as a paid feature. You are better than this! 

Just a thought - should we open a new JIRA issue since this one is closed?  We might be commenting under the proverbial rug given the issue status.

Just wanted to add my $0.02 that this is absolutely ridiculous. A non administrator managed user shouldn't be able to create any new products or organizations under our account. And certainly paywalling this basic functionality behind the enterprise license is probably the least customer focused decision that Atlassian could make.

If this is bothering you like it is me, see also the following recommended further reading :

1. https://jira.atlassian.com/browse/CLOUD-10325?focusedId=3519823&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-3519823
2. https://community.atlassian.com/t5/Confluence-questions/SECURITY-ISSUE-during-login-procedure-of-managed-users/qaq-p/2841895 
3. https://community.atlassian.com/t5/Questions/Why-is-Atlassian-promoting-Shadow-IT-Or-Accidental-IT/qaq-p/2731538 
4. CLOUD-12089

After 4 site deletions in a few months, it sure seems Atlassian's open door policies allowing licensed users with a claimed domain to go out and create new sites that get billed back to the original is just too convenient.

The provided "solution" is just shuffling off additional manual work to administrators & waste time going through the same mundane & tedious steps: reach out to user that created organization, cancel whatever subscriptions they set up, create a ticket to Atlassian support to DELETE the organization, wait for 2-3 weeks, repeat.

Oh my lord, you guys really put what should be a standard (or at least Premium, what are we paying extra for??) security feature behind the Enterprise paywall?  

I'd say that decision did accomplish one thing, now we know this security 'gap' was architected by Atlassian as an opportunity to collect unintended subscription fees. And their solution to fix the gap is....collecting even higher unintended subscription fees.

What Stefaan said - basic security and organization management for our site should be a function of every Atlassian plan, it's crazy to think that something as basic as this has been throttled to only Enterprise plans.

Being able to control the creation of new organizations/sites/products by managed users must be a standard security feature for every paid product version, otherwise why name the user a managed user?
The standard Atlassian products contain the ability to set permissions on users and groups, but not the ability to block organization/site/product creation by managed users? C'mon!

Also Atlassian is fully aware of this: the "discovered products" function is located under the "Security" menu item, indeed, because it is a security hazard!
Moreover, it can take up to one month before such shadow IT site created by a managed user shows up under “discovered products”, this is completely unacceptable. 

Even worse, the UI design by Atlassian continuously tricks the managed users into creating new organizations/sites/products by accident, especially during login.
Instead, while logging in to the platform, a managed user should be guided towards the organizations/sites/products that he/she has access to.

Any organization that takes security and data protection seriously, cannot allow such practices of guiding the users away from the managed environment.
Any self-respecting organization should also not implement such "features".

More:
https://community.atlassian.com/t5/Confluence-questions/SECURITY-ISSUE-during-login-procedure-of-managed-users/qaq-p/2841895
https://community.atlassian.com/t5/Enterprise-articles/An-update-on-product-requests-bringing-shadow-IT-controls-to/ba-p/2840760

As the one introducing Atlassian products (Confluence and Jira, 800 payed licenses!) in our company and encouraging everyone in our company to use the Atlassian products, I have to comment here and push Atlassian to stop this shadow-IT misuse!
Please Atlassian, we cannot continue like this!!!

gjones@atlassian.com 

This shows how little Atlassian cares about anything other than profit. Every year, they increase their license prices by about 10%, despite having millions of paying users. Meanwhile, there are features that have been requested by thousands—sometimes tens of thousands—of users that remain ignored for years. I remember how long we waited just to get a simple text-highlighting option in Confluence. It's ridiculous.

The lack of this feature is a major issue for our company. It feels like they want to avoid fixing it because they know they might getting new paid users this way, leading to more profit. It's infuriating to think that someone with the power to make a difference is just driven by greed and don't get me started about the "premium" licencing...

gjones@atlassian.com how come it's closed and not possible to vote for when so many customers clearly see this as a huge issue with the product? 

It seems Atlassian will not implement this without enough pressure, so I will do my part to create the pressure by creating support tickets every time a user creates one of those shadow IT sites and request the deletion. I'm really, really tired of stacking piles of falsely created instances.

It's not acceptable that 1) this feature is locked behind the enterprise license, it should be part of the standard license and 2) it takes MONTHS to delete these user errors again.

The fact that this is considered an enterprise 'feature' (which undoubtedly should be considered a BUG fix), is outrageous. Shadow IT systems should under no circumstances ever be allowed to exist in the first place. Why hide this so called 'feature' behind a paywall which fixes something that shouldn't even be allowed to exist in the first place?! 

Just like the people whom commented before me, our users were fully unaware they were creating sites and adding products to it. As ef4a19b077a6 mentioned, it more or less appears that Atlassian is straight up encouraging personnel (which lets not forget, they are ALREADY making a profit from as they are licensed by their company) to spend more money unknowingly and unwillingly on their product, whilst also creating an absolute mess for IT staff to clean-up (as the removal process is a pain to say the least...).

It also concerns me that standard users are able to perform administrative actions which we (as organisation) 'should' have full control over. This has potential to introduce data leaks and privacy concerns as many regular users simply lack certain knowledge on how to properly manage digital landscapes (hence you should divide 'regular' and 'administrative' users for certain actions, site-creation and adding products being two of them).

I truly want to encourage Atlassian to revise their statement and introduce this "BUG" fix to ALL paid license models they provide. Until then this issue has NOT been fixed for the gross majority of people watching this ticket, thus should not be considered as such.

dca798797247, ef4a19b077a6 is on the right track - as I've confirmed this with my users and documented the flow with screenshots here.

As I mentioned over in CLOUD-10325, if Atlassian isn't willing to "give" non-Enterprise users this feature, it would be nice if they addressed the BUG in their sign-in/sign-up process that has managed users (whose org already has existing Jira/Confluence sites) go through a login process and "Welcome" those users, only to essentially trick them into accidentally signing up for new sites, when all they really want to do is log into their existing ones.

I've interviewed several of my users, and they all say they did this by mistake while trying to log in.

This could be fixed if Atlassian redirected users after logging in (who again, it already KNOWS if they have accounts in existing sites) to https://home.atlassian.com/

They need to treat this as a BUG, not a feature request.

So I guess we just open another issue and all pile in there with vitriol again? This is ridiculous.  We use a TON of SaaS tools and this is by far the MOST admin unfriendly stance I've ever seen a SaaS provider take.  Unacceptable.

I'd be curious to understand how Atlassian justifies doing this to paying customers based on their core values.

• "Open company, no bullshit" - Please be open and transparent with us as to why you think this is a feature that paying organizations shouldn't have? Why is this hidden behind "Enterprise"?
• "Build with heart and balance" - I don't think you've "consider[ed] options fully and with care" - unless of course, you've considered it and thought "ehh #@!% 'em I can make more money doing it this way than being decent and helping people who pay to use my platform."
• "Don't #@% the customer" - As the customer, I feel like you're #@%ing me. Everyone on this thread feels that way.
• "Play, as a team" - You guys "spend a huge amount of [your] time at work." So do we, and we'd like to spend less, and if you guys would listen to what we're telling you, instead of milking us for profit, you'd probably agree that this is bull that you don't provide this feature to all of your PAYING customers.
• "Be the change you seek" - "All Atlassians should have the courage and resourcefulness to spark change - TO MAKE BETTER OUR PRODUCTS, OUR PEOPLE, OUR PLACE..." So, is there no one with the courage and resourcefulness to take up the mantel of your PAYING customers to make change to such a foolish and greedy decision?

I guess we'll all just have to sit here and wonder if Atlassian will have the COURAGE to stand up for the customers they are #@%ing over. But don't hold your breath, as we have yet to see any response from Atlassian even acknowledging that there might be some contention over such a #@^ing stupid, greedy decision as this.

You have the capability, you've hidden it behind a paywall, and you refuse to acknowledge that... all the while you pretend like security is important - but only if people are willing to pay EVEN MORE for it.

Yeah not really fixed if this is an Enterprise feature.  We are premium customers so I would expect this to at least be a feature for Premium level subscribers.   

Agreed. Placing a feature designed to prevent costly misuse behind a plan that demands even higher payments is questionable, if not exploitative. We’re not freemium users; we're already paying customers. We need controls to prevent user errors from leading to cost increases or wasted time, especially since the cancellation process is neither quick nor straightforward.

And if you do not change the license to free and recognize it within the first trail period, it becomes a service you have to pay for - meaning you have to add a credit card to get it deleted if trail is already over ... 

Apparently some users access Confluence or Jira by googling and clicking the search results. The link leads to Confluence or Jira product page, where you have a large box with your name "Welcome back, N.N." and some random site name chosen for you and button "Agree and Start now, no credit card required". So dca798797247, I'd say this mess is very much enabled and encouraged by Atlassian.

I currently have two of these sites in the removal process, these keep popping up every now and then, and you cannot get rid of them during the first month. Unbelievable!

Does our Jira / Confluence instances or Atlassian documentation somehow "encourage" users to do this? Any ideas?

This consumes us time to check these instances, data in them, sometimes migrate the data, check who are users, cancel subscription / delete / deactivate the instances, inform the user, communicate afterwards with them...

Users are confused - they are able to create new instance, but then we delete their instances and say to them they shouldn't be doing it.

And in some cases it might lead to the loss of data.

we are also doing a lot of clean. It should be set to default. 

we are also doing a lot of clean up regarding this, please implement this.  This is a BUG

Can we please implement this - one a week I'm cleaning up rogue organisations.

Please solve this case as soon as possible , it is really hard to believe that, Premium accounts do not have this feature . This is very important and annoying for our companies.

+1

This shouldn't be hidden behind the paywall of Atlassian Enterprise Cloud, it should be a default feature of Atlassian Guard.

75ad72bea771 - I'm keeping a spreadsheet, and oof, we've had on average about 1 per week since May. That's when we migrated everyone to Cloud, and apparently new users have a really hard time figuring out how to log into Jira and Confluence and end up creating new sites. I wrote up what I think is causing this problem.

So while yes, they could fix it on the Atlassian Guard side, they could also fix it on the sign-up pages.

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.