Uploaded image for project: 'Atlassian Cloud'
  1. Atlassian Cloud
  2. CLOUD-10325

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

    • 573
    • 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 30 2024: ** 

      Hi everyone,

      We have been closely monitoring this ticket and would like to take a moment to address your questions and provide the rationale for closing this ticket.

      When we first launched product requests last year, we decided to package this feature as part of the enterprise plan based on our data-backed analysis, which included an analysis of market standards.

      Following this decision, we kept this ticket open to continue to monitor feedback from our small-to-medium customers. The feedback you provided led us to further invest in an Atlassian Guard Standard (formerly Atlassian Access) feature called automatic product discovery.

      In the last year, the team worked to release ‘add admin’ functionality, making the feature more actionable. Now, an admin can take over the discovered product and determine the appropriate next steps. We have a dedicated community post outlining this process here. Automatic product discovery is not limited to the enterprise plan and any customer of any size can purchase as subscription for Atlassian Guard Standard to gain access to this feature.

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

      Griffin

      Update Oct 15 2024: 

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

      • Ability to create new sites for Jira and Confluence
      • Ability to create new Bitbucket or Trello accounts
      • Ability to join sites or products external to the organization
      • Ability to remove managed users from external sites
      • Ability to remove access to specific products

      We have solved these issues through both proactive and reactive controls for user-created instances (also referred to as sites), and an organization admin’s ability to control them.

      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.

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

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

            [CLOUD-10325] Allow non-Enterprise administrators to control managed users' associated sites and products

            Darryl Lee added a comment -

            Thanks to 7a79c351a973 for getting CLOUD-12193 - Reduce occurrences of accidental site creations created. I hope everyone can vote for this Suggestion that is actually addressing the issue of accidental creations.

            Darryl Lee added a comment - Thanks to 7a79c351a973 for getting CLOUD-12193 - Reduce occurrences of accidental site creations created. I hope everyone can vote for this Suggestion that is actually addressing the issue of accidental creations.

            Indrek Petti added a comment - - edited

            Users who are part of managed domain should never ever be able to create new instanced using their company owned email. The sign in process is tricking users to think that they enter to our company site by offering them autofilled instance name which looks too familiar to our exiting site. By the end of the day - there are like regularly one person in a week who creates yet another new instance by mistake without even realising it. And the removal is time consuming and sometimes even not possible as when that license is forced by Atlassian to become free after the trial expires (as no one entered any billing data) - that cancellation option is not there any more. Not sure how this helps Atlassian or us/any other customer facing with this issue as Atlassina is not getting any more money that way but all we have is just a bad publicity and a fustration. 

            Indrek Petti added a comment - - edited Users who are part of managed domain should never ever be able to create new instanced using their company owned email. The sign in process is tricking users to think that they enter to our company site by offering them autofilled instance name which looks too familiar to our exiting site. By the end of the day - there are like regularly one person in a week who creates yet another new instance by mistake without even realising it. And the removal is time consuming and sometimes even not possible as when that license is forced by Atlassian to become free after the trial expires (as no one entered any billing data) - that cancellation option is not there any more. Not sure how this helps Atlassian or us/any other customer facing with this issue as Atlassina is not getting any more money that way but all we have is just a bad publicity and a fustration. 

            SUGGESTION FOR ATLASSIAN...

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

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

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

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

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

            Respectfully,

            Mark

            Mark B Wager added a comment - SUGGESTION FOR ATLASSIAN... Since Atlassian has locked out our ability to block creation behind a paywall, then  How about improving TWO THINGS: (1) The  ability to DELETE the sites, and (2) the Site creation process? 1. Please ADD A WAY to QUICKLY remove the product & site – an EXPEDITED removal process. Simply give us multiple confirmation prompts to ensure we know we're deleting the site – and then let us delete it, immediately! (Similar to how a "Product" is deleted.) I understand the need for confirmation-delays, but ~90 days is excessive.  The current deletion process in the “improved” billing experience  takes almost 3 months. (The old way took 2 weeks!)  Think about that for a second. I have to keep a trouble ticket open for 3 months to track the work on this. I have to show it in my stats for 3 months. I have to keep this on my radar for 3 months. All for a mistaken click from a user.   2. During CREATION, the Atlassian system should improve user prompts  –  Add   CONFIRMATIONS. Confirm the user's actions with pop-ups/messages to ensure they know what they are doing. Prompts like,  “ YOU ARE ABOUT TO CREATE A WHOLE NEW SITE… ” and “ YOU ARE ABOUT TO ADD A BILLABLE PRODUCT TO THIS SITE ” and a confirmation, " CONFIRM: I AM  AUTHORIZED TO CREATE THIS NEW SITE AND ADD THIS NEW BILLABLE PRODUCT " and " CHECK WITH YOUR ATLASSIAN ADMINISTRATOR BEFORE CONTINUING " !! This would reduce the accidental creations. Every one of the site creations in my organization were created accidentally.  This is 100%  due to the way the system presents options for our users . The Jira App prompted it or the user wasn’t logged in and so they thought they were clicking into Confluence but they were actually creating a new site. Respectfully, Mark

            Why is the ability to block site creation locked behind a paywall?

            We have ~1300 employees and I end up with 3-4 sites to delete per month, which I typically forward to your support for expedited deletion as I don't wish to wait the 60+ days. With this, not only are you creating unnecessary work for us as site admins, but you are also creating unnecessary work or your own support agents.

            Please reconsider locking this basic functionality behind a paywall (enterprise-only, no less! https://support.atlassian.com/organization-administration/docs/update-product-request-settings/), allowing our employees to create rogue sites is not going to win you more customers or bring in more revenue, nor is it going to inspire existing customers to upgrade. 

            Thanks for your consideration, and happy 2025!

            Tara Grünewald added a comment - Why is the ability to block site creation locked behind a paywall? We have ~1300 employees and I end up with 3-4 sites to delete per month, which I typically forward to your support for expedited deletion as I don't wish to wait the 60+ days. With this, not only are you creating unnecessary work for us as site admins, but you are also creating unnecessary work or your own support agents. Please reconsider locking this basic functionality behind a paywall (enterprise-only, no less! https://support.atlassian.com/organization-administration/docs/update-product-request-settings/ ), allowing our employees to create rogue sites is not going to win you more customers or bring in more revenue, nor is it going to inspire existing customers to upgrade.  Thanks for your consideration, and happy 2025!

            This is not a real solution, we need to be able to BLOCK, not REACT after the fact.

            Sean Williams added a comment - This is not a real solution, we need to be able to BLOCK, not REACT after the fact.

            Jason M. added a comment - - edited

            Kicking off another delete process for 2 more sites sites that were unintentionally created by users trying to login, after deleting previous 3 sites unintentionally created by users trying to login. This is for a mid-size org of 200-400 employees in a span of 4 months. 

            Strangely enough, never ran into this issue until that recent timeframe. Now it's every other week or two. 

            Atlassian still out here promoting shadow IT & leveraging the diminishing availability of administrators to manage the security/billing vulnerabilities they've created.

            Jason M. added a comment - - edited Kicking off another delete process for 2 more sites sites that were unintentionally created by users trying to login, after deleting previous 3 sites unintentionally created by users trying to login. This is for a mid-size org of 200-400 employees in a span of 4 months.  Strangely enough, never ran into this issue until that recent timeframe. Now it's every other week or two.  Atlassian still out here promoting shadow IT & leveraging the diminishing availability of administrators to manage the security/billing vulnerabilities they've created.

            Agreed 1b46c259bc3c BUT RE: "a +750 vote for this issue can not be taken lightly" absolutely agreed, BUT please note that actually the number of votes to improve this area is MUCH HIGHER, thanks 495ef2a83e74 for collecting up useful links, I'd consider the accurate number of votes for work on this issue to be a sum of the non-duplicates of the 750 from this CLOUD-10325 , the 1611 in https://jira.atlassian.com/browse/ACCESS-1468 and those who've voted on all of the issues linked to it, so likely to be at least 2000 people! 

            PS 8f4050917dd7 LOL at your Simpsons meme. 

            tom.hawkins added a comment - Agreed 1b46c259bc3c BUT RE: "a +750 vote for this issue can not be taken lightly" absolutely agreed, BUT please note that actually the number of votes to improve this area is MUCH HIGHER, thanks 495ef2a83e74 for collecting up useful links, I'd consider the accurate number of votes for work on this issue to be a sum of the non-duplicates of the 750 from this CLOUD-10325 , the 1611 in https://jira.atlassian.com/browse/ACCESS-1468 and those who've voted on all of the issues linked to it, so likely to be at least 2000 people!  PS 8f4050917dd7 LOL at your Simpsons meme. 

            the "solution" is not a solution as it's reactive for most of the customers (it's only proactive for Enterprise customers). Why is it that difficult to enable that feature on all subscription-levels ? In our company we already have +65 user-created confluence/Jira instances out of our admin-control. Users are not aware of what they doing as it's a "feature" in the product. Users afterwards want to migrate their custom-created instance back to our global company instance, which takes looooots of unwanted/unscheduled/budgeted IT support/resources. So please take your customers seriously regarding this matter : a +750 vote for this issue can not be taken lightly and it's a real burden for customers to have extra time & money spend to manage shadow-IT imposed by our SaaS solution vendor: SaaS should be a service and not a shadow-IT generating service. So - with sugar on top - RECONSIDER a proper solution !

            Bart Van Belle added a comment - the "solution" is not a solution as it's reactive for most of the customers (it's only proactive for Enterprise customers). Why is it that difficult to enable that feature on all subscription-levels ? In our company we already have +65 user-created confluence/Jira instances out of our admin-control. Users are  not aware of what they doing as it's a " feature" in the product. Users afterwards want to migrate their custom-created instance back to our global company instance, which takes looooots of unwanted/unscheduled/budgeted IT support/resources. So please take your customers  seriously regarding this matter : a +750 vote for this issue can not be taken lightly and it's a real burden for customers to have extra time & money spend to manage shadow-IT imposed by our SaaS solution vendor: SaaS should be a   service and not a  shadow-IT generating service. So - with sugar on top - RECONSIDER a proper solution !

            I find it somewhat ironic that even the product they called "Guard" does not actually "guard" you against this....just tell you it happened, and let you show up after the fact. Users just love it when you show up like the "uncool" parents at the high school party to shut things down.

            Haddon Fisher added a comment - I find it somewhat ironic that even the product they called "Guard" does not  actually "guard" you against this....just tell you it happened, and let you show up after the fact. Users just love it when you show up like the "uncool" parents at the high school party to shut things down.

            As 416840511601 said, this is disappointing and unacceptable.

            Preventing users from creating unsanctioned sites is a core security and data governance + compliance feature.

            Atlassian Guard Standard is already overpriced (around USD 10.000 a year for 300 ppl product tier), and the features in it are close to none though Atlassian's attitude is more like "be thankful they are even there in the first place". To add more shame to the matter, the feature is already developed!

            Atlassian Guard Standard as it is right now should be included for free, and the Enterprise tier should cost half of what they are charging now.

            Boooo Atlassian!

            Leonardo Bertolo added a comment - As 416840511601 said, this is disappointing and unacceptable. Preventing users from creating unsanctioned sites is a core security and data governance + compliance feature. Atlassian Guard Standard is already overpriced (around USD 10.000 a year for 300 ppl product tier), and the features in it are close to none though Atlassian's attitude is more like "be thankful they are even there in the first place". To add more shame to the matter, the feature is already developed! Atlassian Guard Standard as it is right now should be included for free, and the Enterprise tier should cost half of what they are charging now. Boooo Atlassian!

            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"

            Hi,

            This week I got contacted by our "customer success manager" of Atlassian. I explained that this is the most important problem that we currently have (along with users starting trials for addons) and that any further discussion about other topics makes no sense.

            We have to take every opportunity to bring this to the attention of Atlassian:

            • Keep posting comments on the different articles and feature request, even the ones that have been closed
            • Keep creating a support ticket for every site that has been created by a user
            • Keep filling in customer surveys and express your disagreement with the practices of Atlassian
            • Keep warning Atlassian that this cannot continue: our organization will stop tolerating this in the near future
            • Keep asking Atlassian about compliance of their products with recent and upcoming regulations (in the EU: NIS2, CRA...)

            Thanks,

            Stefaan

            PS: some relevant links:

             

            Stefaan Vandaele added a comment - Hi, This week I got contacted by our "customer success manager" of Atlassian. I explained that this is the most important problem that we currently have (along with users starting trials for addons) and that any further discussion about other topics makes no sense. We have to take every opportunity to bring this to the attention of Atlassian: Keep posting comments on the different articles and feature request, even the ones that have been closed Keep creating a support ticket for every site that has been created by a user Keep filling in customer surveys and express your disagreement with the practices of Atlassian Keep warning Atlassian that this cannot continue: our organization will stop tolerating this in the near future Keep asking Atlassian about compliance of their products with recent and upcoming regulations (in the EU: NIS2, CRA...) Thanks, Stefaan PS: some relevant links: https://jira.atlassian.com/browse/CLOUD-10325 https://jira.atlassian.com/browse/CLOUD-12089 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/Confluence-questions/SECURITY-ISSUE-during-login-procedure-of-managed-users/qaq-p/2841895 https://community.atlassian.com/t5/Articles/Proposal-to-prevent-Accidental-Site-Creations-accidentalit/ba-p/2867193#M558  

            gjones@atlassian.com, as you can see from the comments that are still active, the issue is not over for most people. I would therefore like to ask you to reopen the issue and address it again internally.

            Andree Knoche added a comment - gjones@atlassian.com , as you can see from the comments that are still active, the issue is not over for most people. I would therefore like to ask you to reopen the issue and address it again internally.

            I agree shadow IT is a nightmare I am constantly blocking sites and url that allow users to try or spin up instances. I think this is my biggest issue along with users able to request apps (I want to be able to disable that section for users)

            Charles Gray added a comment - I agree shadow IT is a nightmare I am constantly blocking sites and url that allow users to try or spin up instances. I think this is my biggest issue along with users able to request apps (I want to be able to disable that section for users)

            Jason M. added a comment - - edited

            Have also confirmed they now provide a concrete date when it can be deleted (as part of the support ticket delete process). And there seems to be redirect in the works to serve up a page for existing managed users that allows to choose existing sites.

            But as of last week, I was still initially presented the option to create a new site all too easily when navigating to https://www.atlassian.com/software/jira 

            Upon disregarding the new site request & closing the tab & then navigating back to URL in a new tab, I was presented the page where you can select the existing site. Will see where this goes....!

            Jason M. added a comment - - edited Have also confirmed they now provide a concrete date when it can be deleted (as part of the support ticket delete process). And there seems to be redirect in the works to serve up a page for existing managed users that allows to choose existing sites. But as of last week, I was still initially presented the option to create a new site all too easily when navigating to https://www.atlassian.com/software/jira   Upon disregarding the new site request & closing the tab & then navigating back to URL in a new tab, I was presented the page where you can select the existing site. Will see where this goes....!

            Darryl Lee added a comment -

            If you aren't already creating a support ticket for every deleted site, you should - supposedly they can expedite the process (although hm, it still takes 15 days). 

            At the very least, I get a specific date for when the site is scheduled for deletion, so I have a reminder for when I can delete the associated organization.

            Darryl Lee added a comment - If you aren't already creating a support ticket for every deleted site, you should - supposedly they can expedite the process (although hm, it still takes 15 days).  At the very least, I get a specific date for when the site is scheduled for deletion, so I have a reminder for when I can delete the associated organization.

            495ef2a83e74 taking part in the survey is a great idea; however, for me, these links expired. I would like to propose a more effective approach. Let's create a support ticket for every newly created product outside our organization to permanently remove it. It will impact operational metrics, so they will have to handle this topic sooner or later.

            Tymoteusz Tomaszuk added a comment - 495ef2a83e74 taking part in the survey is a great idea; however, for me, these links expired. I would like to propose a more effective approach. Let's create a support ticket for every newly created product outside our organization to permanently remove it. It will impact operational metrics, so they will have to handle this topic sooner or later.

            "How can Atlassian better support your organization?"

            That is the title of an email from Atlassian, which you have probably also received, containing an invitation to "Share your thoughts in a short 5-7 minute survey".

            I recommend everyone to participate and share your thoughts about Atlassian pushing shadow IT towards the managed users of customers with Jira Premium and Confluence Premium.

            During the survey, there are 3 text boxes where you can type free text. Keep Atlassian informed about your thoughts!

            Stefaan Vandaele added a comment - "How can Atlassian better support your organization?" That is the title of an email from Atlassian, which you have probably also received, containing an invitation to "Share your thoughts in a short 5-7 minute survey". I recommend everyone to participate and share your thoughts about Atlassian pushing shadow IT towards the managed users of customers with Jira Premium and Confluence Premium. During the survey, there are 3 text boxes where you can type free text. Keep Atlassian informed about your thoughts!

            So I have a proposal to fix this that has nothing to do with Atlassian Guard, because to gjones@atlassian.com 's credit, what the vast majority of us are experiencing is not what Atlassian Guard Enterprise was designed prevent.

            What Atlassian needs to fix is the "landing page" experience for existing users. I have some suggestions here.

            Darryl Lee added a comment - So I have a proposal to fix this that has nothing to do with Atlassian Guard, because to gjones@atlassian.com 's credit, what the vast majority of us are experiencing is not what Atlassian Guard Enterprise was designed prevent. What Atlassian needs to fix is the "landing page" experience for existing users. I have some suggestions here .

            Darryl Lee added a comment - - edited

            c05c14d41e50 while I appreciate you wanting to "stick it to the man", one of the reasons I go to the work of shutting down accidentally created sites is because depending on configuration those sites WILL SHOW UP for other users.

            I'm afraid that one of these accidental sites might start being used for REAL WORK or worse still REAL WORK with multiple users.

            And then I might end up in a situation where I have to migrate data from this accidental site to our real site? Ugh, no thanks.

            Darryl Lee added a comment - - edited c05c14d41e50 while I appreciate you wanting to "stick it to the man", one of the reasons I go to the work of shutting down accidentally created sites is because depending on configuration those sites WILL SHOW UP for other users. I'm afraid that one of these accidental sites might start being used for REAL WORK or worse still REAL WORK with multiple users. And then I might end up in a situation where I have to migrate data from this accidental site to our real site? Ugh, no thanks.

            Hi,

            c05c14d41e50 wrote "So as a conclusion for me, i will open a support ticket every time a user is accidentially creating an site and let the Atlassian support clean up the mess until i get some opportunity to prevent users from creating Jira instances without any admin consent."

            You are completely right, we must keep on bringing this to the attention of Atlassian, using all possible means, and make them spend their time on the cleanup work, too! We must also keep posting and creating new bug reports for this issue.

            In the support tickets, always repeat the same information (I even made a "template" ticket for site removal requests!):

            • The site has been created entirely by accident by one of your "managed" users
            • You don't agree with the shadow IT activities of Atlassian towards the managed users of your "premium" subscriptions
            • This is a huge security issue which must be resolved by Atlassian if they want to show any respect for their customers
            • If this continues, you will have no other option than advising AGAINST the further use of any Atlassian tools

            Also make references to some relevant articles:

            Ask for the immediate and permanent deletion of the site.
            And finally, also ask to keep the ticket open until the site has been completely removed (because they like to close tickets before the site has been deleted and when deletion fails you have to start all over again!).

             

            Stefaan Vandaele added a comment - Hi, c05c14d41e50 wrote " So as a conclusion for me, i will open a support ticket every time a user is accidentially creating an site and let the Atlassian support clean up the mess until i get some opportunity to prevent users from creating Jira instances without any admin consent." You are completely right, we must keep on bringing this to the attention of Atlassian, using all possible means, and make them spend their time on the cleanup work, too! We must also keep posting and creating new bug reports for this issue. In the support tickets, always repeat the same information (I even made a "template" ticket for site removal requests!): The site has been created entirely by accident by one of your "managed" users You don't agree with the shadow IT activities of Atlassian towards the managed users of your "premium" subscriptions This is a huge security issue which must be resolved by Atlassian if they want to show any respect for their customers If this continues, you will have no other option than advising AGAINST the further use of any Atlassian tools Also make references to some relevant articles: https://jira.atlassian.com/browse/CLOUD-10325 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://jira.atlassian.com/browse/CLOUD-12089 Ask for the immediate and permanent deletion of the site. And finally, also ask to keep the ticket open until the site has been completely removed (because they like to close tickets before the site has been deleted and when deletion fails you have to start all over again!).  

            That feature is a nightmare for our small team. Cause the new users are flooded with new features and announcements from Atlassian and click on every button they get. And at the end a Jira Instance is created which i could enter as an Admin and cleanup the mess but thats very unfortunate for multiple reasons

            a) i need to wait 2 weeks to delete the product

            b) sometimes it stucks completely

            c) i need to be very carfull to not delete a real instance

            d) its always an amount of hours i need to put into that until i find the right buttons and start the whole procedure

            So as a conclusion for me, i will open a support ticket every time a user is accidentially creating an site and let the Atlassian support clean up the mess until i get some opportunity to prevent users from creating Jira instances without any admin consent.

            Oliver Eckle added a comment - That feature is a nightmare for our small team. Cause the new users are flooded with new features and announcements from Atlassian and click on every button they get. And at the end a Jira Instance is created which i could enter as an Admin and cleanup the mess but thats very unfortunate for multiple reasons a) i need to wait 2 weeks to delete the product b) sometimes it stucks completely c) i need to be very carfull to not delete a real instance d) its always an amount of hours i need to put into that until i find the right buttons and start the whole procedure So as a conclusion for me, i will open a support ticket every time a user is accidentially creating an site and let the Atlassian support clean up the mess until i get some opportunity to prevent users from creating Jira instances without any admin consent.

            872274a04a84 best you can do is open a support ticket to request to delete the sites and organizations. I had a list of 30+ (and growing) organizations that started to annoy me.

             

            I agree with the rest; if you're able to verify the domain and manage the accounts, you should be able to prevent them from creating sites. Hiding this option behind an Enterprise paywall is not acceptable. I also have customers with a smaller user tier complaning about this, for which Enterprise is not fitted at all.

            Patrick van der Rijst added a comment - 872274a04a84 best you can do is open a support ticket to request to delete the sites and organizations. I had a list of 30+ (and growing) organizations that started to annoy me.   I agree with the rest; if you're able to verify the domain and manage the accounts, you should be able to prevent them from creating sites. Hiding this option behind an Enterprise paywall is not acceptable. I also have customers with a smaller user tier complaning about this, for which Enterprise is not fitted at all.

            I have the same problem but not at the same level as some people here.

            The incorrectly created Confluence product has finally been cancelled. I tried to delete the organisation today but I couldn't. After some reading (at [Delete your organization | Atlassian Support|https://support.atlassian.com/organization-administration/docs/delete-your-organization/]) it looks like I now have to wait an additional 60 days before I can delete the organisation. Surely that can't be correct?

            Gerard McHale added a comment - I have the same problem but not at the same level as some people here. The incorrectly created Confluence product has finally been cancelled. I tried to delete the organisation today but I couldn't. After some reading (at [Delete your organization | Atlassian Support|https://support.atlassian.com/organization-administration/docs/delete-your-organization/] ) it looks like I now have to wait an additional 60 days before I can delete the organisation. Surely that can't be correct?

            Stefaan Vandaele added a comment - - edited

            Hi,

            I didn't even know that the situation was different (and even worse) for the customers who don't have Atlassian Guard.

            Let's have a look at the products and the product names:

            • Premium products: the "premium" versions of Jira and Confluence are not cheap. Many companies, like ours, are spending a small fortune on these products! All customers for the so-called “premium” products are expecting those products to be mature and secure, and well suited for professional use.
            • Managed users: the users are "managed" but what does this mean? In my opinion, the company must have control over those users and what they can do or can’t do on the platform. But not for Atlassian! For them, a "managed" user means a user that belongs to a claimed domain, that's all! On the contrary, Atlassian guides our “managed” users away from the “premium” managed environment, and allows (and encourages!) them to subscribe for new products outside of the managed environment! This shadow IT is a major security hazard!
            • Guard: according to the name, this product should guard their customers from a number of things. The first one, and the most obvious one in my opinion, is guarding the company from the above mentioned security hazard that Atlassian is creating for their "premium" customers, who have "managed" users!

            Although obvious for every customer of Atlassian, it seems none of this makes sense for the so-called product managers of Atlassian! Stopping these shadow IT practices and guiding our managed users towards to our managed environment, is basic stuff for any product that deserves the naming premium/managed/guard, and should never be hidden behind an enterprise paywall.

            Atlassian, if you really want to be what you claim to be (a provider of secure and good quality platforms and services), then just act like that by providing value for money! Now you are providing a lot of garbage for “premium” money (a continuous flood of security hazards), and you are asking “enterprise” money for stopping to provide the same garbage? This is not what I understand under “provide value for money”.

            Stefaan

            Stefaan Vandaele added a comment - - edited Hi, I didn't even know that the situation was different (and even worse) for the customers who don't have Atlassian Guard. Let's have a look at the products and the product names: Premium products: the "premium" versions of Jira and Confluence are not cheap. Many companies, like ours, are spending a small fortune on these products! All customers for the so-called “premium” products are expecting those products to be mature and secure, and well suited for professional use. Managed users: the users are "managed" but what does this mean? In my opinion, the company must have control over those users and what they can do or can’t do on the platform. But not for Atlassian! For them, a "managed" user means a user that belongs to a claimed domain, that's all! On the contrary, Atlassian guides our “managed” users away from the “premium” managed environment, and allows (and encourages!) them to subscribe for new products outside of the managed environment! This shadow IT is a major security hazard! Guard : according to the name, this product should guard their customers from a number of things. The first one, and the most obvious one in my opinion, is guarding the company from the above mentioned security hazard that Atlassian is creating for their "premium" customers, who have "managed" users! Although obvious for every customer of Atlassian, it seems none of this makes sense for the so-called product managers of Atlassian! Stopping these shadow IT practices and guiding our managed users towards to our managed environment, is basic stuff for any product that deserves the naming premium/managed/guard, and should never be hidden behind an enterprise paywall. Atlassian, if you really want to be what you claim to be (a provider of secure and good quality platforms and services), then just act like that by providing value for money! Now you are providing a lot of garbage for “premium” money (a continuous flood of security hazards), and you are asking “enterprise” money for stopping to provide the same garbage? This is not what I understand under “provide value for money”. Stefaan

            Steven Rhodes added a comment - - edited

            At least Guard admins can see the products being created by their managed users, and make themselves org admin and delete. Admins without Guard only get an email telling them that one of their users created a product somewhere with a link to buy Guard.

            Its not automatic product discovery we need, its automatic product restriction, and this should be opt-in, not opt-out.

            Steven Rhodes added a comment - - edited At least Guard admins can see the products being created by their managed users, and make themselves org admin and delete. Admins without Guard only get an email telling them that one of their users created a product somewhere with a link to buy Guard. Its not automatic product discovery we need, its automatic product restriction, and this should be opt-in, not opt-out.

            Agree with all comments. The resolution was molded to the easiest option rather than the expected resolution, which i$ already available, a$ long a$ you are willing to pay...

            Shelley Duncan added a comment - Agree with all comments. The resolution was molded to the easiest option rather than the expected resolution, which i$ already available, a$ long a$ you are willing to pay...

            Gah, thought I made it to 13 days, but nope.

            And this was entirely predictable - It's been two days since the expedited deletion request finally went through for roku-team.atlassian.net, which is the site name that Atlassian's broken login/signup workflow suggests for users. It certainly would "look" right to a user just trying to log into OUR EXISTING site, roku.atlassian.net. But nope. Atlassian doesn't check if that's what the LOGGED IN user was trying to get to. Instead it gives them a big blue button to Get Started, and that's what this user did. It would be great if somebody at Atlassian fixed the problem.

            Darryl Lee added a comment - Gah, thought I made it to 13 days , but nope. And this was entirely predictable - It's been two days since the expedited deletion request finally went through for roku-team.atlassian.net , which is the site name that Atlassian's broken login/signup workflow suggests for users . It certainly would "look" right to a user just trying to log into OUR EXISTING site, roku.atlassian.net . But nope. Atlassian doesn't check if that's what the LOGGED IN user was trying to get to. Instead it gives them a big blue button to Get Started, and that's what this user did. It would be great if somebody at Atlassian  fixed the problem.

            The original description has been removed during edits by Atlassian:

            "Prevent users under a verified domain for being able to sign up for a new Cloud instance.
            Not allow users of a Cloud instance which has the domain already claimed for being able to use their email(verified domain) for sign up to a new Atlassian Cloud instance.
            If some user wants to get a new Cloud instance for any reason, it should ask for the instance Administrator."

            The current description does not reflect IN ANY WAY the orginal request.

            Marking the request as "Fixed" is ridiculous.

            Atlassian, how about telling the truth: you are using this flood of accidentally created sites as an extortion scheme to force all customers towards the "enterprise" version.

            Don't forget this is a huge SECURITY HAZZARD! "Managed" users should never be able to create (and start using!) a site outside of the organization! This makes your "premium" products INHERENTLY INSECURE.

            Securing your product, by blocking managed users from creating new sites, IS NOT A FEATURE. Hiding this behind the "enterprise" paywall is plain extortion: "premium" customers who don't need "enterprise" features, have to PAY EXTRA FOR NOT GETTING UNNEEDED, UNWANTED AND INSECURE PRODUCTS from Atlassian? Paying for not getting unwanted stuff is extortion.

            Stefaan Vandaele added a comment - The original description has been removed during edits by Atlassian: "Prevent users under a verified domain for being able to sign up for a new Cloud instance. Not allow users of a Cloud instance which has the domain already claimed for being able to use their email(verified domain) for sign up to a new Atlassian Cloud instance. If some user wants to get a new Cloud instance for any reason, it should ask for the instance Administrator." The current description does not reflect IN ANY WAY the orginal request. Marking the request as "Fixed" is ridiculous. Atlassian, how about telling the truth: you are using this flood of accidentally created sites as an extortion scheme to force all customers towards the "enterprise" version. Don't forget this is a huge SECURITY HAZZARD! " Managed " users should never be able to create (and start using!) a site outside of the organization! This makes your "premium" products INHERENTLY INSECURE . Securing your product, by blocking managed users from creating new sites, IS NOT A FEATURE. Hiding this behind the "enterprise" paywall is plain extortion: "premium" customers who don't need "enterprise" features, have to PAY EXTRA FOR NOT GETTING UNNEEDED, UNWANTED AND INSECURE PRODUCTS from Atlassian? Paying for not getting unwanted stuff is extortion.

            Hey Atlassian! Are you listening? gjones@atlassian.com your most recent update is wildly disingenuous to suggest you've been 'closely monitoring' this thread. Sorry that this might sound personal but hey - you're literally the one making these nonsense updates. 

            "Automatic product discovery is not limited to the enterprise plan and any customer of any size can purchase as subscription for Atlassian Guard Standard to gain access to this feature."

            This is NOT the issue. It never was. The request is to STOP managed users creating sites AT ALL. I cannot - even stretching the benefit of the doubt - see how you and your colleagues cannot see this, since it has been repeated ad nauseam throughout the many tens of comments. As a watcher of this ticket my inbox is currently blowing up with people saying the same thing, so clearly you're aware of what people are saying.

            You haven't fixed it. Stop claiming that you have. Be the cloud provider you claim to be, re-open the ticket due to the clear and obvious customer demand, and just fix the issue. It's clearly not that hard since the prompt to control requests is ALREADY available in the admin section.

            Joe Johnson added a comment - Hey Atlassian! Are you listening? gjones@atlassian.com your most recent update is wildly disingenuous to suggest you've been 'closely monitoring' this thread. Sorry that this might sound personal but hey - you're literally the one making these nonsense updates.  "Automatic product discovery is not limited to the enterprise plan and any customer of any size can purchase as subscription for Atlassian Guard Standard to gain access to this feature." This is NOT the issue. It never was. The request is to STOP managed users creating sites AT ALL. I cannot - even stretching the benefit of the doubt - see how you and your colleagues cannot see this, since it has been repeated ad nauseam throughout the many tens of comments. As a watcher of this ticket my inbox is currently blowing up with people saying the same thing, so clearly you're aware of what people are saying. You haven't fixed it. Stop claiming that you have. Be the cloud provider you claim to be, re-open the ticket due to the clear and obvious customer demand, and just fix the issue. It's clearly not that hard since the prompt to control requests is ALREADY available in the admin section.

            34 (currently) in an instance of 2000 users....

            Yordan Dichev added a comment - 34 (currently) in an instance of 2000 users....

            e2c1e07fea9d : Oh, you beat us there. we have about the same user tier but haven't migrated Jira to the Cloud, yet. But I bet we can beat you there in a few months. 

            Best I had was 5 products, too. 4 of which were created by the same person who was just trying to get into out Confluence instance and had no intend of creating new sites.

            In my eyes this ticket should not be the goal. The goal should be that users don't even stumble into the option to create new sites and orgs. 

            Benjamin Horst added a comment - e2c1e07fea9d : Oh, you beat us there. we have about the same user tier but haven't migrated Jira to the Cloud, yet. But I bet we can beat you there in a few months.  Best I had was 5 products, too. 4 of which were created by the same person who was just trying to get into out Confluence instance and had no intend of creating new sites. In my eyes this ticket should not be the goal. The goal should be that users don't even stumble into the option to create new sites and orgs. 

            Darryl Lee added a comment -

            OH man, I'm sorry e2c1e07fea9d!

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

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

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

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

            Darryl Lee added a comment - OH man, I'm sorry e2c1e07fea9d ! So, I don't know if somebody advised me to do this, or if I just got impatient, but I have been filing tickets requesting "Expedited Deletion of Accidentally created Sites" (I'm advocating that we add #accidentalit to help them track these). There's a required back-and-forth where I have to "CONFIRM" that I REALLY want to delete the sites I put right there in the request and also CONFIRM that I'm not trying to rename any of the sites. (!?) But after that, support will reach out to the "site deletion team" who will then give you a scheduled date for deletion. The shortest delete date I've gotten has been 14 days after filing a request. Not great, but better than a month! I track all of this nonsense on an Excel sheet. I was able to delete five orgs today!

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

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

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

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

            Mike Langlois added a comment - 8f4050917dd7 within 45 days... They are all marked for deletion, but it takes over a month before they actually drop off. My user base is 4,000 Atlassian Guard Licenses; with a similar number of Jira and Confluence licenses.. 1,000 JSM and 300 JPD. 12 days sounds nice! I dread those almost daily emails "1 product created outside" hahaha A quick search of my emails show that he most I've received was "5 products created outside" on 8/27/2024 – but multiple with 4 and 3; countless with 2 and 1. 

            Darryl Lee added a comment -

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

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

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

            Darryl Lee added a comment - Wow e2c1e07fea9d - 29 sites! How recently were those created? What's the size of your userbase? Not to brag, but personally I'm on a bit of a roll:   (Ooof, of course that may change any day. I'm posting daily snapshots here.)

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

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

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

            Stefaan Vandaele added a comment - Since this month, many companies in the EU must comply with the NIS2 directive, which has the goal to enhance security practices in EU companies (and their supply chain): https://digital-strategy.ec.europa.eu/en/policies/nis2-directive From next year onwards, digital solutions sold in the EU must comply with the Cyber Resilience Act, which has the goal to enhance security of digital products and solutions provided to companies and consumers: https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act I wonder about the answer from Atlassian for both legislations on this specific subject.

            Paul Clegg added a comment -

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

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

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

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

            Krista added a comment -

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

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

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

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

            Krista added a comment - I just wanted to echo a sentiment of Stefaan's.  Whenever I have reached out to the support team, they have been so helpful and understanding. No matter the issue they have strived to do their absolute best to resolve the issue. In no way do I believe that the response from this ticket is in line with how the support staff operate. It seems to be the higher ups making decisions at Atlassian that have no clue. I absolutely adore the Atlassian support staff. Best support of any vendor we use, by far. Shame on the higher ups to make the whole company image seem so much worse.

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

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

            Stefaan Vandaele added a comment - - edited

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

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

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

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

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

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

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

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

             

            Stefaan Vandaele added a comment - - edited The way things are worded in the October 30th response do not correspond to reality, nor do they correspond to what has been requested by the customers. This kind of response only shows that (some people at) Atlassian don't give a damn about customer satifaction by offering a good product. They just want to hide a basic security feature behind a paywall. It is plain extortion: "premium" customers who don't need "enterprise" functions, would have to PAY EXTRA FOR NOT GETTING UNNEEDED, UNWANTED AND INSECURE PRODUCTS from Atlassian. This guy probably doesn't care, but I feel truly sorry for the helpdesk staff, who are well aware of the magnitude of the problem, and who have to lie to customers on a daily basis. This is a response I received in a ticket after my complaint about the never ending flood of sites created by our MANAGED users: “Thank you for taking the time to share your concerns with us. I genuinely apologize for any frustration this situation has caused, and I completely understand your standpoint on the importance of robust data protection and security measures, especially given the context of new regulations in the European Union. Your feedback is incredibly valuable, and I want to assure you that it has been relayed to our internal development teams. While the support team is primarily tasked with facilitating communication and passing on insights from our customers, please know that we are committed to advocating for changes that align with our customers' security needs. I understand the critical nature of meeting industry standards and how essential it is for you to ensure that your organization is protected. I also realize how disconcerting it must be to feel that a basic security feature is only available under specific plans. I want to emphasize that we, as support teams, are continuously in discussions with our product teams to address these issues and work towards a more secure and compliant experience for all our users based on your feedback and comments. We are committed to taking your feedback seriously, and it plays a significant role in driving improvements. Thank you for your patience and understanding as we work to address these important issues.”  

            Edward Ho added a comment -

            Absolutely agree with Mike and Kirsta.

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

            Edward Ho added a comment - Absolutely agree with Mike and Kirsta. gjones@atlassian.com or someone from Atlassian, sorry for my ignorance but do you mind giving me an example on how the IT department of any company, regardless of their subscription tier, can benefit from the existence of a shadow IT?

            Mike Langlois added a comment - - edited

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

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

            What don't you understand? 

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

             

            Mike Langlois added a comment - - edited I completely agree with Krista... gjones@atlassian.com this is a ridiculous response. Yes, you gave us discovery... BUT 1. We are not notified for days... that's days of a potential exposure of data. 2. it's admin overhead and work for no reason other you creating a paywall. Very few people in a large organization have these types of permission.  What don't you understand?  I have 29 discovered instances right now... All pending deletion... in what realistic world do you think that's ok?   

            Krista added a comment -

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

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

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

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

            Justine Mathews added a comment - This " release ‘add admin’ functionality, making the feature more actionable." is not a viable solution. Your reason is extra money from the Enterprise or Atlassian Guard subscription. It's your businesses, you can make that call. But could you at least be honest? This feels much more like a money move that a "small-to-medium customers don't need this" thing. 

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

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

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

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

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

            Matt Baillargeon added a comment - This is in regards to the new October 30th update that just dropped. "In the last year, the team worked to release ‘add admin’ functionality, making the feature more actionable. Now, an admin can take over the discovered product and determine the appropriate next steps". Admins do not want the the ability to take over a discovered product, they want the ability to stop people from creating new products. This does not solve the issue that was reported. This just creates more overhead for administrators who have to babysit the discovered product page to see if any new ones showed up. "We will keep this ticket closed and appreciate your understanding, as well as your time to comment and interact here." There you have it folks. Atlassian doesn't care and will keep this ticket closed. Hope you enjoy the "solution" they provided, otherwise upgrade to enterprise to get the feature you want.

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

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

            Darryl Lee added a comment -

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

            Original summary and description

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

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

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

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

            Darryl Lee added a comment - Also of note: When 23ef3e30d63c made her change, she retained the original summary and description as part of the Description . It looked like this: Original summary and description "Prevent users under a verified domain for being able to sign up for a new Cloud instance" Not allow users of a Cloud instance which has the domain already claimed for being able to use their email(verified domain) for sign up to a new Atlassian Cloud instance. If some user wants to get a new Cloud instance for any reason, it should ask for the instance Administrator. On 15/Oct/2024 4:41 AM gjones@atlassian.com updated the description to remove that original context.

            Darryl Lee added a comment -

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

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

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

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

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

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

            Huh.

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

            Anyways. Feeling a little gaslit.

            Darryl Lee added a comment - So I've been getting y'alls recent comments, but looking at the Summary of this ticket today, I had a moment of confusion: "Allow non-Enterprise administrators to control managed users' associated sites and products" I mean... they added the ability for regular Atlassian Guard admins to control (become admins) of managed users' sites back in ... Feb 2024 . So it sure sounds like they delivered. Good job everyone. Milestone met! And I was like. Man, so why are we still complaining? Except... that in the History of this ticket, we can see that on 16/Nov/2023 7:27 PM, 23ef3e30d63c made a change to the Summary , which was originally: "Prevent users under a verified domain for being able to sign up for a new Cloud instance" Huh. Well... I guess if you move the goalposts, it's a lot easier to make that kick. Anyways. Feeling a little gaslit.

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

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

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

            Melanie Truett added a comment - ac8ecbf6db22 Must the same people who thought my cafeteria could save money by making the free coffee taste terrible!

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

             

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

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

            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.

            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. 

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

              gjones@atlassian.com Griffin Jones
              lsanguitam Leonardo Sanguitam (Inactive)
              Votes:
              750 Vote for this issue
              Watchers:
              501 Start watching this issue

                Created:
                Updated:
                Resolved: