Uploaded image for project: 'Identity'
  1. Identity
  2. ID-7697

Prevent managed users from creating cloud site using a verified domain.

    • 335
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Update Oct 15 2024: 

      Hi, we are happy to share some new updates to this ticket in regards to the issue listed:

      • Introduce an option for organization admins to stop managed users from creating additional cloud sites

      The product requests feature, a proactive shadow IT control allowing admins to more centrally manage and prevent new user-created instances across their cloud footprint, 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).

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

            [ID-7697] Prevent managed users from creating cloud site using a verified domain.

            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.

            Michael Cain added a comment - 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.

            Stefaan Vandaele added a comment - 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.

            Maik Paluch added a comment - 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.

            Ali AYDIN added a comment - - edited

            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.

            Ali AYDIN added a comment - - edited 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.

            Tim Makai added a comment -

            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 

            Tim Makai added a comment - 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"

            Chris Rogers added a comment - 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"

            Tim Makai added a comment -

            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.

            Tim Makai added a comment - 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! 

            Indrek Petti added a comment - 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.

            S Alexandre Lemaire added a comment - 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.

            Ben Ruset added a comment -

            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.

            Ben Ruset added a comment - 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.

            tom.hawkins added a comment - If this is bothering you like it is me, see also the following recommended further reading : https://jira.atlassian.com/browse/CLOUD-10325?focusedId=3519823&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-3519823 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   CLOUD-12089    

            Jason M. added a comment -

            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.

            Jason M. added a comment - 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.

            Jason M. added a comment -

            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.

            Jason M. added a comment - 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.

            Joel Calland added a comment - 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

             

            Stefaan Vandaele added a comment - 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 

            Steven Thielemans added a comment - 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...

            david.jares added a comment - 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? 

            Sara Hamberg added a comment - 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.

             

            Conrad Mohr added a comment - 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.  

            nigo added a comment - - edited

            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.

            nigo added a comment - - edited 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.

            Darryl Lee added a comment - 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.

            Scott Dyer added a comment -

            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.

            Scott Dyer added a comment - 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.

            Matt Hulse added a comment - - edited

            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.

            Matt Hulse added a comment - - edited 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.   

            Andrew Hewitson added a comment - 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.

             

            S Alexandre Lemaire added a comment - 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.  

            gjones@atlassian.com this is NOT fixed, please reopen! The suggestion doesn't specify that the prevention need only be available to Premium or Enterprise customers, so until it's available for STANDARD plan customers, it should not be closed please. Did dnguyen4 talk to you about this? Quoting https://community.atlassian.com/t5/Enterprise-articles/An-update-on-product-requests-bringing-shadow-IT-controls-to/bc-p/2840937#M981 "There are many functions where it's understandable why they are only available to Enterprise or Premium level customers, but this is NOT one of them!"  

            tom.hawkins added a comment - gjones@atlassian.com this is NOT fixed, please reopen! The suggestion doesn't specify that the prevention need only be available to Premium or Enterprise customers, so until it's available for STANDARD plan customers, it should not be closed please. Did dnguyen4 talk to you about this? Quoting https://community.atlassian.com/t5/Enterprise-articles/An-update-on-product-requests-bringing-shadow-IT-controls-to/bc-p/2840937#M981 "There are many functions where it's understandable why they are only available to Enterprise or Premium level customers, but this is NOT one of them!"  

            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 ... 

            Benedikt A. added a comment - 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!

            Ismo Haanaho added a comment - 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?

            Nena Kruljac added a comment - 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.

            Nena Kruljac added a comment - 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. 

            Josia Leppert added a comment - 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

            Lisbeth Hedlund added a comment - 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.

            Shane O'Sullivan added a comment - 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.

            sibel.avci@xprclub.com added a comment - 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.

            Byron Galietta added a comment - +1 This shouldn't be hidden behind the paywall of Atlassian Enterprise Cloud, it should be a default feature of Atlassian Guard.

            Darryl Lee added a comment -

            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.

            Darryl Lee added a comment - 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.

            Kevin Kilburg added a comment - 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.

            Peter Fjelsten added a comment - 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 .....

            Lisbeth Hedlund added a comment - 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.

            Claudio Sharkawi added a comment - 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.

            Ali AYDIN added a comment -

            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.

            Ali AYDIN added a comment - 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.

            Scott Dyer added a comment -

            Please Please Please implement this.  the process removing a new org and product that someone has added that shouldn't have is very annoying.

            Scott Dyer added a comment - Please Please Please implement this.  the process removing a new org and product that someone has added that shouldn't have is very annoying.

            Bret Hicks added a comment -

            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.

            Bret Hicks added a comment - 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.

            Matt Hulse added a comment -

            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.

            Matt Hulse added a comment - 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.

            Karri Adkins added a comment - 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.

            Robert Klohr added a comment - 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.

            nigo added a comment -

            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...

             

            nigo added a comment - 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.

            Kacper Obłuski added a comment - 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.

            dave.drexler added a comment - 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

            Michael LEROY added a comment - 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

            Dave Furlani added a comment - 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.

            Luca Rauscher added a comment - 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.

            Michael LEROY added a comment - 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.

            Krapfl, Brett added a comment - 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.

            Chris Andrews added a comment - - edited

            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. 

            Chris Andrews added a comment - - edited 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.

            Léo Boulanger added a comment - 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!!!!!

            Andres Martinez added a comment - 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. 

            Lilach Ben-Altabet added a comment - 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.

            Duarte Meneses added a comment - Users keep creating products by mistake. This should be much easier to manage.

            Rob Horan added a comment -

            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.

            Rob Horan added a comment - 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.

            Joe.Noel added a comment -

            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.

            Joe.Noel added a comment - 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?

            Brian Taylor added a comment - 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 

             

            Mohsin Patel added a comment - 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. 

            Yana Maletska added a comment - 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.

            S Alexandre Lemaire added a comment - 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

             

            Denis Liapin added a comment - 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?

             

            octavian.stanescu added a comment - 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?  

            Bret Hicks added a comment -

            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.

            Bret Hicks added a comment - 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..

            Bartłomiej Borowy added a comment - 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!

            Denis Liapin added a comment - 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!

            tom.hawkins added a comment - 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.

            Andrew Hewitson added a comment - 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/

            Trudy Claspill added a comment - 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. 

            Ben Gallant added a comment - 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. 

            Matt Brown added a comment -

            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.

            Matt Brown added a comment - 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.

             

            Octavian Stanescu added a comment - 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.  

            Van Evans added a comment -

            I have requested this enhancement more than two years ago.  Nothing has changed since.  Although more users are requesting the same feature, Jira has done nothing about it.  It's frustating that this is not on their roadmap but don't hold your breath.

            Van Evans added a comment - I have requested this enhancement more than two years ago.  Nothing has changed since.  Although more users are requesting the same feature, Jira has done nothing about it.  It's frustating that this is not on their roadmap but don't hold your breath.

            I have to add a vote on this as well, my company has sensitive data on many products they are developing that we need to tightly manage, and we don't need users creating "Free" sites to skirt the controls we have in place in order to post content in a product that's "more convenient" to them, and then try to keep this data from inadvertently getting pushed out to the public.

            Yes, there are controls in Confluence to restrict access but all it takes is someone with too much admin privileges and not enough knowledge of the product and its controls to hand sensitive info to the world through "Public sharing" and "Public links".

            This is a major headache for us to monitor on top of our other duties.

            Greg Williams added a comment - I have to add a vote on this as well, my company has sensitive data on many products they are developing that we need to tightly manage, and we don't need users creating "Free" sites to skirt the controls we have in place in order to post content in a product that's "more convenient" to them, and then try to keep this data from inadvertently getting pushed out to the public. Yes, there are controls in Confluence to restrict access but all it takes is someone with too much admin privileges and not enough knowledge of the product and its controls to hand sensitive info to the world through "Public sharing" and "Public links". This is a major headache for us to monitor on top of our other duties.

            There seem to be a bunch of tickets for this feature floating around...this comment was originally seen on CLOUD-10325 but re-posting it to try and get any scrap of attention I can on this:

            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.

            Haddon Fisher added a comment - There seem to be a bunch of tickets for this feature floating around...this comment was originally seen on CLOUD-10325 but re-posting it to try and get any scrap of attention I can on this: 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.

            It's a huge headache (and time-consuming process) to reach out to our users who create rogue instances with our domain. 

            I need to walk them through adding me as an admin, then go through and find out what projects and tasks were created in Jira, any docs in Confluence, all the stuff that they do in there by the time I catch it needs to be transferred to our main instance. 

            Please at least make it easy to move those projects or spaces into our main instance without all of the other steps. That would be awesome. 

            Ben Gallant added a comment - It's a huge headache (and time-consuming process) to reach out to our users who create rogue instances with our domain.  I need to walk them through adding me as an admin, then go through and find out what projects and tasks were created in Jira, any docs in Confluence, all the stuff that they do in there by the time I catch it needs to be transferred to our main instance.  Please at least make it easy to move those projects or spaces into our main instance without all of the other steps. That would be awesome. 

            Ben Z added a comment -

            We've had managed users do this more than once, and resolving it isn't exactly a parade down main street either. 

            Ben Z added a comment - We've had managed users do this more than once, and resolving it isn't exactly a parade down main street either. 

            Welp that's me being dumb. Thanks and sorry 23ef3e30d63c!

            Haddon Fisher added a comment - Welp that's me being dumb. Thanks and sorry 23ef3e30d63c !

            Hi 78a5cd2342f3 this ticket has been reopened since 14/Dec/2023.

            Anusha Rutnam added a comment - Hi 78a5cd2342f3 this ticket has been reopened since 14/Dec/2023.

            Hi 23ef3e30d63c I will reach out to support as well, but this ticket should be reopened because this ask ("Allow admins to prevent creation of new instances using managed domain emails" is not actually covered by CLOUD-11072. That ticket seems only include half-measures and other not-very-useful stuff.

            Haddon Fisher added a comment - Hi 23ef3e30d63c I will reach out to support as well, but this ticket should be reopened because this ask ("Allow admins to prevent creation of new instances using managed domain emails" is not actually covered by CLOUD-11072 . That ticket seems only include half-measures and other not-very-useful stuff.

            Atlassian Update - December 2022

            As per this comment I am closing this ticket.

            If you disagree with the closing of this ticket, please add a comment here saying why and we can reopen it.

            Anusha Rutnam added a comment - Atlassian Update - December 2022 As per this comment I am closing this ticket. If you disagree with the closing of this ticket, please add a comment here saying why and we can reopen it.

            Thanks very much e41fee99e9e9.

            I recommend that watchers of this issue vote on and watch the issue CLOUD-11072 – Allow Administrators to control managed users' associated sites and products which is older and has more votes. So that votes aren't split, I believe this ticket should be closed, but I will wait a week before taking any action in case anyone thinks both issues should continue to exist. Thank you!

            Anusha Rutnam added a comment - Thanks very much e41fee99e9e9 . I recommend that watchers of this issue vote on and watch the issue CLOUD-11072 – Allow Administrators to control managed users' associated sites and products which is older and has more votes. So that votes aren't split, I believe this ticket should be closed, but I will wait a week before taking any action in case anyone thinks both issues should continue to exist. Thank you!

            @Anusha Rutnam That seems to be the same issue yes

            Morten Junker Juul added a comment - @Anusha Rutnam That seems to be the same issue yes

            I believe this issue might be a duplicate of CLOUD-11072 – Allow Administrators to control managed users' associated sites and products. Could the watchers of this issue let me know if they disagree? Thank you.

            Anusha Rutnam added a comment - I believe this issue might be a duplicate of CLOUD-11072 – Allow Administrators to control managed users' associated sites and products . Could the watchers of this issue let me know if they disagree? Thank you.

            Hi all,

            we would like to prevent users that are assigned to our org, of creating new sites, and becoming Org admins to this sites,

            it's a process then to disable and delete those sites.

             

            Boris Zazovsky added a comment - Hi all, we would like to prevent users that are assigned to our org, of creating new sites, and becoming Org admins to this sites, it's a process then to disable and delete those sites.  

            Still don't understand how this is not an implemented feature. Why is it called Atlassian Access if you can't control the access for one of the biggest "moves" that an end-user can make - that is creating a separate cloud site. Anybody can create their own cloud sites within the org without permission - that can get too messy and overhead would be too much to organize. 

            Nijat Behbudov added a comment - Still don't understand how this is not an implemented feature. Why is it called Atlassian Access if you can't control the access for one of the biggest "moves" that an end-user can make - that is creating a separate cloud site. Anybody can create their own cloud sites within the org without permission - that can get too messy and overhead would be too much to organize. 

            Van Evans added a comment -

            Please allow a feature to prevent users from creating cloud site using a our verified domain

            Van Evans added a comment - Please allow a feature to prevent users from creating cloud site using a our verified domain

            Lukasz added a comment -

            Also would love to see this implemented. Thanks!

            Lukasz added a comment - Also would love to see this implemented. Thanks!

            Nas Raja added a comment -

            Kieren, 

            Inability to moderate new product creation on a verified domain is inflating our Atlassian Access bill projections. 

            This is a severe limitation for us in expanding our footprint with-in the Atlassian eco-system. 

            Like others have said on this thread, this should not be considered a feature request but a defect fix in the workflows for new product creation. 

             

            Thanks, 

            Nas Raja 

             

             

             

            Nas Raja added a comment - Kieren,  Inability to moderate new product creation on a verified domain is inflating our Atlassian Access bill projections.  This is a severe limitation for us in expanding our footprint with-in the Atlassian eco-system.  Like others have said on this thread, this should not be considered a feature request but a defect fix in the workflows for new product creation.    Thanks,  Nas Raja       

            selleos added a comment -

            When is this going to be implemented. This should have been rolled out when verified domains was released.

            selleos added a comment - When is this going to be implemented. This should have been rolled out when verified domains was released.

            David Hawn added a comment -

            This should not be considered a feature addition, this should be considered a bug fix. I cannot believe that this is the default behavior and there isn't any mechanism to prevent managed users from spinning up new Atlassian instances.

            David Hawn added a comment - This should not be considered a feature addition, this should be considered a bug fix. I cannot believe that this is the default behavior and there isn't any mechanism to prevent managed users from spinning up new Atlassian instances.

            Kindly implement this control feature for managed users ASAP

            This is increasing unwanted work for Atlassian admins in respective organizations and even for Atlassian cloud support

            Balvant Biradar added a comment - Kindly implement this control feature for managed users ASAP This is increasing unwanted work for Atlassian admins in respective organizations and even for Atlassian cloud support

              gjones@atlassian.com Griffin Jones
              rdey@atlassian.com Ratnarup
              Votes:
              501 Vote for this issue
              Watchers:
              352 Start watching this issue

                Created:
                Updated:
                Resolved: