OH man, I'm sorry e2c1e07fea9d!

So, I don't know if somebody advised me to do this, or if I just got impatient, but I have been filing tickets requesting "Expedited Deletion of Accidentally created Sites" (I'm advocating that we add #accidentalit to help them track these).

There's a required back-and-forth where I have to "CONFIRM" that I REALLY want to delete the sites I put right there in the request and also CONFIRM that I'm not trying to rename any of the sites. (!?)

But after that, support will reach out to the "site deletion team" who will then give you a scheduled date for deletion. The shortest delete date I've gotten has been 14 days after filing a request. Not great, but better than a month!

I track all of this nonsense on an Excel sheet. I was able to delete five orgs today!

8f4050917dd7 within 45 days... They are all marked for deletion, but it takes over a month before they actually drop off.

My user base is 4,000 Atlassian Guard Licenses; with a similar number of Jira and Confluence licenses.. 1,000 JSM and 300 JPD.

12 days sounds nice! I dread those almost daily emails "1 product created outside" hahaha

A quick search of my emails show that he most I've received was "5 products created outside" on 8/27/2024 – but multiple with 4 and 3; countless with 2 and 1. 

Wow e2c1e07fea9d - 29 sites! How recently were those created? What's the size of your userbase?

Not to brag, but personally I'm on a bit of a roll:
 

(Ooof, of course that may change any day. I'm posting daily snapshots here.)

Since this month, many companies in the EU must comply with the NIS2 directive, which has the goal to enhance security practices in EU companies (and their supply chain):

• https://digital-strategy.ec.europa.eu/en/policies/nis2-directive

From next year onwards, digital solutions sold in the EU must comply with the Cyber Resilience Act, which has the goal to enhance security of digital products and solutions provided to companies and consumers:

• https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act

I wonder about the answer from Atlassian for both legislations on this specific subject.

Security shouldn't be a premium feature, prevention beats cleaning up every time. I appreciate Griffin and the team keeping an eye on this ticket but it's very clear that a business decision is forcing us to play janitor instead of actually securing our data.

Attention Atlassian stuff - Sarcasm!
Atlassian Product Management ist getting better and better. Changing request definition to deliver something nobody asked for, but internal statistics are looking good - great job!
Ignoring customer needs and responses is also a proper way to get them to resign and don't create requests anymore as it's useless. So the the number of requests will get reduced - so again, internal statistics are good - great job again!
Just keep going, that is certainly the best way to be successful in the long term - congratulations! I hope you'll receive a bonus payment for this great strategy!

I just wanted to echo a sentiment of Stefaan's. 
Whenever I have reached out to the support team, they have been so helpful and understanding. No matter the issue they have strived to do their absolute best to resolve the issue.

In no way do I believe that the response from this ticket is in line with how the support staff operate. It seems to be the higher ups making decisions at Atlassian that have no clue.

I absolutely adore the Atlassian support staff. Best support of any vendor we use, by far.

Shame on the higher ups to make the whole company image seem so much worse.

Absolutely unacceptable that this continues to be the response. That was the most eloquent "we don't care at all what you want" response that I've ever read. My company spends a small fortune every year paying for Atlassian, only to be ignored over and over on important issues such as this one. You have received so many upset responses about this issue, yet you simply close it, and then double down on closing it? Wow. 

The way things are worded in the October 30th response do not correspond to reality, nor do they correspond to what has been requested by the customers.

This kind of response only shows that (some people at) Atlassian don't give a damn about customer satifaction by offering a good product.

They just want to hide a basic security feature behind a paywall. It is plain extortion: "premium" customers who don't need "enterprise" functions, would have to PAY EXTRA FOR NOT GETTING UNNEEDED, UNWANTED AND INSECURE PRODUCTS from Atlassian.

This guy probably doesn't care, but I feel truly sorry for the helpdesk staff, who are well aware of the magnitude of the problem, and who have to lie to customers on a daily basis. This is a response I received in a ticket after my complaint about the never ending flood of sites created by our MANAGED users:

“Thank you for taking the time to share your concerns with us. I genuinely apologize for any frustration this situation has caused, and I completely understand your standpoint on the importance of robust data protection and security measures, especially given the context of new regulations in the European Union.

Your feedback is incredibly valuable, and I want to assure you that it has been relayed to our internal development teams. While the support team is primarily tasked with facilitating communication and passing on insights from our customers, please know that we are committed to advocating for changes that align with our customers' security needs. I understand the critical nature of meeting industry standards and how essential it is for you to ensure that your organization is protected.

I also realize how disconcerting it must be to feel that a basic security feature is only available under specific plans. I want to emphasize that we, as support teams, are continuously in discussions with our product teams to address these issues and work towards a more secure and compliant experience for all our users based on your feedback and comments.

We are committed to taking your feedback seriously, and it plays a significant role in driving improvements. Thank you for your patience and understanding as we work to address these important issues.”

Absolutely agree with Mike and Kirsta.

gjones@atlassian.com or someone from Atlassian, sorry for my ignorance but do you mind giving me an example on how the IT department of any company, regardless of their subscription tier, can benefit from the existence of a shadow IT?

I completely agree with Krista... gjones@atlassian.com this is a ridiculous response. Yes, you gave us discovery... BUT

1. We are not notified for days... that's days of a potential exposure of data.
2. it's admin overhead and work for no reason other you creating a paywall. Very few people in a large organization have these types of permission. 

What don't you understand? 

I have 29 discovered instances right now... All pending deletion... in what realistic world do you think that's ok? 

Griffin, in response to your update on 30th of October
What a ridiculous response. We never asked for the ability to take over sites; we asked for them to be prevented from being created in the first place!!
Stop moving the goalposts and actually listen to what is being requested.
This is wasting your customer's valuable time. I wonder how many customers have moved to other products due to this? It's absurd to put cyber security behind an enterprise paywall FOR EVERY ATLASSIAN APPLICATION!!
It's not enough that we have an enterprise subscription to JSM and Guard. We can only prevent our users signing up for JSM! Should we really go out and purchase an enterprise subscription for all the products we DON'T USE just to prevent our users signing up for them by mistake??

This " release ‘add admin’ functionality, making the feature more actionable." is not a viable solution. Your reason is extra money from the Enterprise or Atlassian Guard subscription. It's your businesses, you can make that call. But could you at least be honest?

This feels much more like a money move that a "small-to-medium customers don't need this" thing. 

This is in regards to the new October 30th update that just dropped.

"In the last year, the team worked to release ‘add admin’ functionality, making the feature more actionable. Now, an admin can take over the discovered product and determine the appropriate next steps".

Admins do not want the the ability to take over a discovered product, they want the ability to stop people from creating new products. This does not solve the issue that was reported. This just creates more overhead for administrators who have to babysit the discovered product page to see if any new ones showed up.

"We will keep this ticket closed and appreciate your understanding, as well as your time to comment and interact here."

There you have it folks. Atlassian doesn't care and will keep this ticket closed. Hope you enjoy the "solution" they provided, otherwise upgrade to enterprise to get the feature you want.

I don't understand why this is behind a premium/enterprise wall at all. All of these ghost sites cost Atlassian money. Removing all of these things manually also costs time/money for the customer. Its a security nightmare. Surely it would benefit all plans and Atlassian to block these things. If Atlassian really think that unintended subscription fees are really worth hiding this feature behind Enterprise, then they are sinking quite low.

Also of note: When 23ef3e30d63c made her change, she retained the original summary and description as part of the Description. It looked like this:

Original summary and description

"Prevent users under a verified domain for being able to sign up for a new Cloud instance"

Not allow users of a Cloud instance which has the domain already claimed for being able to use their email(verified domain) for sign up to a new Atlassian Cloud instance.

If some user wants to get a new Cloud instance for any reason, it should ask for the instance Administrator.

On 15/Oct/2024 4:41 AM gjones@atlassian.com updated the description to remove that original context.

So I've been getting y'alls recent comments, but looking at the Summary of this ticket today, I had a moment of confusion:

"Allow non-Enterprise administrators to control managed users' associated sites and products"

I mean... they added the ability for regular Atlassian Guard admins to control (become admins) of managed users' sites back in ... Feb 2024. So it sure sounds like they delivered. Good job everyone. Milestone met!

And I was like. Man, so why are we still complaining?

Except... that in the History of this ticket, we can see that on 16/Nov/2023 7:27 PM, 23ef3e30d63c made a change to the Summary, which was originally:

"Prevent users under a verified domain for being able to sign up for a new Cloud instance"

Huh.

Well... I guess if you move the goalposts, it's a lot easier to make that kick.

Anyways. Feeling a little gaslit.

Wow, just wow, this should not be a premium feature, at least other products make it difficult to accidentally create a new site.

ac8ecbf6db22 Must the same people who thought my cafeteria could save money by making the free coffee taste terrible!

A member of Atlassian Support kindly raised CLOUD-12089 for me after my feedback that during the cancellation requests, none of the offered reasons made it clear what the situation was, recommend voting for it so that each cancellation we do adds to the case for a change in decision, I suspect a number of Atlassian users don't regularly use Atlassian's own Jira.  

In the last two days, we have seen the creation of 10 new products outside the organization. Additionally, our users are not aware of this situation. This occurs due to a gap in the process maintained by Atlassian. It seems unreasonable to require an upgrade to the enterprise plan only for this reason.

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.

266372c65f7b at least now, admins can add themselves as admins to the created products and delete them, although there is still a delay before the site is deleted. Definitely an oversight (intentional likely as 27c4fad69a4e states). Same goes with giving guests edit access by default. I'm wondering who makes these design decisions. 

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.

I guess we'll just keep opening PCS-Tickets for each and every site that our users accidentally create.

The Atlassian CEO and CSO should be ashamed of this as a resolution. Any organization that is internally promoting Shadow IT and doesn't prioritize customer data is a risk to do business with. 

It's only a matter of time before data is exposed from the wrong organization and Atlassian is blasted in a lawsuit and our industry... all over trying to make a little extra money. 

What a phenomenally bad and tone-deaf "resolution."

I'm afraid this is a dead (closed) ticket.

I also raised this question:

https://community.atlassian.com/t5/Confluence-questions/SECURITY-ISSUE-during-login-procedure-of-managed-users/qaq-p/2841895

Outrageous that this has been closed, detailing a 'fix' in Enterprise even though the ticket title is for Non-Enterprise - and further doesn't even fix the problem in Enterprise, per 3a86d20e561c 's comments. another vote here for re-opening this ticket - the problem is not solved!

Hi all,

Title of this security issue:

• Allow non-Enterprise administrators to control managed users' associated sites and products

Answer by Atlassian:

• With the Enterprise plan feature product requests, admins can set a policy and then either deny or approve requests for a new user-created instance. This feature is available to customers who have a Jira, Confluence, or Jira Service Management Enterprise plan - and coverage now expands to Trello and Bitbucket (Premium plan, in beta).

Conclusion:

• Atlassian does not care about the security of their Premium customers.

The intention is clearly to trick the managed users of a PREMIUM customer towards the creation of a shadow IT site and to start using it for work related data, outside of the managed organization, disregarding the fact that the CUSTOMER has already paid for the PREMIUM products of Atlassian.

This is definitely BAD INTENTION and a SECURITY ISSUE.

Stefaan

In general, apart from the fact that Atlassian has once again raised the prices of its products, it is ridiculous that the Administrators cannot block new sites that are created from verified domain email addresses.

To bad that Atlassian is a registered CNA - otherwise this would certainly warrant a CVE for allowing unprivileged users to perform a critical operation. Especially when taking 3a86d20e561c's remarks into consideration, that it doesn't even work when the enterprise feature is being used.

gjones@atlassian.com, you haven't 'solved these issues'. Please listen to all the feedback you're getting and reopen this ticket.

Two new products on my Discovered Products list today. One was created four weeks ago, but only appeared on the list today. More pointless admin to get these closed down.

For those saying that the solution is locked behind a paywall, we recently switched to enterprise for Jira. Even this doesn't solve the problem. The 'require admin review' option that comes with enterprise only applies for certain ways that users can create products. See Why can users create products when requests are required? (Which doesn't tell you why users can still do this, just confirms that they can.)

The solution put forth is clearly a middle finger to your premium customers.

Apparently this request is "Closed" now . I spend about 2 hours a weeks doing a clean up job to prevent users from unknowingly creating orgs and products as going against our companies attempt to promote collaboration and transparency to our users.

This functionality DOES THE OPPOSITE of what Atlassian is promoting on its website

• "Plan, track, and deliver your biggest ideas together."
• "Connect and consolidate scattered docs and disconnected teammates in one, central source of truth"
• "align everyone with product roadmaps - all in one single Jira platform."

gjones@atlassian.com please let me as an Admin of a Premium subscription disable allowing new products by going to Atlassian Admin > Security > Product requests (https://admin.atlassian.com/o/[...]/product-requests/settings). I frustratingly see the option, allow me to select it.

We will never double our cost by upgrading to Enterprise ONLY FOR THIS FEATURE. Atlassian is already a nearly impossible sell to our tech procurement because of issues like this.  

Honestly, I don't know what to say as it's not the only issue which is handled like this - it's basic Atlassian philosophy.
Just tell us directly that you don't care about your customers!
Everytime the same sh..! Feature requests have to be created for missing basic functionalities which should be of course logical to be there. Then we wait for ages to get the information that nothing will be changed.
What the hell to we pay money for every month and every year a lot more?!

gjones@atlassian.com Your update from October 15, 2024 does NOT describe a solution to the problem mentioned, which not only customers with an Enterprise plan have, but also those with a Standard plan. This is a serious security issue for all your cloud customers, which cannot be completely prevented with appropriate URL filter rules on a proxy or firewall (remote worker, etc.). This would only be a work-around anyway and not a real solution.
We therefore strongly urge you to reopen this ticket and finally create a suitable solution after more than 7 years!!!

If you have any difficulties in recreating the problem, I can only refer you to the very good and detailed comment by 8f4050917dd7 from October 15, 2024! (Thanks for that, Darryl!)

It is unbelievable that Atlassian is pursuing dubious strategies to drive business at the expense of its customers' security! 

Hi 8f4050917dd7 ,

Thanks. I had missed your comment.
You are right about mobile devices. That was very helpful.

Hi 198a0d57c156 - yes other users like 0b89c650c7a1 have previously posted URLs/patterns to block signups:

• https://admin.atlassian.com/o/create
• https://www.atlassian.com/try
• https://www.atlassian.com/try/*

Which is great, except it's not going to help me block mobile signups, as my users' devices are not managed.

I regret that Atlassian has indicated a willingness not to consider this as an essential security feature for its customers.

An alternative solution must be considered.

Would it be effective to block the trial start URL for each product with an internal proxy? (Except for the organization administrator, who would need to set up a trial site.)

For example, the URL for Confluence trial sign-up is as follows

https://www.atlassian.com/ja/try/cloud/signup

0b89c650c7a1 - I'm sorry I missed you in Barcelona. We should've had a meetup over this issue!

I also talked to a few PMs for Atlassian Guard. And to give some grace to gjones@atlassian.com, I (and they) honestly don't think this is an Atlassian Guard issue, or a feature, or a suggestion.

It's a BUG in the sign-in flow. These instances that have been created by my managed users, all 42 of them - they are NOT Shadow IT. NONE of the users who created these instances intended to stand up their own Confluence or Jira site.

They were created by mistake because of a broken login flow that after properly authenticating a user, they get redirected to a page that displays "Welcome back, Darryl", and presents them with a big blue button to continue, when it really should be redirecting them to https://start.atlassian.com or https://home.atlassian.com or whatever they're calling their central landing page now.

So if a new BUG can be filed about the broken login workflow, I think it should go something like this:

Summary: Broken login workflow when users start on atlassian.com
Steps to reproduce:

• User forgets what the URL of their Jira/Confluence site (CLOUD-6999)
• User types jira, confluence, or atlassian into their web browser/search bar
• User clicks a link to one of the many big blue buttons to "Try now", "Get it free", "Get Confluence free", "Get Jira free"
• User either enters their work email as prompted OR clicks on the tile for their IdP
• User logs IN using their company's IdP, thinking they are on the right track

Expected Results:

• Because Atlassian can see that the user is part of an organization that already has one or SEVERAL existing Jira/Confluence sites, it redirects them to https://home.atlassian.com, where they then choose the correct site.

Actual Results:

• User is redirected to the signup page for Jira or Confluence, where it gives them a comforting "Welcome back, Darryl" message in all bold, tricking them into thinking they are on the correct path
• The "Your site" is pre-filled with a name that contains the organization name: org-team, or because that probably was already accidentally created org-team-randomletters.
• Because site name does contain the name of the organization, the user thinks "Oh yeah, that's right" and clicks the big blue button, ignoring that it says "Agree and start now" because ... sure, they agree. It's probably just usual TOS.
• New site and org is created
• User does NOT end up on the site they were trying to get to

(There's some other things about admins having to clean up this mess, if they even can since w/o Atlassian Guard Standard you can't even do that, but yeah, that's probably sufficient.)

I do have some screenshots documenting this issue here.

Can't believe this ticket has been resolved without any sort of real resolution. Atlassian would rather you have to police the "discovered products" page, join the organization as admin, delete the instance than to lock down the ability for your users to create new products.

Also "With our Atlassian Guard (formerly Atlassian Access) feature automatic product discovery, admins are able to see what user-created instances exist within their cloud footprint, and join these instances to take over control. By doing so, they can remove certain users, products, etc. - and determine the best next steps." is not a real solution. Essentially you're spending time having to clean up organizations and having to wait 14 days for them to be deleted from Atlassian's environment.

Working in a field that handles PII and HIPAA data this is a huge issue. Shame on Atlassian for locking this behind an enterprise paywall. You should be ashamed for the blatant greed.

Request to reopen please.

As others have mentioned, this was not implemented at all. 

For example:

My users can go sign up for a Trello "free trial". Nothing ever indicates to them there will be charges incurred.

These users then become billable under Atlassian Guard. 

"Make a non-billable policy" workaround is not viable. My users still need to login to my JSM portal with SSO to create internal help tickets.

The last line of your resolution mentions:

For further information, please refer to our latest community post: An update on product requests: bringing shadow IT controls to Trello and Bitbucket

That article clearly states controls have been expanded for, "organization admin[s] with Jira, Confluence, and Jira Service Management’s (JSM) Enterprise"

How does this address the title of this request?

 "Allow non-Enterprise administrators to control managed users' associated sites and products"

gjones@atlassian.com "With our Atlassian Guard (formerly Atlassian Access) feature automatic product discovery, admins are able to see what user-created instances exist within their cloud footprint, and join these instances to take over control. By doing so, they can remove certain users, products, etc. - and determine the best next steps."

You're basically letting users create whatever they want, publish data, make it billable, expose it to the internet with the correct clicks, and then 24 to 48 hours LATER inform an admin. 

You've created unnecessary complexity, security vulnerabilities and toil... When all you need to do was block the users from creating the products in the first place. 

ticket resolution contradicts with the title. 

for everyone else URL blocking via firewall does the magic for free  - as per one of the comments earlier

@0b89c650c7a1 They all know... They are not being truthful about it. This is by design to drive sales. I've worked with various Atlassian leadership for over 2 years on this (please see my post from a few months ago). gjones@atlassian.com has made it clear, this is here to stay. 

"Shadow IT product manager (***Griffin) you previously engaged with, and he has confirmed that, unfortunately, we will not be including the shadow IT controls that enable you to block product creation, specifically "Product Requests," in any edition other than enterprise at this time. It's important to recognize that this challenge is not unique to our tool but rather a common occurrence in the software industry, reflecting the growth mindset that all SaaS providers strive to foster."

Strive to foster... code for MORE money for the vendor... NO security for the customer

I was in Team 24 in Barcelona, and literally talked to everyone who worked in Atlassian in each of the product booths about this issue.

No one there seemed to know anything about this issue or know who could address this within Atlassian.   

I saw Mike Cannon-Brookes (Co-Founder and Chief Executive Officer of Atlassian) and regret not asking him directly. 

Gathering interest for 7 years and 749 Votes, what does it take to get this pesky issue fixed!!!!!!!!!!!!!!!!!!!!

Please urgently add this feature.

It is a shame that Atlassian is promoting the use of shadow IT towards the employees of their paying customers.

And it is a pain in the *ss to remove all sites that the users are creating (this week alone: 8 sites!).

Most of the users that created their own orgs and sites don't even know how they did it. 

Right now, out of 18 discovered products only 2 were created voluntarily and only one of them is in use. 

In addition the users who weren't able to understand that they are creating a new site/org now get emails that their data is going to be deleted if they do not log in. they don't understand that they have access to multiple orgs, giving them access to administrative functions and confusing them.

After a well organized and straight forward approach in Confluence DC, the Cloud gives them options they shouldn't see.

+1

There is a switch to disallow managed users from creating Jira projects in the Standard plan, yet the switch to disallow the creation of new instances requires an upgrade to an Enterprise plan. IMO there is no logic to such market segmenting. It really should be the other way around - users are limited to 1 instance in a Standard plan, and my company would have to pay more in order to unlock multiple instances.

Same problem here as for a00469ca237d.
Please make that available soon. That would prevent our users doing stupid things as they don't know what they do and would save me and I guess a lot of other admins a lot of time.
Thanks.

This feature is so important , we are on premium plan, but our users keep creating new sites by mistake , there must be a solution ..

What was in your photo, 09bb9c7a8ac1?

I have a recent photo of my Discovered products page showing 15 sites created in the last two months by MISTAKE by my users. Oh, and ONE which was created in June, but wasn't "discovered" until yesterday, somehow. (I've got a support ticket asking about that...)

I also have a lot of photos of Atlassian's pages which instead of directing already logged in users to the sites that they already have access to, instead shows a nice "Welcome back, Darryl" then encourages them to click a single button to create a new site.

I'm happy to help stir the pot...and I reject your cookies.

I am trying to stir the pot on this. We'll see  (I guess you cannot attach photos here) I emailed premium support

7 years since creation of this suggestion and still nothing...

For those of us who work in organizations that guard HIPAA data, this leads to the possibility of huge HIPAA violations. Anyone could create a product outside the organization and store HIPAA data outside of our protected realm, leading to violation of federal guidelines. Please fix this, Atlassian.

ID-7697 - Prevent managed users from creating cloud site using a verified domain. seems related. 

+1

Seems pretty ridiculous that this safeguard feature is locked behind a hefty enterprise tier paywall. There is no reason any managed account should be able to create a product outside of your organization. This can be dangerous if company information is accidently shared on the newly created product and public links are enabled which essentially circumvents any security measures you have in place on your real organizational product.

Additionally, you have to play babysitter by making yourself an admin of their organization, then you must talk to the employee about not creating products, spend time moving their data off and deleting the organization.

I can't believe that this is not standard. You get into a maintenance hell when using Guard and identity integration.

We need to pay for users in Guard, who are already deleted from the identity provider and who created a free Trello account. We don't have any chance to delete the account or the product.

The domain admin should have control over all products where the domain is used for a user account.

A managed domain account/email address should not be able to create a new Org with products. Yes, I can join as admin & cancel and delete the org, but that takes time and it should not be allowed in the first place.

Brian's comment is the way.

These CLOUD tickets make no reference to the other products Atlassian continues to release - Atlas, JPD... all being spun up and impossible to block or join as admin regardless of Premium vs Enterprise.

If you can, have IT block the URLs Brian listed.

If you can, find a way to automate a monthly or bi-weekly export of the directory to monitor the number of columns exported for the addition of new sites to hunt down for deactivation (and then teach me how because I do it manually).

And although Trello and Bitbucket are mentioned, the user directory export gives 0 information on which site is in use.  So, if you can, make sure you are cross-checking the user list exported from the Bitbucket site your claimed domain owns vs. the Bitbucket active users in your directory export to again, manually, hunt down.  I have searched CLOUD tickets for something requesting this, can't find one but if anyone knows please share.

And I have no idea what to advise about Trello unless you have deep pockets and can just get everyone in to JWM or at least get on Trello Premium.

https://admin.atlassian.com/o/create
https://www.atlassian.com/try
https://www.atlassian.com/try/*

@992b0dfccfdd 
Makes no difference.. Griffin has already made it clear this will NEVER see the light of day. They want you to purchase enterprise.. period. 

The correct way to vote for this issue is to click "Vote for this issue" in the "People" panel (top right). Please do not write "+1" comments – they produce unnecessary notifications for people watching this issue. Atlassian do not use comment count as a measure of popularity.

+1

+1

Atlassian Team, 

Please provide urls and ways, when regular users allowed to create new discovered products. We will try at least block those ULRs by vpn or other tools.

Why you can't disable this feature till providing smart solution for managing it by Org admins? and at least notify about some pilot and ask customers, who need this feature prior pushing it to anyone. 

We need to have this feature because it’s not reasonable for users to be able to do this. Please allow administrators to control managed users’ associated sites and products, or give us the option to block this option to our users as admins.

This needs to be fixed as soon as possible.

This is not an Enterprise feature, but core functionality found in every well-built, secure system i.e., a non-administrator must not be allowed to complete an administrator level task.

As a non-Enterprise customer, you are presented with the "Product request settings" option in the console, but it is disabled. The text linked under 'Product permission' reads:

"You need a Jira Enterprise subscription to be able to review requests for this product."

The text linked under 'Product permission' should read:

"Since you didn't pay for an Enterprise license that you obviously don't need, we decided to disable a core admin and security feature of the product. In addition, we have chosen to frustrate your administrators by showing a feature they can't use, having an open issue where we will openly ignore input and justify the lack of security in the interest of perceived possible future revenue, and finally waste their time by forcing them to manually check and delete unauthorized products creation done by any user in the organization."

But I guess there is not enough room in the module window, so they went with the shorter text.

As Org admins we should be able to manage what users are allowed to do on our tenant. please add this functions asap

I just recieved a potential ray of hope . 

It was suggested that we could create a firewall rule in our 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/*

so users could not create Atlassian organizations themselves and could not open the pages that allow them to start their own site subscriptions.

Please note that such network rule will not block you from adding additional products/sites to your current organization, but will be a blocker should you legitimately require to create another cloud site for your company in a separate Atlassian organization.

Atlassian Support should be able to easily track the amount of time it's own team and it's customers are wasting in this matter. This is terrible of Atlassian to waste so much of it team's and customer's time. 

0b89c650c7a1 I keep hearing that they have no idea how they did it...they never remember. The fact that this doesn't require site/org admin approval is mind boggling, until you learn that it's yet another 'incentive' for us to upgrade past the paywall where all of the good (needed) features are.

And when I tested on mobile when I had previously logged into Jira (so Atlassian "knew who I was"), the path to (accidentally) signing up for a new site was even easier.  

Hey 0b89c650c7a1 - after talking to my users, I believe that it's Atlassian's public-facing pages for the Jira and Confluence that unfortunately make it very easy to do this. I've taken some screenshots of the flow that I believe is leading to this problem: https://shorl.com/homegribrusypry

Can anyone tell me the steps that users are taking to create these products? I am trying to reproduce this myself, but am unable. Something has definitely changed as this was not a problem until the end of last year. 

We should just not pay the extra costs when an accidental site with products is created and make it their problem and not ours.

Since recently, we have had 5 users who coincidentally signed up for their own Atlassian site and product. In one case, even for a Premium subscription, with cost attached. We are using the Atlassian products for years and till now this never happened, so apparently something has changed.

This is highly cumbersome for us: we have Atlassian Guard to find these products, but ending them is a hassle: unsubscribing, waiting for weeks and then removing the organizations.

We want Atlassian to prevent this. We know that it is a feature of the Enterprise subscription, but we feel it is unfair to try and sell an expensive subscription by dragging us into cost and and overhead this way.

I have over 2 years of emails and meetings going back and forth with Atlassian on this issue. I even worked with their Shadow IT team while they were building the solution to block these from being created...

However, to date, it's only a feature for customers on their Enterprise plans.

I have confirmation provided to me today, Friday June 21st 2024, that Atlassian has no plans to extend the feature to non - Enterprise customers.

Here is their email:

I truly appreciate your patience as we delved deeper into this matter internally. I reached out to [*Name removed because I care about privacy and data security; unlike Atlassian*], the Shadow IT product manager you previously engaged with, and he has confirmed that, unfortunately, we will not be including the shadow IT controls that enable you to block product creation, specifically "Product Requests," in any edition other than enterprise at this time. It's important to recognize that this challenge is not unique to our tool but rather a common occurrence in the software industry, reflecting the growth mindset that all SaaS providers strive to foster.

Edit
I noticed that the person's name I removed is on this ticket  

Lets make this clear. This is being allowed because it creates addition revenue streams for Atlassian.
1) those instances of Jira, JSM, Confluence and now JPD eventual can cost money
2) Some companies will be forced into paying the outrageous enterprise prices to secure their data. Certainly, that will be a false hope though. 

"If you have the improved billing experience, you have to wait an additional 60 days after the products are deactivated to delete the organization." 

Seriously Atlassian? Is this a joke!?? 

From: https://support.atlassian.com/organization-administration/docs/remove-domains-and-products-from-your-organization/

Hey everyone! So here's a fun story. Four mistakenly instances that I cancelled on 4/11/24 could still not have their orgs deleted. Support says it was because they were still under the grace period which ... makes no sense if the grace period is 14 days.

Since 4/11/2024, seven more instances were created by mistake. Now this was probably accelerated because we migrated to Cloud on 5/20/2024 and users probably got confused in the login process and BECAUSE ATLASSIAN'S SALES FUNNEL IS SO GOOD, they ended up creating new instances.

So on 6/6/2024 (a week ago) I opened a ticket to request deletion of all of these instances so that I could delete the orgs.

A week later Support gets back to me, and they've scheduled deletion for the 7 new instances (6/24/2024) and the ones from April can FINALLY have their orgs deleted.

Here's the kicker: in the 7 days since I filed the ticket, TWO MORE instances were created.

AND WAIT, it gets better. One of the ones that got created: IT HAS THE SAME NAME AS ONE I JUST DELETED:

companyname-team

Because again, ATLASSIAN'S SALES FUNNEL auto-fills in a name for your new instance and to a user, companyname-team totally makes sense for the name of a Confluence or Jira site. They don't know they're creating a new one. They're just trying to login.

THANKS ATLASSIAN.

https://getsupport.atlassian.com/browse/PCS-286709

oh, here it goes again... one more random user has created an org...

We keep fighting windmills that Atlassian carefully placed,

Navigating complexities, our persistence embraced.

We keep fighting windmills that Atlassian carefully placed,

Crafting pathways to success, no effort should ever be wasted.

We keep fighting windmills that Atlassian carefully placed,

With breached security, our trust is mispaced.

So many customers asked Atlassian!! And you just don't answer or give any hint on this. It's unbelievable. Please write at least a document where you show us what we can do when it happens again.

We have a serious Security Problem without ability to decline users for creating news sites. Very weird feature, where Org Admin of Premium Plan can't remove those sites. I've tried anything:  unsubscribe, archive those sites. But it stay alive and working! 

Stupid situation!!!Unable to render embedded object: File (  Very very BAD) not found. Users continue to create new sites without option to stop it.

ATLASSIAN SUPPORT USELESS in this situation. They also can't figure out those cases.

At least should be option to delete those sites by Org Admin/Billing Admin by support request, ability to manage who from admins can create those sites AND ABILITY to disable this feature at all as harmful on business request.

Please take Priority for this issue!!!

It takes me to catch an email notification that this happened.  Email our PMO and Jira Engineer telling them to check.  They send an email to the people who created new environments.  They ALWAYS responds that they did it BY ACCIDENT.  Jira Engineer then has to go into Atlassian, find each environment and delete them.  RESTRICT NEW ENVIRONMENTS TO ADMINS ONLY BY DOMAIN.  DOI!

blatant disregard for the security.

I have to delete these sites at least once per month! 

FIX IT ASAP

These features should be obvious as admin tools due to security and compliance reasons.
I urge Atlassion to prioritize and plan a release.

https://getsupport.atlassian.com/browse/PCS-288015

This is a pain. Users can apparently create new organizations or sites by accident, and they are slow to be removed, even if they are empty instances.
I get the safeguard to prevent accidental deletion of data, but it should not take this long. Nor should it be this easy to create a new site, for non-administrators.

And it's still on "Gathering Interest", maybe we should buy Enterprise versions of Jira / JSM / Confluence to manage those "new" organizations. Problem will be solved  

I have four sites now outside of my control. How the f*** do I now get rid of them? Thanks Atlassian for creating additional work for me.

The removal of these orgs, which should have not been created in the first place, is also 'so' difficult to do and takes very long.

This needs to be fixed ASAP.

A low-level user just accidentally created a new Premium product on our tenancy incurring additional costs to the business, yet we can't disable this feature. How is this even possible Atlassian!? Massive design flaw. Please fix ASAP.

The removal of these newly created organizations is also a slow and laborious process, adding yet more cost to our business

Some of our users are creating accidentially a new site. This is confusing for our users and makes the overview unclear for our admins. 

• Ability to create new sites for Jira, Confluence, JSD

This option would be really valuable for the Premium version too.

Pasted from JST-989758 Sorry @Shubham, CLOUD-10325 isn’t currently sufficient in my view. IF you were about to address it AND MP-194 then I wouldn’t suggest further changes to this, but given this seems unlikely I think you need to more directly address the design flaws in the current process, (the notifications admins get when receiving requests for apps such as Jira Product Discovery and Compass) DOESN’T have a Reject Request option and needs one B. there’s no justification for differing the ability to reject unwanted addons between tiers in my view (“I don’t object to you offering some more advanced functionality to Premium and Enterprise customers but in cases like this where the things that you’re giving us inferior control over are in my opinion design bugs from Atlassian I strongly suggest you reconsider.”) 

ID-7697 appears to be another version of this issue/request dated from 2021 and owned by an inactive Atlassian user.

This one was created in 2017. No work logged.

Agreeing with all the other people here. This has to be available for all license types. Not every coworker is allowed to do contracts on behalf of the company and the possibility of spoofing the corporate identity is a serious security threat. Having this as an enterprise only feature is like threatening customers to purposefully compromise their security. Simply unacceptable.