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.

It's actually ridiculous that they've put the feature to control this behind the enterprise subscription. We're paying for Guard that lets me know they exist but we have no ability to stop them unless I get Enterprise for both Jira and Confluence? Guard is your security tool so let me use it to make my organization secure. Don't nickle and diming while promoting shadow/accidental IT. Clearly something has changed recently where these accidental orgs are now popping up on a weekly basis. Somehow your team managed to make a problem worse before you make it better. Color me surprised....

I'm glad y'all are having to waste your own cloud resources to create and host all these accidental orgs. I'm now actively seeking alternatives to your products. Thanks.  

+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

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.

As administrators, we require this control for our Jira and Confluence Premium license tiers.  It is very disappointing such a basic control requires an enterprise license at substantially more cost.

Would love to see this feature added for Confluence Premium.

We spend too much time creating accesses and then have to contact users to correct what they've done!

I cannot believe we're still begging for this. It should be a baseline feature.

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!

@Pablo thank you for sharing! This is really useful for dealing with discovered products that users have spun up and finally gives us an easy way to do something about it rather than guiding the user that created the product!

I would still rather the preventative measures that are configurable on Enterprise plans so that we didn't need to do this action after a user has signed up to another product using their managed account.

Ideally the ability to Prevent users from signing up for products will be made available to all Atlassian Access users. Not just Enterprise.

Last week this document was published and it helped me to take control of the products created outside the organization and (most likely) delete them:

https://community.atlassian.com/t5/Atlassian-Access-articles/Take-control-of-unmanaged-products-with-new-enhancements-to/ba-p/2616410

Although I haven't tried to delete yet, but I'm org admin of those products.

This is a lack that can lead to product change.

Company users should have the right to use their corporate accounts to make use of free plans on other Atlassian products, without being considered billable managed accounts. It makes no sense to be asked to upgrade the license of Servicedesk to a higher tier for Trello licenses that are supposed to be free.

Please fix this!

This is the #1 annoyance I have with Atlassian. Please allow premium subscriptions to disable this for users!!! Each time I get notified I contact the user, and they are confused about what they did.

Yes, please add this option for Jira Premium also.

Thank You.

This functionality is VERY NEEDED for Jira Premium.  When can you get this done. 

@Derrick James,  yeah the documentation for this blows, just like everything else for Atlassian.

you need to create a new authentication policy for none IDP managed and non-SSO users  if you have not already  and then change the authentication policy of these other users  to use that.

hope that helps you out. i had to do this for 2k + users.

We are being billed for 75 Atlassian Access users, when we only have 12 JSM users. 

I'm told it's because some employees (that haven't been with the company for years) signed up for a Trello free trial or have access to another company's cloud products. 

I came here from the other closed ticket which provided no solution. It seems it is "as designed" to not help administrators being able to stop users to increase the bills. Very sad indeed.

Hello , We need to have this feature enabled . will be greate

I agree Haddon. This is pretty disappointing. 

I can't imagine that the income gained from these instances is really all that much, and while I acknowledge I have no idea what's going on under the hood, I have to believe this isn't SO much work to implement...so what IS the rationale here?

I get not investing in things like "bulk updating" or "group renaming" to make Jira easier to manage at a day-to-day level...I mean, if Atlassian didn't give us mountains of endless, pointless, and repetitive busywork just to get basic activities accomplished, what would we do all day? However this problem is (as so many others have pointed out) a security risk thing. We spend countless hours and dollars securing and maintaining our corporate instance specifically so Bob in accounting can't accidentally leak PII.

Now I know that Atlassian thinks we're all just vendor-locked at this point and that moving to another tool would be even more painful than putting up with all the garbage they feed us. And you'd be right about that. Today. But it'll be interesting to see what happens when a viable option appears.

'Enhance data security & governance for your Atlassian Cloud products with Atlassian Access' there is even a graphic showing Trello and Bitbucket as a products that will benefit from this enhanced security and governance.... This is marketed to everyone, not just Enterprise customers.

Want to stop 2000 of your managed users from signing up to Trello and increasing your Atlassian Access bill? Tough luck you need to pay for Enterprise.

ACCESS-1468 had votes from ALL ATLASSIAN ACCESS customers who need better control over managed accounts access to products, NOT JUST ENTERPRISE customers.

I don't think Atlassian are so ignorant that they don't already know that this is the case. So personally, I find that the decision to paywall this as an Enterprise only feature, insulting. And something that goes directly against Atlassian core values of 'Don't #@!% the customer'. Also, everyone was pretty excited to see this functionality being worked on and improving so restricting to Enterprise at the last minute doesn't really align with 'Open company, no bullshit'.

If the functionality exists for Enterprise customers now there should be no major technical limitations to enabling this to the rest of the Atlassian Access customers that were marketed a better experience for managing managed users and aren't getting it.