Uploaded image for project: 'Atlassian Guard'
  1. Atlassian Guard
  2. ACCESS-1468

Allow Administrators to control managed users' associated sites and products

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

      Atlassian Update - 6 October 2023

      Thank you for your active participation and feedback following our announcement of product requests. We want to address some of the feedback we’ve heard and share our strategy for addressing shadow IT risks now and going forward.
      The Cloud Enterprise (CE) plan solves the challenges of customers operating our products at a large scale by addressing their complexity, governance, advanced security, and compliance needs. The Atlassian Access product solves for more foundational security requirements and provides identity and access management support. We have implemented solutions for shadow IT risks based on customer differentiation in both CE and Atlassian Access.

      The product requests feature will help our CE customers in large, complex environments more closely monitor shadow IT risks as they scale, bolstering our advanced security pillar of CE. For customers with Atlassian Access, we will be adding enhancements to Automatic Product Discovery (APD). The first enhancement is scheduled for release this month and will introduce a new “last active date” field to APD.

      With this enhancement, admins will be able to visit the ‘Discovered Products’ tab within Atlassian Administration and easily identify long inactive shadow IT instances and prioritize recently active ones to take action on. The next APD enhancement will provide org admins with one-click access to ‘join’, or add themselves to, shadow IT instances and take over the management of said instance. 

      In order to track our progress and gain more targeted feedback moving forward, we will now close this ticket and have created separate, linked tickets to address your concerns in smaller forums.

      1. The enhancements to Automatic Product Discovery for the ‘add admin’ feature
      2. The request for product request controls in Trello
      3. The request for product request controls in BitBucket
      4. The ability to remove managed users from external sites

      Best, Griffin

      As an administrator, I would like to have the ability to control and configure permissions to my organization's managed accounts, these permissions are:

      • Ability to create new sites for Jira, Confluence, JSD
      • 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

      Current impact

      Not being able to have these controls allows managed accounts to join or create sites under the company's email domain, possibly causing an undesired increase on the Atlassian Access billing, which in some occasions might hit the license seat limit.

       

            [ACCESS-1468] Allow Administrators to control managed users' associated sites and products

            @Griffin

            What about existing products that are already costing us with unnecessary licensing with Access?

            Adam England added a comment - @Griffin What about existing products that are already costing us with unnecessary licensing with Access?

            Hi everyone,

            We’re excited to share our latest update on this ticket. Since our last post, we’ve made significant progress, and plan to ship the first iteration of this feature this summer.

            In early 2023, we presented our proposed solution, named Product Requests, to our Customer Advisory Board (CAB). Our CAB has highlighted their need to control managed users' and user-generated instances for some time, and we’re happy with our upcoming feature capabilities. Product Requests will give admins the ability to deny new product instances from being spun up through a lightweight ticketing system.

            We plan to ship Product Requests in late summer 2023. Stay tuned for more, and thanks for the feedback and engagement.

            Best,

            Griffin

            Griffin Jones added a comment - Hi everyone, We’re excited to share our latest update on this ticket. Since our last post, we’ve made significant progress, and plan to ship the first iteration of this feature this summer. In early 2023, we presented our proposed solution, named Product Requests, to our Customer Advisory Board (CAB). Our CAB has highlighted their need to control managed users' and user-generated instances for some time, and we’re happy with our upcoming feature capabilities. Product Requests will give admins the ability to deny new product instances from being spun up through a lightweight ticketing system. We plan to ship Product Requests in late summer 2023. Stay tuned for more, and thanks for the feedback and engagement. Best, Griffin

            Atlassian does not understand enterprise support. This is another example.  Frustrating!

            Ravi Radhakrishnan added a comment - Atlassian does not understand enterprise support. This is another example.  Frustrating!

            Thank you both so much. It is ridiculous. I am currently removing products created by people no longer with the company and the hoops you have to jump through are insane. Being admin should mean complete control - not only control over certain things and in other areas users can do what they like!

            lisa.jackson added a comment - Thank you both so much. It is ridiculous. I am currently removing products created by people no longer with the company and the hoops you have to jump through are insane. Being admin should mean complete control - not only control over certain things and in other areas users can do what they like!

            Lisa, I opened a helpdesk request with Atlassian and had them send me an export of the directory. Then I sorted on users that had Trello.

            I then called Atlassian billing and was informed that due to their privacy policy, each individual user must respond and personally ask via email to have your Trello account deleted.

            I emailed them to reply to all on the email for the helpdesk request and ask that thier Trello account be deleted and it worked.

             

            The fact that Atlassian provides no way other that this for administrators or end users to delete their Trello accounts is ridiculous.

             

            Thanks,

             

            Chuck

            Chuck Alexander added a comment - Lisa, I opened a helpdesk request with Atlassian and had them send me an export of the directory. Then I sorted on users that had Trello. I then called Atlassian billing and was informed that due to their privacy policy, each individual user must respond and personally ask via email to have your Trello account deleted. I emailed them to reply to all on the email for the helpdesk request and ask that thier Trello account be deleted and it worked.   The fact that Atlassian provides no way other that this for administrators or end users to delete their Trello accounts is ridiculous.   Thanks,   Chuck

            Lisa, if you're using Atlassian Access, go to https://admin.atlassian.com/ then click on "Directory" and in the "Product access" dropdown, choose "Trello". This will list any users who have signed up to Trello using your managed domain accounts. 

             

            Asher Francis added a comment - Lisa, if you're using Atlassian Access, go to https://admin.atlassian.com/ then click on "Directory" and in the "Product access" dropdown, choose "Trello". This will list any users who have signed up to Trello using your managed domain accounts.   

            How can we see how many Trello accounts are out there created by people with our domains that we manage - why are they not shown with the discovered products?

            lisa.jackson added a comment - How can we see how many Trello accounts are out there created by people with our domains that we manage - why are they not shown with the discovered products?

            Adam Lamb added a comment -

            Really need this feature, it's crazy that we're being asked to pay for Atlassian Access fees for old Trello accounts that are no longer being used! Will we be given a refund for all of the additional Atlassian Access fees we've paid?

            Adam Lamb added a comment - Really need this feature, it's crazy that we're being asked to pay for Atlassian Access fees for old Trello accounts that are no longer being used! Will we be given a refund for all of the additional Atlassian Access fees we've paid?

            Scott Windus added a comment - - edited

            As the Org/Site Admin of my account, it's honestly hard to comprehend that I do not have the ability to block staff in our domain from adding products. We subscribe to Atlassian Access as well, and given the substantial cost of that, it is seriously lacking in functionality and control. Very disappointing that this ticket has been running for 3 years, regardless of the necessity of it. Please Atlassian, stop working on new bells and whistles until you can make the core system do the basics.

            Not having this basic level of control, on an expensive cloud app is like leaving the door to your apartment open, trusting the other building residents won't let themselves in. You wouldn't do it at home, don't force your subscribing org admins to do it with our accounts.

            If you can't practice zero trust.... you are completely out of touch with modern workplace technology and information security and that is just not acceptable. 

            I'm sorry if this sounds harsh, but come one... seriously. Security and administrative control by those of us paying for these tenancies has to take higher priority.

            Scott Windus added a comment - - edited As the Org/Site Admin of my account, it's honestly hard to comprehend that I do not have the ability to block staff in our domain from adding products. We subscribe to Atlassian Access as well, and given the substantial cost of that, it is seriously lacking in functionality and control. Very disappointing that this ticket has been running for 3 years, regardless of the necessity of it. Please Atlassian, stop working on new bells and whistles until you can make the core system do the basics. Not having this basic level of control, on an expensive cloud app is like leaving the door to your apartment open, trusting the other building residents won't let themselves in. You wouldn't do it at home, don't force your subscribing org admins to do it with our accounts. If you can't practice zero trust.... you are completely out of touch with modern workplace technology and information security and that is just not acceptable.  I'm sorry if this sounds harsh, but come one... seriously. Security and administrative control by those of us paying for these tenancies has to take higher priority.

            Tony Chen added a comment -

            Adminssss, where are you? were you sleeping on these product features?

            It's like you have a nice house, nice car, want to show everybody, and brag about it, but you lost the fking key to the house! It's embarrassing. 

            Tony Chen added a comment - Adminssss, where are you? were you sleeping on these product features? It's like you have a nice house, nice car, want to show everybody, and brag about it, but you lost the fking key to the house! It's embarrassing. 

            This issue being left unresolved for so long is costing Atlassian Access users money that shouldn't need to be spent, wasted on the fact we don't have the control we need over our own verified domains.

            David Baverstock added a comment - This issue being left unresolved for so long is costing Atlassian Access users money that shouldn't need to be spent, wasted on the fact we don't have the control we need over our own verified domains.

            This has thrown a massive spanner in the works for my organisation's migration from JSM Server to Cloud. I no longer am confident the migration can proceed with this issue outstanding.

            According to Atlassian's documentation, a user is not considered billable if:

            • "They have a Jira Service Management portal customer account (portal customers who have an Atlassian account are covered by Atlassian Access features, but only agents count as unique billable users)."

            However, if any of my 2,500+ customers (in addition to people who have long left the company) have at any point over the past 4 years decided to sign up for a free Trello account they are inexplicably regarded as billable. This is not clearly articulated in Atlassian's documentation - documentation which me and it would appear, countless others have relied on to inform their migration efforts and budgets.

            Needless to say I was shocked to see hundreds of inactive Trello accounts across my domain regarded as billable users on Atlassian Access with no ability to unlink Trello or manage the accounts without killing access to all Atlassian products (thereby removing customer portal access!)

            How is it possible that a product claiming to provide 'enhanced governance' and 'enterprise-grade access management' can allow any staff member to just create a free Trello account at any time and subsequently result in us getting charged without our knowledge? 

            Consumers have the right to expect certain things when they purchase a product or service. In Australia these rights are protected under consumer law. It is evident in this ticket that Atlassian's marketing around Access does appear to be incongruent with what is actually being provided in the product. It feels misleading.

            Please provide an update on what is happening with this issue.

             

            Karl Herger added a comment - This has thrown a massive spanner in the works for my organisation's migration from JSM Server to Cloud. I no longer am confident the migration can proceed with this issue outstanding. According to Atlassian's documentation , a user is not considered billable if: "They have a Jira Service Management portal customer account (portal customers who have an Atlassian account are covered by Atlassian Access features, but only agents count as unique billable users)." However, if any of my 2,500+ customers (in addition to people who have long left the company) have at any point over the past 4 years decided to sign up for a free Trello account they are inexplicably regarded as billable. This is not clearly articulated in Atlassian's documentation - documentation which me and it would appear, countless others have relied on to inform their migration efforts and budgets. Needless to say I was shocked to see hundreds of inactive Trello accounts across my domain regarded as billable users on Atlassian Access with no ability to unlink Trello or manage the accounts without killing access to all Atlassian products (thereby removing customer portal access!) How is it possible that a product claiming to provide 'enhanced governance' and 'enterprise-grade access management' can allow any staff member to just create a free Trello account at any time and subsequently result in us getting charged without our knowledge?  Consumers have the right to expect certain things when they purchase a product or service. In Australia these rights are protected under consumer law. It is evident in this ticket that Atlassian's marketing around Access does appear to be incongruent with what is actually being provided in the product. It feels misleading. Please provide an update on what is happening with this issue.  

            CJ Edwards added a comment -

            Is this on a roadmap we can see anywhere? this is a huge problem still

             

            CJ Edwards added a comment - Is this on a roadmap we can see anywhere? this is a huge problem still  

            Bump

            jbruijntjes added a comment - Bump

            Bump

            Please prioritize this item! 

            It is very important that our Org Admins be able to control managed users' associated sites and products.

            rebecca.percell added a comment - Please prioritize this item!  It is very important that our Org Admins be able to control managed users' associated sites and products.

            Bump

            attila.balazs added a comment - Bump

            John Tran added a comment -

            Bump.

            John Tran added a comment - Bump.

            This is a serious headache for our organization, we as Org Admins should at least have the ability to delete these...

            Tyler Stephens added a comment - This is a serious headache for our organization, we as Org Admins should at least have the ability to delete these...

            While this is in progress, is there a way to discount users who are added to product sites that are not under our control from Atlassian access charges?

            Ravi Radhakrishnan added a comment - While this is in progress, is there a way to discount users who are added to product sites that are not under our control from Atlassian access charges?

            plz fix k thx bai 

            David T Jones added a comment - plz fix k thx bai 

            We need, please provide it.

            Dibyandu Roy added a comment - We need, please provide it.

            Bump!!

            Remco Haarlemmer added a comment - Bump!!

            Bump this as a priority, please.

            Jeff Gunawan added a comment - Bump this as a priority,  please .

            Same here. We are paiyng for that...

            Carlos Henrique Gremmelmaier added a comment - Same here. We are paiyng for that...

            Big problem for us as well, becoming a nightmare.

            Richard Prigorodon added a comment - Big problem for us as well, becoming a nightmare.

            Greg Roche added a comment -

            This is desperately needed. My organization's users create Jira and Confluence instances without even realizing it. It's a nightmare to get control.  

            Greg Roche added a comment - This is desperately needed. My organization's users create Jira and Confluence instances without even realizing it. It's a nightmare to get control.  

            Adding this summarized response here in addition to feedback provided on CA-2265367. Note that some of this has been altered to be more generalized, more specific details on how this is impacting our organization can be found in the private ticket.

            ...There’s currently a huge gap between what seems like an overstepping sales practice vs. maintaining Enterprise security & governance controls. Some of the comments here call these problems out, although the compliance & controls issues seem to be mixed in with other customers who are frustrated about Trello licensing. Want to make sure that IT controls & compliance concerns are not lost on whoever is working on this issue, which is that users of a corporate-owned domain (@contoso.com for example) are allowed to completely bypass controls & governance in order to spin up new environments within Atlassian on their own in a matter of seconds. This process completely bypasses HIPAA protections and MFA/SSO controls put in place for the corporate-owned domain and happens in a way that administrators who own that domain have zero ability to take control of new sites as they are spun up. The fact that Atlassian acknowledges this in the following article honestly just adds insult to injury: https://support.atlassian.com/organization-administration/docs/what-is-the-impact-of-shadow-it-on-my-organization/

            Atlassian’s sales and product teams have created this provisioning problem, acknowledge its existence, and provide no solution. They are obviously aware of what they are doing, and instead of offering a safe alternative for their Enterprise-grade customers, they instead have continued to acknowledge and promote “shadow IT” provisioning by treating corporate-owned domain email addresses as potential new customers instead of as governed identities...

            Jared Pittman added a comment - Adding this summarized response here in addition to feedback provided on CA-2265367. Note that some of this has been altered to be more generalized, more specific details on how this is impacting our organization can be found in the private ticket. ...There’s currently a huge gap between what seems like an overstepping sales practice vs. maintaining Enterprise security & governance controls. Some of the comments here call these problems out, although the compliance & controls issues seem to be mixed in with other customers who are frustrated about Trello licensing. Want to make sure that IT controls & compliance concerns are not lost on whoever is working on this issue, which is that users of a corporate-owned domain (@contoso.com for example) are allowed to completely bypass controls & governance in order to spin up new environments within Atlassian on their own in a matter of seconds. This process completely bypasses HIPAA protections and MFA/SSO controls put in place for the corporate-owned domain and happens in a way that administrators who own that domain have zero ability to take control of new sites as they are spun up. The fact that Atlassian acknowledges this in the following article honestly just adds insult to injury: https://support.atlassian.com/organization-administration/docs/what-is-the-impact-of-shadow-it-on-my-organization/ Atlassian’s sales and product teams have created this provisioning problem, acknowledge its existence, and provide no solution. They are obviously aware of what they are doing, and instead of offering a safe alternative for their Enterprise-grade customers, they instead have continued to acknowledge and promote “shadow IT” provisioning by treating corporate-owned domain email addresses as potential new customers instead of as governed identities...

            This has been picked up but has been any progress made?

            Alessandro Rosmo added a comment - This has been picked up but has been any progress made?

            Many of our Trello accounts are inactive or for people that have left the company with disabled accounts so are being billed for Access, like others we need a way to controll this so we are only paying for services we are using. We can't depend on users managing this.

            Jeremy Poulter added a comment - Many of our Trello accounts are inactive or for people that have left the company with disabled accounts so are being billed for Access, like others we need a way to controll this so we are only paying for services we are using. We can't depend on users managing this.

            We really need a way to remove Trello users or minimally being able to stop them from signing up and consuming licences unnecessary. if consuming Atlassian licence is necessary for  Trello users, we should be able to have a way to block them from doing so in the first place Without affecting them having other product access to Atlassian (ie: Portal Customer) We are planning to put all users to internal accounts and essentially becoming a managed account, however by doing so we actual lose control for trello (ie: User signing up get an Atlassian licence consumed immediately) This is not an effective way to manage billing. 

            Jesslin Chen added a comment - We really need a way to remove Trello users or minimally being able to stop them from signing up and consuming licences unnecessary. if consuming Atlassian licence is necessary for  Trello users, we should be able to have a way to block them from doing so in the first place Without affecting them having other product access to Atlassian (ie: Portal Customer) We are planning to put all users to internal accounts and essentially becoming a managed account, however by doing so we actual lose control for trello (ie: User signing up get an Atlassian licence consumed immediately) This is not an effective way to manage billing. 

            Yes, please provide an update on this. These additional admin privileges are a necessity. 

            Justin Krynicki added a comment - Yes, please provide an update on this. These additional admin privileges are a necessity. 

            Not sure if this would help, but we've found a 'way' for users to remove themselves from Trello products (from being Access billable users in case they only have access to Trello).

            Here's the guide: Navigate users to remove themselves from Trello (Atlassian Access billing 'issue')

            Tomislav Tobijas added a comment - Not sure if this would help, but we've found a 'way' for users to remove themselves from Trello products (from being Access billable users in case they only have access to Trello). Here's the guide: Navigate users to remove themselves from Trello (Atlassian Access billing 'issue')

            Roberto Martignano added a comment - - edited

            @Hugh Jinhyun Kim you're correct that the only option is to deactivate the user, but you can keep the SSO.

            You have to change the mail address associated to the Trello user, deactivate the user, and create a new brand user (with the same mail) via User Provisioning.

            The workaround I used in similar occasions is:

            • Contact Atlassian so that they can break the SCIM link for the user using Trello (for ex. peter.parker@acme.com)
            • Once the SCIM link is broken, you can now change the mail address of the user (for ex. peter.parker_OLD@acme.com)
            • Deactivate the user 
              • this will deactivate the user associated to Trello
            • On the next User Provisioning a new brand user will be created for peter.parker@acme.com
              • assign Jira/Confluence licenses
              • enable SSO

            This is helpful for brand new Cloud instances, so that you won't have data associated to users.

            Otherwise you should migrate data too (for ex. where the user is Assignee, Reporter, ecc...)

             

            This is far from being easy and smooth, I still can't understand how Atlassian is not aware of this (probably they are).

            Roberto Martignano added a comment - - edited @Hugh Jinhyun Kim you're correct that the only option is to deactivate the user, but you can keep the SSO. You have to change the mail address associated to the Trello user, deactivate the user, and create a new brand user (with the same mail) via User Provisioning. The workaround I used in similar occasions is: Contact Atlassian so that they can break the SCIM link for the user using Trello (for ex. peter.parker@acme.com) Once the SCIM link is broken, you can now change the mail address of the user (for ex. peter.parker_OLD@acme.com) Deactivate the user  this will deactivate the user associated to Trello On the next User Provisioning a new brand user will be created for peter.parker@acme.com assign Jira/Confluence licenses enable SSO This is helpful for brand new Cloud instances, so that you won't have data associated to users. Otherwise you should migrate data too (for ex. where the user is Assignee, Reporter, ecc...)   This is far from being easy and smooth, I still can't understand how Atlassian is not aware of this (probably they are).

            We have users who used Trello free version long before 2021, and admin can't even remove their product on Atlassian Access. It just eats up the bill and do nothing. Users don't even know if they used the Trello.. And the only option is to deactivate. To deactivate I have to remove them from SSO, which defeats the purpose of having Atlassian Access.

            Please have administrators to be able to control products of managed users.

            Hugh Jinhyun Kim added a comment - We have users who used Trello free version long before 2021, and admin can't even remove their product on Atlassian Access. It just eats up the bill and do nothing. Users don't even know if they used the Trello.. And the only option is to deactivate. To deactivate I have to remove them from SSO, which defeats the purpose of having Atlassian Access. Please have administrators to be able to control products of managed users.

            My friends at Atlassian, just adding to the pile again.

            We can't have our users ingest licenses for Atlassian access because they want to trial Trello.  We love the fact that our users have our service portal available on SSO free of any charge, this is incredible and an awesome user experience.

            The issue is that they have a lovely trial experience using Trello on a whim, then a grumpy administrator (me in this case) has to pull them out of Single Sign On so they have yet another password to remember.  They can't even get rid of Trello without me deleting their Atlassian account and re-syncing them with our IDP - what the hell.

            The other alternative is to pivot on your Atlassian Access pricing models, and I don't want to insinuate this but it makes me feel like you are getting your bang for the buck for organizations who blindly agree to thousands of access licenses so they don't have to feed and water this problem.  Globally everywhere is looking at costs and I'm sorry to say this, it's not going to be palatable anymore so please don't just pin a comment from October thinking this will satisfy us that you've got this on your radar.

            Coming from a place of care, every large SaaS provider worth their salt allows checks and balances on this stuff... you're going to get left behind.  Not to mention the glaringly obvious management and data black holes this causes with regulatory groups.

            Adam England added a comment - My friends at Atlassian, just adding to the pile again. We can't have our users ingest licenses for Atlassian access because they want to trial Trello.  We love the fact that our users have our service portal available on SSO free of any charge, this is incredible and an awesome user experience. The issue is that they have a lovely trial experience using Trello on a whim, then a grumpy administrator (me in this case) has to pull them out of Single Sign On so they have yet another password to remember.  They can't even get rid of Trello without me deleting their Atlassian account and re-syncing them with our IDP - what the hell. The other alternative is to pivot on your Atlassian Access pricing models, and I don't want to insinuate this but it makes me feel like you are getting your bang for the buck for organizations who blindly agree to thousands of access licenses so they don't have to feed and water this problem.  Globally everywhere is looking at costs and I'm sorry to say this, it's not going to be palatable anymore so please don't just pin a comment from October thinking this will satisfy us that you've got this on your radar. Coming from a place of care, every large SaaS provider worth their salt allows checks and balances on this stuff... you're going to get left behind.  Not to mention the glaringly obvious management and data black holes this causes with regulatory groups.

            Krista added a comment -

            @Griffin Jones

            Can we at least get some kind of ETA or time frame? This is ridiculous, we haven't heard a peep out of Atlassian since October about this issue. 5 months ago!!
            People comment on this ticket almost daily with their frustrations and yet - nothing.
            This ticket has been open for over three years. That isn't even close to how old some of the tickets I've seen are, which is a very scary thought. How long till this is fixed? 4 years? 5? ....10? 

            Krista added a comment - @Griffin Jones Can we at least get some kind of ETA or time frame? This is ridiculous, we haven't heard a peep out of Atlassian since October about this issue. 5 months ago!! People comment on this ticket almost daily with their frustrations and yet - nothing. This ticket has been open for over three years. That isn't even close to how old some of the tickets I've seen are, which is a very scary thought. How long till this is fixed? 4 years? 5? ....10? 

            Yes - this is a problem - where i found users who no longer work for my company have created their own instances but i have no over-sight or permissions to be able to close it down. 

            I think the ultimate control is that Org Admins must approve the creation of new products/sites.

            Dale Fernandes added a comment - Yes - this is a problem - where i found users who no longer work for my company have created their own instances but i have no over-sight or permissions to be able to close it down.  I think the ultimate control is that Org Admins must approve the creation of new products/sites.

            This issue ticket looks like more a blog than a real tracking issue of a professionnel company.

             

            @atlassian, where should we open the Issue ticket in order to have it taken in charge ?

             

             

            Olivier GRALL added a comment - This issue ticket looks like more a blog than a real tracking issue of a professionnel company.   @atlassian, where should we open the Issue ticket in order to have it taken in charge ?    

            +1 here too, we also have "shadow" sites, we don't want to have. IT should have the full control of the instances - so we want to restrict our Domain-Members so they can't create a instance without permission.

            Viktoria Jechsmayr added a comment - +1 here too, we also have "shadow" sites, we don't want to have. IT should have the full control of the instances - so we want to restrict our Domain-Members so they can't create a instance without permission.

            Jared Pittman added a comment - - edited

            Not being able to restrict the creation of new "shadow IT" sites puts us in a difficult situation, where IT controls & governance are being bypassed for end-user convenience. As a customer who relies on Enterprise licensing for HIPAA compliance & multi-site capabilities, this one setting allows our employees to bypass all of our controls. This is a significant compliance issue, and isn't something Atlassian should just brush under the rug in order to appease their sales team! Please allow us to restrict non-admins from creating new sites in Jira & Confluence. At a minimum pop up a warning that they may be violating company policies by not going through approved channels. As others have repeatedly said, not having control here is hurting your enterprise customers.

            Jared Pittman added a comment - - edited Not being able to restrict the creation of new "shadow IT" sites puts us in a difficult situation, where IT controls & governance are being bypassed for end-user convenience. As a customer who relies on Enterprise licensing for HIPAA compliance & multi-site capabilities, this one setting allows our employees to bypass all of our controls. This is a significant compliance issue, and isn't something Atlassian should just brush under the rug in order to appease their sales team! Please allow us to restrict non-admins from creating new sites in Jira & Confluence. At a minimum pop up a warning that they may be violating company policies by not going through approved channels. As others have repeatedly said, not having control here is hurting your enterprise customers.

            This feature is desperately needed, dare I say it, mandatory for large Enterprise customers. It would be good to provide some timeframes on when it will become available so your customers can adjust their plans accordingly.

            Nathon Fowlie added a comment - This feature is desperately needed, dare I say it, mandatory for large Enterprise customers. It would be good to provide some timeframes on when it will become available so your customers can adjust their plans accordingly.

            Same here. We had close to 20 'bogus' sites also. Again unsecured which was big concern for us. We also found employees using their company email addresses while doing outside contract work at other companies' Jira sites.

            Karen Rogalski added a comment - Same here. We had close to 20 'bogus' sites also. Again unsecured which was big concern for us. We also found employees using their company email addresses while doing outside contract work at other companies' Jira sites.

            +1 here. It appears that our organisation has about 20 "shadow" (external) sites of Jira, Confluence etc.
            This is for us a major concern because of IP-related content, security etc.
            People who set up those sites usually don't have expert knowledge on how to manage and secure their sites.
            This is something that should be left to the IT department.
            We should have the ability to block the possibility to create those external sites. Furthermore it would be welcome if Atlassian displays a message or so forwarding them to the organisation's IT department when someone tries to create a site.

            This needs to be fixed quickly - Thank you. 

            Johan Geens added a comment - +1 here. It appears that our organisation has about 20 "shadow" (external) sites of Jira, Confluence etc. This is for us a major concern because of IP-related content, security etc. People who set up those sites usually don't have expert knowledge on how to manage and secure their sites. This is something that should be left to the IT department. We should have the ability to block the possibility to create those external sites. Furthermore it would be welcome if Atlassian displays a message or so forwarding them to the organisation's IT department when someone tries to create a site. This needs to be fixed quickly - Thank you. 

            Any update when can we expect this!!

            Geetanjali Sharma added a comment - Any update when can we expect this!!

            Do you guys have a potential release date on this yet? I have a customer dealing with an issue as well.

            Jeff Pittman added a comment - Do you guys have a potential release date on this yet? I have a customer dealing with an issue as well.

            WHEN ???

            Ludovic BOYER added a comment - WHEN ???

            Favor providenciar a liberação de podermos através da console, desativar o produto TRELLO e os demais, pois não faz sentido, criarmos um procedimento para solicitar aos usuários que façam este tipo de exclusão.

            Por sermos administradores da console, temos que ter a opção de desativar os produtos dos usuários quando for necessário.

            Aqui na empresa, não é permitido o uso do TRELLO, por determinação da área de Segurança Corporativa.

            Favor, acelerar esta atividade o mais rápido possível, pois isso este provisionamento conta como licença e isso gera custo desnecessário para a nossa organização. Temos no momento 889 acessos que precisam ser desativados com URGÊNCIA.

            Obs.: Comunicados já estão sendo realizados quanto a não utilização do TRELLO com o e-mail corporativo, para que não tenhamos mais casos.

            Alexandre Abreu added a comment - Favor providenciar a liberação de podermos através da console, desativar o produto TRELLO e os demais, pois não faz sentido, criarmos um procedimento para solicitar aos usuários que façam este tipo de exclusão. Por sermos administradores da console, temos que ter a opção de desativar os produtos dos usuários quando for necessário. Aqui na empresa, não é permitido o uso do TRELLO, por determinação da área de Segurança Corporativa. Favor, acelerar esta atividade o mais rápido possível, pois isso este provisionamento conta como licença e isso gera custo desnecessário para a nossa organização. Temos no momento 889 acessos que precisam ser desativados com URGÊNCIA. Obs.: Comunicados já estão sendo realizados quanto a não utilização do TRELLO com o e-mail corporativo, para que não tenhamos mais casos.

            We have found the following workaround: we asked all users whom we detected have a free Trello account to log in and delete all their Trello workspaces (not their account since they cannot delete that). So basically when leaving an empty Trello account with no workspaces seems to count as no Trello product access any more and will stop counting towards Atlassian Access licenses. Maybe this helps someone.

            Adam Public WW Name added a comment - We have found the following workaround: we asked all users whom we detected have a free Trello account to log in and delete all their Trello workspaces (not their account since they cannot delete that). So basically when leaving an empty Trello account with no workspaces seems to count as no Trello product access any more and will stop counting towards Atlassian Access licenses. Maybe this helps someone.

            It's really necessary!!! Please enable ASAP!!!

            Alekya Chillakuru added a comment - It's really necessary!!! Please enable ASAP!!!

            It is also a security risk.

            ddigioia_pdl added a comment - It is also a security risk.

            this feature is needed asap please

            Marquita Pruitt added a comment - this feature is needed asap please

            Manuel Drontmann added a comment - - edited

            So, we are not able to remove users WE manage from external managed sites via access? But we have to pay for them, even if they are only e.g., Jira SM customers who actually do not have a payed license in our internal Environment.

            Manuel Drontmann added a comment - - edited So, we are not able to remove users WE manage from external managed sites via access? But we have to pay for them, even if they are only e.g., Jira SM customers who actually do not have a payed license in our internal Environment.

            Wow, this is a great loophole, a money printing machine! I bet Atlassian Access is the fastest growing product of Atlassian! No one sued you guys for this?

            Adam Public WW Name added a comment - Wow, this is a great loophole, a money printing machine! I bet Atlassian Access is the fastest growing product of Atlassian! No one sued you guys for this?

            Ben Finn added a comment -

            This creates unprofitable churn for everyone. When something like this gets approved and an app starts in our system, we need to track down the people and explain the process which means we shut down the trial. Then Atlassian has left a bad and embarrassing taste in the users mouth so they go elsewhere. 

            Ben Finn added a comment - This creates unprofitable churn for everyone. When something like this gets approved and an app starts in our system, we need to track down the people and explain the process which means we shut down the trial. Then Atlassian has left a bad and embarrassing taste in the users mouth so they go elsewhere. 

            We have deployed Jira Service Management with premium subscription but we have been suprised that we have being be billed for Trello and Bitbucket personal's accounts or free and the IT budget allowed for Atlassian has been exeeded and the Top Management are really upsets !

            Houssemeddine ZAYET added a comment - We have deployed Jira Service Management with premium subscription but we have been suprised that we have being be billed for Trello and Bitbucket personal's accounts or free and the IT budget allowed for Atlassian has been exeeded and the Top Management are really upsets !

            Created 2020. Disappointing to see it took two years to reach in-progress status - An estimated timeframe would be nice. This gap will ultimately kill Atlassian for our company if not closed. 

            Mark Crowle-Groves added a comment - Created 2020. Disappointing to see it took two years to reach in-progress status - An estimated timeframe would be nice. This gap will ultimately kill Atlassian for our company if not closed. 

            It would be enough to give options on which accounts to actually claim in the process. Why would I want to claim Trello accounts from former employees that haven't used the product since 2016 anyway? 

            Julien Schröder added a comment - It would be enough to give options on which accounts to actually claim in the process. Why would I want to claim Trello accounts from former employees that haven't used the product since 2016 anyway? 

            From an org owner I don't care, if a user creates their own organizations. However, there is a problem. We have users (assigned to other policy than non-billable) that are Customers to Service Desk and they can create their OWN orgs with products. That adds to OUR org's billing.

            Therefore, I am not asking to restrict freedom on creating own organizations. If that is your policy that is fine. However, that adds to our billing. So you - Atlassian - do not have right to bill us for users that we have no control over. If you want to leave the freedom that is fine, but do not touch our credit card! 

            Explanations I got from support of admin being informed about user creating a new org - again that is an information past the moment you added to our billing. If we are five people that maybe viable. But we are a 10 per month growing for last 3 years - this is not a sustainable solution. 

            As an admin

            I would like to be asked for an approval before user adds products to our billing

            So I don't need to monitor my billing account and have control over my spendings or have an option to reject it.

            OR

            As an admin

            I would like to know that no user can create an account behind my back (ex. when I am on vacation) 

            So I can have full control over user creation and billing within my own org. 

            FYI - we found this loop hole, and we are resigning from Atlassian Access because of it. We tested and raised it as an issue. After a week we know that there is less work for us not to have Atlassian Access than have it. Ridiculous!!! 

            Rafal Chomicz added a comment - From an org owner I don't care, if a user creates their own organizations. However, there is a problem. We have users (assigned to other policy than non-billable) that are Customers to Service Desk and they can create their OWN orgs with products. That adds to OUR org's billing. Therefore, I am not asking to restrict freedom on creating own organizations. If that is your policy that is fine. However, that adds to our billing. So you - Atlassian - do not have right to bill us for users that we have no control over. If you want to leave the freedom that is fine, but do not touch our credit card!  Explanations I got from support of admin being informed about user creating a new org - again that is an information past the moment you added to our billing. If we are five people that maybe viable. But we are a 10 per month growing for last 3 years - this is not a sustainable solution.  As an admin I would like to be asked for an approval before user adds products to our billing So I don't need to monitor my billing account and have control over my spendings or have an option to reject it. OR As an admin I would like to know that no user can create an account behind my back (ex. when I am on vacation)  So I can have full control over user creation and billing within my own org.  FYI - we found this loop hole, and we are resigning from Atlassian Access because of it. We tested and raised it as an issue. After a week we know that there is less work for us not to have Atlassian Access than have it. Ridiculous!!! 

            Why would Atlassian hurry to fix a problem that is very  profitable to them?    

            I have so many users who sign up for "FREE"  trello.   These users are not getting informed that their company will be charged for Atlassian Access and Atlassian Site administrators are not getting notified when the Atlassian Access bill user base increases  due to users using their company email on non-company endorsed Atlassian products like trello or Bitbucket in my case. 

            The number of "unauthorized" Atlassian Access charges on my bill now surpass the legitimate ones.     This is crazy! 

             

            Adrian Vital added a comment - Why would Atlassian hurry to fix a problem that is very  profitable to them?     I have so many users who sign up for "FREE"  trello.   These users are not getting informed that their company will be charged for Atlassian Access and Atlassian Site administrators are not getting notified when the Atlassian Access bill user base increases  due to users using their company email on non-company endorsed Atlassian products like trello or Bitbucket in my case.  The number of "unauthorized" Atlassian Access charges on my bill now surpass the legitimate ones.     This is crazy!   

            I'd like to join the 992 other people screaming into the void on this thread.

            So, Atlassian's chargeable flagship enterprise access tool, Atlassian Access, doesn't allow enterprises to reliably manage access to Atlassian's products? And hasn't been addressed in 2 1/2 years?

            The product manager for Atlassian Access ought to be pilloried for this.

            kevin.maitland added a comment - I'd like to join the 992 other people screaming into the void on this thread. So, Atlassian's chargeable flagship enterprise access tool, Atlassian Access , doesn't allow enterprises to reliably manage access to Atlassian's products? And hasn't been addressed in 2 1/2 years ? The product manager for Atlassian Access ought to be pilloried for this.

            Manuel Venegas added a comment - https://support.atlassian.com/requests/PCS-148294

            Bruno Souza added a comment - https://getsupport.atlassian.com/browse/PCS-148258

            Are there any updates?

            Hanna Pososhenko added a comment - Are there any updates?

            I have similar issue since one year ago and no acceptable solution has been provided by Atlassian. Bills should reflect what administrators allows or not within a directory, here it's open bar for a end user to try a product and then Atlassian send the bill to the administrators... Atlassian Access billing policies should evolve not to impact Administrators or organization. Easily free products should not be included in Access billing like "non billable policy"

            Anthony Gea added a comment - I have similar issue since one year ago and no acceptable solution has been provided by Atlassian. Bills should reflect what administrators allows or not within a directory, here it's open bar for a end user to try a product and then Atlassian send the bill to the administrators... Atlassian Access billing policies should evolve not to impact Administrators or organization. Easily free products should not be included in Access billing like "non billable policy"

            hticadmin added a comment -

            We have noticed an issue that auto signed users getting added to our ganization and billed for those users. Here we would like to have a feature to bill only those users admin invited similar like Github. Further discussion with Support, I was informed that this feature in consideration and development by this time recomeded to use non billable users policy. When I had a check I noticed we should opt additional service called Atlassian Access and pay for it. I feel like it is not accepatable, we should have some option to control billed users or have provision to add non billable users without any additional cost. Please sreview and support 

            hticadmin added a comment - We have noticed an issue that auto signed users getting added to our ganization and billed for those users. Here we would like to have a feature to bill only those users admin invited similar like Github. Further discussion with Support, I was informed that this feature in consideration and development by this time recomeded to use non billable users policy. When I had a check I noticed we should opt additional service called Atlassian Access and pay for it. I feel like it is not accepatable, we should have some option to control billed users or have provision to add non billable users without any additional cost. Please sreview and support 

            I have a similar issues, we are paying for Atlassian access for users that have a trello account they dont even use anymore.

            Should be possible to have full control over managed accounts and all the Atlassian products they have on the managed account

            Morten Junker Juul added a comment - I have a similar issues, we are paying for Atlassian access for users that have a trello account they dont even use anymore. Should be possible to have full control over managed accounts and all the Atlassian products they have on the managed account

            Happy New Year Atlassian!

            Just had an excellent email from you saying that I have exceeded my Atlassian Access tier.  Some of our adventurous users have installed Trello over the holidays and bounced us back over our licensed amount.

            Will 2023 be the year where the penny drops and we can stop our users from dictating our licensing unknowingly?

            My New Years' resolution is to remain positive with you guys, so starting off strong! 💪🏻 You can do it, we believe in you!

            Adam England added a comment - Happy New Year Atlassian! Just had an excellent email from you saying that I have exceeded my Atlassian Access tier.  Some of our adventurous users have installed Trello over the holidays and bounced us back over our licensed amount. Will 2023 be the year where the penny drops and we can stop our users from dictating our licensing unknowingly? My New Years' resolution is to remain positive with you guys, so starting off strong! 💪🏻 You can do it, we believe in you!

            We have users with only Free Trello license that are in the provisioning scope of our identity provider (AzureAD) and with that, they are counted in Atlassian Access billing. 

            In the managed accounts, I can't disable trello for users.

            The most of them are not using it. More of 30 people have last login time before 2021.

            If I exclude them from the provisioning, they can't access other products as a customer. For exemple, we use Jira Service Management as an Helpdesk for our internal factory.
            So, it's not a solution for us.

            You force us to pay for something we're not using.

            Gabriele Rosati added a comment - We have users with only Free Trello license that are in the provisioning scope of our identity provider (AzureAD) and with that, they are counted in Atlassian Access billing.  In the managed accounts, I can't disable trello for users. The most of them are not using it. More of 30 people have last login time before 2021. If I exclude them from the provisioning, they can't access other products as a customer. For exemple, we use Jira Service Management as an Helpdesk for our internal factory. So, it's not a solution for us. You force us to pay for something we're not using.

            We are using Access and experiencing the same issue with Basic END USERS creating new products. Why is this still only a Suggestion!!!!

            Stephen Crandell added a comment - We are using Access and experiencing the same issue with Basic END USERS creating new products. Why is this still only a Suggestion!!!!

            Nick Parry added a comment -

            This really isn’t good enough from a company like Atlassian, especially when we are being pushed into cloud hosted instances with monthly subscription charges. Until we can control our costs ourselves, Atlassian really shouldn’t be counting Trello accounts as a billable item.

             

            Nick Parry added a comment - This really isn’t good enough from a company like Atlassian, especially when we are being pushed into cloud hosted instances with monthly subscription charges. Until we can control our costs ourselves, Atlassian really shouldn’t be counting Trello accounts as a billable item.  

            Olivier GRALL added a comment - - edited

            We were due to migrate this december to Jira Cloud. Unfortunately, with this known issue, not progressing, we have decided to stay one more year on our internal Jira server.

            Olivier GRALL added a comment - - edited We were due to migrate this december to Jira Cloud. Unfortunately, with this known issue, not progressing, we have decided to stay one more year on our internal Jira server.

            Mark Crum added a comment -

            We're currently implementing Acces and having the same issues with free Trello accounts being billed. Fixing this issue should be a top priority

            Mark Crum added a comment - We're currently implementing Acces and having the same issues with free Trello accounts being billed. Fixing this issue should be a top priority

            Dana Frost added a comment -

            I recommend bringing issues (if they are getting no traction) to your sales rep. I work in a support role and every issues is #1 to that customer but you only have so much bandwidth and people listening. Atlassian is getting pretty big now and has problems of a large company.

            Dana Frost added a comment - I recommend bringing issues (if they are getting no traction) to your sales rep. I work in a support role and every issues is #1 to that customer but you only have so much bandwidth and people listening. Atlassian is getting pretty big now and has problems of a large company.

            Checking in on a Saturday afternoon out of business hours to perform MANUAL maintenance on anyone in our organization who used to be able to use SSO, fancied trying Trello on a whim and now having to MANUALLY carve them out of our authentication policies so we don't get billed.

            "Why do I have to set a new password" - great question Joe, it's because you downloaded Trello.

            📣 Is anyone at Atlassian actually listening to what the problem is here? 

            We shouldn't have our END USERS impact our billing without any level of control from administrators.  This is starting to be maddening how you are missing the complete point.  I don't want to buy Atlassian Access for 10,000 employees who need to submit tickets and read knowledge-base articles.

            Adam England added a comment - Checking in on a Saturday afternoon out of business hours to perform MANUAL maintenance on anyone in our organization who used to be able to use SSO, fancied trying Trello on a whim and now having to MANUALLY carve them out of our authentication policies so we don't get billed. "Why do I have to set a new password" - great question Joe, it's because you downloaded Trello. 📣 Is anyone at Atlassian actually listening to what the problem is here?   We shouldn't have our END USERS impact our billing without any level of control from administrators.  This is starting to be maddening how you are missing the complete point.  I don't want to buy Atlassian Access for 10,000 employees who need to submit tickets and read knowledge-base articles.

            We want the ability to manage and control access to Trello free and Bitbucket, as it stands now users that are synced with Atlassian, are able to sign up for Trello free and charged an Atlassian access license fee. with no way of removing that access without removing them Atlassian and creating some hack policy in azure.  

            Douglas Grilletto added a comment - We want the ability to manage and control access to Trello free and Bitbucket, as it stands now users that are synced with Atlassian, are able to sign up for Trello free and charged an Atlassian access license fee. with no way of removing that access without removing them Atlassian and creating some hack policy in azure.  

             

            We really wanted to see this implemented cz we have Atlassian Access subscriptions for 2,000 users. As a result of some users using Trello, which has a free plan, we have exceeded our Atlassian Access subscription count of 2,000.

            srinivasrao_mutyam added a comment -   We really wanted to see this implemented cz we have Atlassian Access subscriptions for 2,000 users. As a result of some users using Trello, which has a free plan, we have exceeded our Atlassian Access subscription count of 2,000.

            We are facing a GDPR problem because we are not allowed to preventing users from singing up to Trello with their work email. This is not good at all.

            WE NEED THIS FEATURE.

            Hanna Torany added a comment - We are facing a GDPR problem because we are not allowed to preventing users from singing up to Trello with their work email. This is not good at all. WE NEED THIS FEATURE.

            Hi Griffin,

             

            Any ETA to communicate to us for this feature implementation availability through instances?

             

            Thanks,

            Valentin

            LECERF Valentin added a comment - Hi Griffin,   Any ETA to communicate to us for this feature implementation availability through instances?   Thanks, Valentin

            We really wanted to see this implemented to Allow Administrators to control managed users' associated sites and products 

            Faisal Shamim added a comment - We really wanted to see this implemented to Allow Administrators to control managed users' associated sites and products 

            Tim Leclerc added a comment - - edited

            Hi Griffin -

            Thank you for that explanation, but I think I speak for a fair amount that that is not the use case scenario for the vast majority of us.  When we claim a domain, any user who has ever set up a trello account in the past using the domain you are claiming now is counting as a billable user according to Atlassian Access.  This was our case.  We also have a limited number of actual licensed users, as the vast majority of our employees are considered customers, which are not billable.  If they then set up a "free" trello account that is now counted as a billable customer for a user who was not previously billable.  I would also like to point out that you mentioned the "Non-billable policy", however, as it has been stated previously numerous times, the non-billable policy is not a viable option for managed users as we are not able to move managed users into the non-billable policy.  At the end of the day, we are still in the same scenario we were previously.

            Tim Leclerc added a comment - - edited Hi Griffin - Thank you for that explanation, but I think I speak for a fair amount that that is not the use case scenario for the vast majority of us.  When we claim a domain, any user who has ever set up a trello account in the past using the domain you are claiming now is counting as a billable user according to Atlassian Access.  This was our case.  We also have a limited number of actual licensed users, as the vast majority of our employees are considered customers, which are not billable.  If they then set up a "free" trello account that is now counted as a billable customer for a user who was not previously billable.  I would also like to point out that you mentioned the "Non-billable policy", however, as it has been stated previously numerous times, the non-billable policy is not a viable option for managed users as we are not able to move managed users into the non-billable policy.  At the end of the day, we are still in the same scenario we were previously.

            Hi everyone,

            I wanted to circle back around and mention, we have multiple teams – including the Trello team – actively working on a more proactive approach to control if and how managed users can create product instances. The timelines for Jira Software and Confluence, are more straightforward to determine than those for Trello and Bitbucket, where the product architecture is fundamentally different. Making this solution available first for Jira and Confluence helps inform our approach when it comes time to implement this for Trello and Bitbucket.

            As you may be aware, a user becomes an incremental billable user in Access upon gaining rights to their first cloud product. For example, if a user already has Confluence and then creates a Trello workspace, that user was already billable for Access at the time they were granted Confluence access, and the addition of Trello does not cause an incremental increase in the organization’s Access bill.

            Additionally, we introduced the concept of a “Non-billable policy” that you can set as the default policy when someone joins. We developed this for admins who don’t want users that are manually invited or signing themselves up to count towards the Atlassian Access subscription. Instead, you can automatically add them to a default non-billable policy. For more information: https://support.atlassian.com/security-and-access-policies/docs/understand-authentication-policies/#To-make-a-default-policy-non-billable

            To address concerns beyond the Access bill, admins can get in touch with users to shut down unauthorized Trello workspaces. If there is no response from the user, admins can reset these users' Atlassian account password and access their Trello interface directly. For more information: https://support.atlassian.com/security-and-access-policies/docs/how-to-work-with-admins-of-discovered-products/

            Lastly, I want to acknowledge that your concerns around Trello are valid and top of mind for us as we start building this feature set. We understand that for some, Trello is the primary driver of this issue and it’s paramount we enable customers with controls to manage this.

            Best,

            Griffin

            Griffin Jones added a comment - Hi everyone, I wanted to circle back around and mention, we have multiple teams – including the Trello team – actively working on a more proactive approach to control if and how managed users can create product instances. The timelines for Jira Software and Confluence, are more straightforward to determine than those for Trello and Bitbucket, where the product architecture is fundamentally different. Making this solution available first for Jira and Confluence helps inform our approach when it comes time to implement this for Trello and Bitbucket. As you may be aware, a user becomes an incremental billable user in Access upon gaining rights to their first cloud product. For example, if a user already has Confluence and then creates a Trello workspace, that user was already billable for Access at the time they were granted Confluence access, and the addition of Trello does not cause an incremental increase in the organization’s Access bill. Additionally, we introduced the concept of a “Non-billable policy” that you can set as the default policy when someone joins. We developed this for admins who don’t want users that are manually invited or signing themselves up to count towards the Atlassian Access subscription. Instead, you can automatically add them to a default non-billable policy. For more information: https://support.atlassian.com/security-and-access-policies/docs/understand-authentication-policies/#To-make-a-default-policy-non-billable To address concerns beyond the Access bill, admins can get in touch with users to shut down unauthorized Trello workspaces. If there is no response from the user, admins can reset these users' Atlassian account password and access their Trello interface directly. For more information: https://support.atlassian.com/security-and-access-policies/docs/how-to-work-with-admins-of-discovered-products/ Lastly, I want to acknowledge that your concerns around Trello are valid and top of mind for us as we start building this feature set. We understand that for some, Trello is the primary driver of this issue and it’s paramount we enable customers with controls to manage this. Best, Griffin

            Krista added a comment -

            Guys, Atlassian isn't "missing the point". They KNOW we're upset about Trello "free" users being unmanaged. They don't care because it generates them revenue.

            This is a huge scam and if it was up to me my company wouldn't be using this product any longer,

            Krista added a comment - Guys, Atlassian isn't "missing the point". They KNOW we're upset about Trello "free" users being unmanaged. They don't care because it generates them revenue. This is a huge scam and if it was up to me my company wouldn't be using this product any longer,

            Trello MUST be considered in phase 1....

            Felipe Gracini added a comment - Trello MUST be considered in phase 1....

            Fully agree with others who have posted, and I am going to repeat what I mentioned before, because Atlassian is completely missing the point.

            This is completely unacceptable and very unprofessional from Atlassian. 

            Atlassian is selling:

            • Jira Service Management , with the functionality of portals and "portal customer accounts",
            • Atlassian Access for "adding enterprise-grade identity and access management (IAM) features to the central admin console.".

            Then, and according to https://support.atlassian.com/subscriptions-and-billing/docs/manage-your-bill-for-atlassian-access/

            Jira Service Management portal customer account are not considered a unique billable user for Atlassian Access, but still covered by Atlassian Access features.

            Our organization requires SSO and IAM security controls, which is why we chose this product.

            However now that we are implementing, and spending thousands of $ on this already, we learn that any of our users that has used Trello (free plan) at least once in the past 4.5 years (since Feb. 2018 and later) is now counted into Atlassian Access billing, completely negating the non-billable aspect of JSM portal customer account.

            This applies to hundreds of our accounts, driving up the monthly Access bill to ~$1800 monthly for over 500 users that at some point interacted with Trello, whereas in reality actual agents are <100 (<$400 monthly).

            This in itself would not be a problem, if Atlassian allows us to remove and block Trello product access from these accounts, which Atlassian does not allow.

            It's an incomprehensible situation that Atlassian charges us for this and we cannot cancel / block Trello access.

            Both of the 2 offered workarounds are not viable:

            1. To "deactivate the user accounts" which is impossible since we require them activated, as portal customer accounts, to access the Jira Service Management portal.
            1. To "add affected user accounts into non-billable authentication policy and let affected user accounts to login service desk portal via username and password" - this kills the Identity Provider link, so there's no SSO or IAM controls, which we require and what was sold to us as being possible. 

            This needs to be adressed by Atlassian per the highest priority.

            The fact that this ticket is around since 2020 and having status "Suggestion / gathering interest" is not looking good by any means.

            It's certainly unacceptable to us and without a doubt to many other larger companies that require ful SSO/IAM security controls on their SaaS applications.

            Bas Rathje added a comment - Fully agree with others who have posted, and I am going to repeat what I mentioned before, because Atlassian is completely missing the point. This is completely unacceptable and very unprofessional from Atlassian.  Atlassian is selling: Jira Service Management  , with the functionality of portals and " portal customer accounts ", Atlassian Access  for "adding enterprise-grade identity and access management (IAM) features to the central admin console.". Then, and according to  https://support.atlassian.com/subscriptions-and-billing/docs/manage-your-bill-for-atlassian-access/ Jira Service Management  portal customer account  are  not considered  a unique billable user for Atlassian Access, but still covered by Atlassian Access features. Our organization requires SSO and IAM security controls, which is why we chose this product. However now that we are implementing, and spending thousands of $ on this already, we learn that any of our users that has used  Trello (free plan)  at least  once  in the past 4.5 years (since Feb. 2018 and later) is now counted into Atlassian Access billing, completely negating the non-billable aspect of JSM portal customer account. This applies to hundreds of our accounts, driving up the monthly Access bill to ~$1800 monthly for over 500 users that at some point interacted with Trello, whereas in reality actual agents are <100 (<$400 monthly). This in itself would not be a problem, if Atlassian allows us to remove and block Trello product access from these accounts, which Atlassian does not allow. It's an incomprehensible situation that Atlassian charges us for this and we cannot cancel / block Trello access. Both of the 2 offered workarounds are not viable: To "deactivate the user accounts" which is impossible since we require them activated, as portal customer accounts, to access the Jira Service Management portal. To "add affected user accounts into non-billable authentication policy and let affected user accounts to login service desk portal via username and password" - this kills the Identity Provider link, so there's no SSO or IAM controls, which we require and what was sold to us as being possible.  This needs to be adressed by Atlassian per the highest priority. The fact that this ticket is around since 2020 and having status "Suggestion / gathering interest" is not looking good by any means. It's certainly unacceptable to us and without a doubt to many other larger companies that require ful SSO/IAM security controls on their SaaS applications.

            Hi gjones@atlassian.com, please do listen to the feedback comments on this ticket and enable admins to control Trello & Bitbucket product access. This should be the main priority, because currently admins have no means of disabling user access to these products other then disabling or deleting the user's entire Atlassian account, which is not in our or Atlassian's best interest. Admins would like to simply be able to revoke user access to Trello or Bitbucket (like we can for other products), without having to delete or disable their entire Atlassian account. By continuing to tightly couple access of these products with the user's Atlassian account, with no option of disabling access to those products, some organizations are forced to disable Atlassian accounts entirely for users (which I know because I've had to do so in our organization for many legacy Trello users that would otherwise be billable). Non-billable policy, is not a solution to this problem, we should not have to sacrifice security feature like SSO and others, because appropriate product access controls aren't available. Please fix this.

            Ivan Shtanichev added a comment - Hi gjones@atlassian.com , please do listen to the feedback comments on this ticket and enable admins to control Trello & Bitbucket product access. This should be the main priority, because currently admins have no means of disabling user access to these products other then disabling or deleting the user's entire Atlassian account, which is not in our or Atlassian's best interest. Admins would like to simply be able to revoke user access to Trello or Bitbucket (like we can for other products), without having to delete or disable their entire Atlassian account. By continuing to tightly couple access of these products with the user's Atlassian account, with no option of disabling access to those products, some organizations are forced to disable Atlassian accounts entirely for users (which I know because I've had to do so in our organization for many legacy Trello users that would otherwise be billable). Non-billable policy, is not a solution to this problem, we should not have to sacrifice security feature like SSO and others, because appropriate product access controls aren't available. Please fix this.

            Roberto Martignano added a comment - - edited

            What's the point of a feedback if it's not taken into consideration?

            This is a punch in the face to the community. Or, well, to paying customers...

            Roberto Martignano added a comment - - edited What's the point of a feedback if it's not taken into consideration? This is a punch in the face to the community. Or, well, to paying customers...

            I have to pitch in and agree with the rest here: Trello and Bitbucket are the ones that cause problems. So these should go on Phase 1.. at least trello!

            Alex Koxaras _Relational_ added a comment - I have to pitch in and agree with the rest here: Trello and Bitbucket are the ones that cause problems. So these should go on Phase 1.. at least trello!

            luke west added a comment -

            I am cynical.

            Atlassian are fixing the things which are important/non-urgent to THEM, and ignoring customer-centric important/urgent items (the revenue generating ones) for the moment. It means customers keep paying for a "free" service over which they have no control for another year or two before it is "fixed"

            Once completed, I fully expect Atlassian to announce the fix as a new feature.

            I would love to be proved wrong, but...

             

             

            luke west added a comment - I am cynical. Atlassian are fixing the things which are important/non-urgent to THEM, and ignoring customer-centric important/urgent items (the revenue generating ones) for the moment. It means customers keep paying for a "free" service over which they have no control for another year or two before it is "fixed" Once completed, I fully expect Atlassian to announce the fix as a new feature. I would love to be proved wrong, but...    

            Agreed, Trello and Bitbucket are the ones that give problems, not Jira or Confluence

            Matijs Visser added a comment - Agreed, Trello and Bitbucket are the ones that give problems, not Jira or Confluence

            Andrew Wright added a comment - - edited

            It's great to hear there is some progress on this - but it sounds like it's really missing the core issue here

             

            We are scoping out corresponding controls for Trello and Bitbucket for the next phase of the project.

             

            These are the ones that need urgently addressing!

            Andrew Wright added a comment - - edited It's great to hear there is some progress on this - but it sounds like it's really missing the core issue here   We are scoping out corresponding controls for Trello and Bitbucket for the next phase of the project.   These are the ones that need urgently addressing!

            The fact that something is being done to address this is great but in the meantime the customer is bearing the costs of Atlassian's free demo software.

            There may be contractual issues with this. 

            Derek Wailes added a comment - The fact that something is being done to address this is great but in the meantime the customer is bearing the costs of Atlassian's free demo software. There may be contractual issues with this. 

            So happy you guys are actually listening, but you seemed to have missed one of the central pain point themes in this thread...

            "It's the bitbucket, trello nonsense that magically charges our accounts but we have ZERO ability to do anything about it. "

            C'mon!!

            Please make Trello part of phase 1, that one is critical. 

             

            Jim Anderson added a comment - So happy you guys are actually listening, but you seemed to have missed one of the central pain point themes in this thread... "It's the bitbucket, trello nonsense that magically charges our accounts but we have ZERO ability to do anything about it. " C'mon!! Please make Trello part of phase 1, that one is critical.   

            Great to hear

            darleneashleigh.jeter added a comment - Great to hear

            Glad we got some response after few months.
            So, what alternative solutions do you provide until you fix the problem for customer who are getting billed for Atlassian Access unnecessarily.

            How about these below options:
            [OPTION 1] Do not charge for Atlassian Access licenses until this is resolved.
            [OPTION 2]: Make the non-billable policy as the default policy. 

             

            Praveen Gudupudi added a comment - Glad we got some response after few months. So, what alternative solutions do you provide until you fix the problem for customer who are getting billed for Atlassian Access unnecessarily. How about these below options: [OPTION 1] Do not charge for Atlassian Access licenses until this is resolved. [OPTION 2] : Make the non-billable policy as the default policy.   

            Thanks for the update. While this is being worked on, can you please remove Trello-only users from Admin, or at least make them like Service Desk Customers and non-billable? No control over added costs is our primary complaint.

            Scott Paist added a comment - Thanks for the update. While this is being worked on, can you please remove Trello-only users from Admin, or at least make them like Service Desk Customers and non-billable? No control over added costs is our primary complaint.

            Please make Trello part of phase 1, that one is critical. we need to be able to stop all of them from happening.

            Mourad Marzouk added a comment - Please make Trello part of phase 1, that one is critical. we need to be able to stop all of them from happening.

            Atlassian is missing the point. Jira, Confluence already have controls - even if reactive. We can delete an account that someone provisisoned.  It's the bitbucket, trello nonsense that magically charges our accounts but we have ZERO ability to do anything about it.  

            Rick Hadsall added a comment - Atlassian is missing the point. Jira, Confluence already have controls - even if reactive. We can delete an account that someone provisisoned.  It's the bitbucket, trello nonsense that magically charges our accounts but we have ZERO ability to do anything about it.  

            Hi everyone, thank you for the lively discussion and feedback on this ticket. We hear your concerns and are committed to providing more updates and transparency on the work being done to resolve these issues.

            We understand Atlassian admins are looking for more advanced security controls over what their users create. ‘Automatic Product Discovery’ gave organization admins visibility into what products their managed users created outside of their organization.

            We are currently working on the next iteration of this feature set, which aims to enable admins to determine if and how managed accounts provision new product instances. After conversations with customers, two themes have emerged that are now the main focus of our solution’s approach:

            1. Admins would like the ability to block new product instances being spun up

            2. Admins would like users to request new instances to be created, as opposed to having those instances created automatically

            Over the course of Atlassian's FY23, our focus will be on delivering these controls for Jira, Confluence, and Jira Service Management. We are scoping out corresponding controls for Trello and Bitbucket for the next phase of the project.

            We plan to deliver this functionality to you over the course of FY23 and will use this ticket to provide updates. As we progress, as always, please feel free to leave your feedback. We understand that this feature set is essential, and we are committed to delivering a solution that meets your needs. We appreciate your patience.

            Griffin Jones added a comment - Hi everyone, thank you for the lively discussion and feedback on this ticket. We hear your concerns and are committed to providing more updates and transparency on the work being done to resolve these issues. We understand Atlassian admins are looking for more advanced security controls over what their users create. ‘Automatic Product Discovery’ gave organization admins visibility into what products their managed users created outside of their organization. We are currently working on the next iteration of this feature set, which aims to enable admins to determine if and how managed accounts provision new product instances. After conversations with customers, two themes have emerged that are now the main focus of our solution’s approach: 1. Admins would like the ability to block new product instances being spun up 2. Admins would like users to request new instances to be created, as opposed to having those instances created automatically Over the course of Atlassian's FY23, our focus will be on delivering these controls for Jira, Confluence, and Jira Service Management. We are scoping out corresponding controls for Trello and Bitbucket for the next phase of the project. We plan to deliver this functionality to you over the course of FY23 and will use this ticket to provide updates. As we progress, as always, please feel free to leave your feedback. We understand that this feature set is essential, and we are committed to delivering a solution that meets your needs. We appreciate your patience.

            Definitely a massive issue. We went from 6 access license requirement to 36 because people had signed up for free trello. 

            Hannah Cherry added a comment - Definitely a massive issue. We went from 6 access license requirement to 36 because people had signed up for free trello. 

              gjones@atlassian.com Griffin Jones
              rbecker Rodrigo B.
              Votes:
              1611 Vote for this issue
              Watchers:
              1047 Start watching this issue

                Created:
                Updated:
                Resolved: