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

            We need to be able to disable this feature so users are not signing up for trials.

            Alexander Nezis added a comment - We need to be able to disable this feature so users are not signing up for trials.

            Where we have security and regulatory requirements that demand applications are validated this administrative mess is an audit trap.

            I don't expect Atlassian to do anything about it because they seem to be building a thunder cloud for admin on purpose.

            I note the patronizing email today telling admins that it is their duty to cleanup their cloud instance. Dear Atlassian, you made it a mess in the first place.

            Derek Wailes added a comment - Where we have security and regulatory requirements that demand applications are validated this administrative mess is an audit trap. I don't expect Atlassian to do anything about it because they seem to be building a thunder cloud for admin on purpose. I note the patronizing email today telling admins that it is their duty to cleanup their cloud instance. Dear Atlassian, you made it a mess in the first place.

            +1

            Arrived at this issue too,  everything that David Meredith said, spot on.
            Start with removing the Access Billing for Free trello

            This might make more admins sign up for it as removes the uncontrollable potential cost.

            Darren Taylor added a comment - +1 Arrived at this issue too,  everything that David Meredith said, spot on. Start with removing the Access Billing for Free trello This might make more admins sign up for it as removes the uncontrollable potential cost.

            Atlassian out here promoting "Atlassian Together" by bringing other tools into the Atlassian ecosystem friction-free and making it incredibly hard for admins to navigate access and billing to their own products.

            Just let us remove Trello from managed accounts or allow us to use SSO with free watered down products like any other normal company?

             

            Adam England added a comment - Atlassian out here promoting "Atlassian Together" by bringing other tools into the Atlassian ecosystem friction-free and making it incredibly hard for admins to navigate access and billing to their own products. Just let us remove Trello from managed accounts or allow us to use SSO with free watered down products like any other normal company?  

            Eugen G. added a comment -

            I don't expect anything to happen soon - and in your last sentence you precisely highlighted why, David M.

            Eugen G. added a comment - I don't expect anything to happen soon - and in your last sentence you precisely highlighted why, David M.

            David Meredith added a comment - - edited

            Benefits of Atlassian access for: Jira Software | Work Management | Service Management | Confluence | Bitbucket | Status Page
            I can manage product access, licencing, SSO. (Including non-licenced customer users)

            Benefits of Atlassian Access for Trello (Free) | Bitbucket:
            NONE, I can't manage product access or licencing and it costs me extra with literally no benefit.

            If 2000 of my users decided tomorrow, to sign up for a free Trello account (which I can't prevent them from doing), they'll massively increase my Atlassian Access bill. Even if they never use Trello ever again. As an admin, I can't remove Trello from their Atlassian Accounts. I'd just be stuck paying for them forever, or disable their entire Atlassian Account, losing access to the products I need them to access.

            Atlassian Access already has the concept of non-billable users for JSM customers, because WE DON'T PAY FOR LICENCES FOR THEM. It would not be difficult to extend this to Trello Free accounts, it's not as if Atlassian Access doesn't have access to this information. SSO would still work as it does for non-billable JSM customers.

            I'd like Atlassian to prove me wrong here but I don't think they want to fix this. It generates additional income for them which appears to be worth more than the experience of ~800 admins.

            David Meredith added a comment - - edited Benefits of Atlassian access for: Jira Software | Work Management | Service Management | Confluence | Bitbucke t | Status Page I can manage product access, licencing, SSO. (Including non-licenced customer users) Benefits of Atlassian Access for Trello (Free) | Bitbucket: NONE , I can't manage product access or licencing and it costs me extra with literally no benefit. If 2000 of my users decided tomorrow, to sign up for a free Trello account ( which I can't prevent them from doing ), they'll massively increase my Atlassian Access bill. Even if they never use Trello ever again. As an admin, I can't remove Trello from their Atlassian Accounts. I'd just be stuck paying for them forever, or disable their entire Atlassian Account, losing access to the products I need them to access. Atlassian Access already has the concept of non-billable users for JSM customers, because WE DON'T PAY FOR LICENCES FOR THEM . It would not be difficult to extend this to Trello Free accounts, it's not as if Atlassian Access doesn't have access to this information. SSO would still work as it does for non-billable JSM customers. I'd like Atlassian to prove me wrong here but I don't think they want to fix this. It generates additional income for them which appears to be worth more than the experience of ~800 admins.

            wvorigin added a comment -

            +1
            I want this as well. It cannot be that a Free Trello will be considered as billable product.

            wvorigin added a comment - +1 I want this as well. It cannot be that a Free Trello will be considered as billable product.

            This issue needs fixing, if you are using the Access module, you should be able to control the cost.

             

            Why can't they apply if the Trello license = is free do not bill very simple

            Anthony Bowmore added a comment - This issue needs fixing, if you are using the Access module, you should be able to control the cost.   Why can't they apply if the Trello license = is free do not bill very simple

            Eryll Paula added a comment - https://getsupport.atlassian.com/browse/CA-1952401

            https://support.atlassian.com/trello/docs/changing-an-email-address/

            If you're using a company email address on your Trello account, and the organization who owns the domain (everything after the @ in your email address) has verified the domain on their Atlassian Organization, the Organization Admin have the ability to manage your Trello account. This means they could deactivate or delete the Trello account at any time. 

            "This means they could deactivate or delete the Trello account at any time."

            Not true...

             

            Alvaro Riera Elena added a comment - https://support.atlassian.com/trello/docs/changing-an-email-address/ If you're using a company email address on your Trello account, and the organization who owns the domain (everything after the @ in your email address) has verified the domain on their Atlassian Organization, the Organization Admin have the ability to manage your Trello account. This means they could deactivate or delete the Trello account at any time. "This means they could deactivate or delete the Trello account at any time." Not true...  

            Bas Rathje added a comment - - edited

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

            Bill Goetz added a comment -

            This would save Org admins so much time! Right now, if an Atlassian Access admins gets notified of a new Org being stood up, we have to contact the user and have them (try) to make us Org admins on the new site, so we can lock it out.

            Bill Goetz added a comment - This would save Org admins so much time! Right now, if an Atlassian Access admins gets notified of a new Org being stood up, we have to contact the user and have them (try) to make us Org admins on the new site, so we can lock it out.

            Praveen Gudupudi added a comment - - edited

            Hi Atlassian Team,
            I hope the Atlassian is reviewing these comments.
            This issue is a real pain for the customers.

            What is your timeline in addressing this issue?
            At least , provide an alternative solution to this issue till it is addressed.
            OR do not bill for the Atlassian Access for the concerned customers till this issue is addressed.

             

            Praveen Gudupudi added a comment - - edited Hi Atlassian Team, I hope the Atlassian is reviewing these comments. This issue is a real pain for the customers. What is your timeline in addressing this issue? At least , provide an alternative solution to this issue till it is addressed. OR do not bill for the Atlassian Access for the concerned customers till this issue is addressed.  

            Katja Wass added a comment -

            Absolutely unacceptable that we can´t control or more precise can´t permit users from downloading and start using Trello. 

            Systems at our company needs to be in the solution repository and Trello ain´t and shall not be. And when also being billed for access, then the only one this is smart for is Atlassian. 

            Must be prioritised fixed asap

             

            Katja Wass added a comment - Absolutely unacceptable that we can´t control or more precise can´t permit users from downloading and start using Trello.  Systems at our company needs to be in the solution repository and Trello ain´t and shall not be. And when also being billed for access, then the only one this is smart for is Atlassian.  Must be prioritised fixed asap  

            As an Atlassian partner I can confirm this behaviour has been a blocker in several Atlassian Access presales process

            And is an pain point for all our JSM Cloud and AA customers

            This is for me the "hotest" issue currently on the product, I hope it will be  prioritized soon

            Mathieu Truchot added a comment - As an Atlassian partner I can confirm this behaviour has been a blocker in several Atlassian Access presales process And is an pain point for all our JSM Cloud and AA customers This is for me the "hotest" issue currently on the product, I hope it will be  prioritized soon

            At least, as we are stuck for managing users, can Atlassian provide a workarround and allow more (free) Atlassian acess - for users having only access to Jira Service Management.

            The only solution is to pay more for free users? This behavior will contribute to a bad reputation for Atlassian software and let users think to change this tools.

            Having no feedback from Atlassian is disapointing.

             

            Martin ARSAC added a comment - At least, as we are stuck for managing users, can Atlassian provide a workarround and allow more (free) Atlassian acess - for users having only access to Jira Service Management. The only solution is to pay more for free users? This behavior will contribute to a bad reputation for Atlassian software and let users think to change this tools. Having no feedback from Atlassian is disapointing.  

            Greg Besso added a comment -

            This is quite surprising, and honestly unacceptable to have this lack of control for managed user accounts to not be able to granularly remove consumer products they accidentally sign up for. 

            Greg Besso added a comment - This is quite surprising, and honestly unacceptable to have this lack of control for managed user accounts to not be able to granularly remove consumer products they accidentally sign up for. 

            obl-br added a comment -

            This really needs to be be implemented.  As things stand our users can sign up for "free" Atlassian services without knowing that we will be billed for the access rights.

            I think I understand why Atlassian aren't so keen to "fix" this issue.

            obl-br added a comment - This really needs to be be implemented.  As things stand our users can sign up for "free" Atlassian services without knowing that we will be billed for the access rights. I think I understand why Atlassian aren't so keen to "fix" this issue.

            At the LEGO group we are on a journey towards automating and centralizing management tasks across our entire portfolio of software-as-a-service solutions - through a Developer Centric approach anchored in the Developer Experience group.

            Not being able to limit who can access what from the SaaS offering negates our ability to create a solid onboarding experience for our product teams.

            Additionally to providing value for our employees, this experience also creates overhead for the team that is managing the day-to-day operations for the Atlassian product suite.

            This, combined with a handful of other missing features like

            • "multiple assignees" (most likely never to be fixed)
            • disabling user-invitation when directory is managed through SAML/SCIM (aware a solution is coming Feb 2023)
            • the steadily rising cost of the Atlassian products over the last couple of years

            are essentially, based on internal feedback, pushing us to start looking elsewhere for - ironically - more agile and more cost-effective products that cater towards enterprise managed workflows.

            vincentbriglia added a comment - At the LEGO group we are on a journey towards automating and centralizing management tasks across our entire portfolio of software-as-a-service solutions - through a Developer Centric approach anchored in the Developer Experience group. Not being able to limit who can access what from the SaaS offering negates our ability to create a solid onboarding experience for our product teams. Additionally to providing value for our employees, this experience also creates overhead for the team that is managing the day-to-day operations for the Atlassian product suite. This, combined with a handful of other missing features like "multiple assignees" (most likely never to be fixed) disabling user-invitation when directory is managed through SAML/SCIM (aware a solution is coming Feb 2023) the steadily rising cost of the Atlassian products over the last couple of years are essentially, based on internal feedback, pushing us to start looking elsewhere for - ironically - more agile and more cost-effective products that cater towards enterprise managed workflows.

            I'm in awe that this request/feature is still in the "gathering interest" status. Are there at least any updates for this? 

            Jeff Gunawan added a comment - I'm in awe that this request/feature is still in the "gathering interest" status. Are there at least any updates for this? 

            Praveen Gudupudi added a comment - - edited
            • We have been using Enterprise version of TRELLO since last few years even before it was acquired by Atlassian.
              We use SSO to login to TRELLO and we have claimed our domains in TRELLO. TRELLO admin were able to manage the users being created. All was good till Dec 2021.
            • Atlassian implements Atlassian Access {}feature to access its products. TRELLO Enterprise license includes the cost of Atlassian Access. This is good.
              But, users from our domain are now able to create FREE TRELLO profiles and this is creating Atlassian Access profiles for them and Atlassian is charging us for the Atlassian Access We have no control on that.
              As a temporary solution, we are moving such users to a non billable policy, but doing this exercise every month is very frustrating and not customer friendly.
              If we miss this exercise, we get charged.

             THIS IS CAUSING LOT OF PROBLEM FOR US. HOPE AND WISH THIS IS GIVEN A HIGHER PRIORITY

            Praveen Gudupudi added a comment - - edited We have been using Enterprise version of TRELLO since last few years even before it was acquired by Atlassian. We use SSO to login to TRELLO and we have claimed our domains in TRELLO. TRELLO admin were able to manage the users being created. All was good till Dec 2021. Atlassian implements Atlassian Access { }feature to access its products. TRELLO Enterprise license includes the cost of Atlassian Access.  This is good. But, users from our domain are now able to create FREE TRELLO profiles and this is creating Atlassian Access profiles for them and Atlassian is charging us for the Atlassian Access We have no control on that. As a temporary solution, we are moving such users to a non billable policy, but doing this exercise every month is very frustrating and not customer friendly. If we miss this exercise, we get charged.   THIS IS CAUSING LOT OF PROBLEM FOR US. HOPE AND WISH THIS IS GIVEN A HIGHER PRIORITY

            The control needs to be added! I have users consistently accidentally creating new products/orgs. The cleanup is excruciating and takes Atlassian support literal months to finally delete.

            Stephen Davis added a comment - The control needs to be added! I have users consistently accidentally creating new products/orgs. The cleanup is excruciating and takes Atlassian support literal months to finally delete.

            luke west added a comment -

            This was created in Jan 2020 - it cant be important to Atlassian

            Disappointed.

            luke west added a comment - This was created in Jan 2020 - it cant be important to Atlassian Disappointed.

            luke west added a comment -

            Just bumping this ticket.

            We have the same problem. Lack of control of free accounts which cause us to pay for connect licenses sucks.

            Come on - this is important!

            luke west added a comment - Just bumping this ticket. We have the same problem. Lack of control of free accounts which cause us to pay for connect licenses sucks. Come on - this is important!

            I agree with the previous comments:

            "I WANT to exclude Trello (or any Atlassian free plan) from the billable policy in Atlassian Access. It is currently not possible."

            Felipe Gracini added a comment - I agree with the previous comments: "I WANT to exclude Trello (or any Atlassian free plan) from the billable policy in Atlassian Access. It is currently not possible."

            Ulka added a comment -

            Ulka added a comment - https://getsupport.atlassian.com/browse/PCS-117308

            Dana Frost added a comment -

            Not having true “autonomous” control of your own account is the real issue in my eyes. You should not need an administrator of a remote site to “dis-engage” from a project that you should not have been registered in the first place. I would like to see a way where end-users could remove their own registration without the need of an admin from a cloud instance that they no longer user (or never even registered). We had a number of users registered (without there knowledge or input) to a JIRA cloud instance as a form of spam. There was not way for our admins to clean this up but also, there was not way for the users themselves to request to be removed etc.

            So, I see this as a serious issue for sure.

            Dana Frost added a comment - Not having true “autonomous” control of your own account is the real issue in my eyes. You should not need an administrator of a remote site to “dis-engage” from a project that you should not have been registered in the first place. I would like to see a way where end-users could remove their own registration without the need of an admin from a cloud instance that they no longer user (or never even registered). We had a number of users registered (without there knowledge or input) to a JIRA cloud instance as a form of spam. There was not way for our admins to clean this up but also, there was not way for the users themselves to request to be removed etc. So, I see this as a serious issue for sure.

            Another situation:

            I use "Atlassian Access" to propose SSO to IT users using Jira Software, Confluence.

            We recently have an increase of our seat in "Atlassian Access" due to the fact that some users(outside from the IT users) are using Trello in free version for their own purpose with their work email.

            I would like to exclude Trello (or any Atlassian free plan) from the billable policy in Atlassian Access. It is currently not possible.

            As soon as you use an Atlassian product (with your work e-mail) even if it is not managed by the firm, it consume a seat in Atlassian access.

            Regards

            Martin

            PS: A radical solution can be to stop using Atlassian due to the current limitation.

             

             

             

            Martin ARSAC added a comment - Another situation: I use "Atlassian Access" to propose SSO to IT users using Jira Software, Confluence. We recently have an increase of our seat in "Atlassian Access" due to the fact that some users(outside from the IT users) are using Trello in free version for their own purpose with their work email. I would like to exclude Trello (or any Atlassian free plan) from the billable policy in Atlassian Access. It is currently not possible. As soon as you use an Atlassian product (with your work e-mail) even if it is not managed by the firm, it consume a seat in Atlassian access. Regards Martin PS: A radical solution can be to stop using Atlassian due to the current limitation.      

            Another situation to note: User-created accounts override SAML-controlled accounts in Atlassian Access. This means that it is very difficult to manage a user who creates an account outside of the SAML mechanism.

            For example: Sally creates an Atlassian account on her own with her work email. This account will automatically be added to her work's Enterprise account. Eventually Sally may be added to the SAML gateway. When Sally departs, the SAML gateway will attempt to deactivate her account. But it cannot because she first created a direct account. The only way to then resolve is to know that she wasn't fully deactivated, then manually deactivate her account.

            Melanie Truett added a comment - Another situation to note: User-created accounts override SAML-controlled accounts in Atlassian Access. This means that it is very difficult to manage a user who creates an account outside of the SAML mechanism. For example: Sally creates an Atlassian account on her own with her work email. This account will automatically be added to her work's Enterprise account. Eventually Sally may be added to the SAML gateway. When Sally departs, the SAML gateway will attempt to deactivate her account. But it cannot because she first created a direct account. The only way to then resolve is to know that she wasn't fully deactivated, then manually deactivate her account.

            Gustavo Kindel added a comment - https://getsupport.atlassian.com/browse/TRELLO-125142

            Charles added a comment -

            Same need definitely required. For most product like creating another instance of Jira / confluence it can be managed by contacting new creation. it is a pain, but still.  The MAJOR issue is the free trello. We do have an premium subscription and would like to force use to use that one vs creating free board to ease management, unfortunately we cannot restrictrict to paid version and neither stop paying for those not using it anymore. In some cases, people stop using the trello free (only product they were using), but we still pay for Atlassian Access for them.  in our case we do not want to put them in non billable as if they move to another product later we want to enforce security.... non billable policy requires manual sync thru csv and it end up being time consuming !  Let at least option to delete board of user (with proper warning confirmation to end user etc) so it can be like he never uses Trello and get back to non billable until he uses other product or new product again.

            Charles added a comment - Same need definitely required. For most product like creating another instance of Jira / confluence it can be managed by contacting new creation. it is a pain, but still.  The MAJOR issue is the free trello. We do have an premium subscription and would like to force use to use that one vs creating free board to ease management, unfortunately we cannot restrictrict to paid version and neither stop paying for those not using it anymore. In some cases, people stop using the trello free (only product they were using), but we still pay for Atlassian Access for them.  in our case we do not want to put them in non billable as if they move to another product later we want to enforce security.... non billable policy requires manual sync thru csv and it end up being time consuming !  Let at least option to delete board of user (with proper warning confirmation to end user etc) so it can be like he never uses Trello and get back to non billable until he uses other product or new product again.

            A refund until fixed might do the trick.

            Karsten Zacher Nielsen added a comment - A refund until fixed might do the trick.

            I had an open ticket with Atlassian on this exact issue just this week. There were several emails involved with this ticket. My abbreviated conversation is below, but the quick answer is at the bottom.

             

            Me to Atlassian: I got the following message in an email. "Your user tier for Atlassian Access has been exceeded by 1 users. In order to keep your users online and collaborating, you need to either increase the user tier or decrease the number of current users by 1." 
            We have a 15 user license for JSW, JSM, and Confluence. We have not exceeded any of these three. This message is about Atlassian Access which includes Free Trello accounts. Why are Free Trello accounts set up by employees taking up an Atlassian Access license? I don't understand what Free Trello licenses have to do with our paid 15 user license in JSW, JSM, and Confluence.


            Atlassian to me: At the moment, there is no proper way to delete the Trello accounts without deleting a user's Atlassian account as well (and that will make the user lose access to any Atlassian cloud product linked to that account).


            Me to Atlassian: In the end, we bought a higher tier license. I still think this is not a good policy. A free Trello account should not count toward our paid Access license. I hope something is done to correct this unfair practice where Atlassian is taking advantage of its paying customers. 


            Atlassian to me: We are very sorry that you had to pay for an extra license to solve this problem, and for not having a better solution at the moment.

            Clifton Foster added a comment - I had an open ticket with Atlassian on this exact issue just this week. There were several emails involved with this ticket. My abbreviated conversation is below, but the quick answer is at the bottom.   Me to Atlassian: I got the following message in an email. "Your user tier for Atlassian Access has been exceeded by 1 users. In order to keep your users online and collaborating, you need to either increase the user tier or decrease the number of current users by 1."  We have a 15 user license for JSW, JSM, and Confluence. We have not exceeded any of these three. This message is about Atlassian Access which includes Free Trello accounts. Why are Free Trello accounts set up by employees taking up an Atlassian Access license? I don't understand what Free Trello licenses have to do with our paid 15 user license in JSW, JSM, and Confluence. Atlassian to me: At the moment, there is no proper way to delete the Trello accounts without deleting a user's Atlassian account as well (and that will make the user lose access to any Atlassian cloud product linked to that account). Me to Atlassian: In the end, we bought a higher tier license. I still think this is not a good policy. A free Trello account should not count toward our paid Access license. I hope something is done to correct this unfair practice where Atlassian is taking advantage of its paying customers.  Atlassian to me: We are very sorry that you had to pay for an extra license to solve this problem, and for not having a better solution at the moment.

            Is there any update on this?? We have Access Synced with Azure AD and Atlassians workaround on this is hell. Remove user from sync, Remove user from SCIM with rest API, delete user in directory, re-enable sync, recreate user. Not even once that worked well.... and of course user looses all history, permissions, etc. and of course we are on the edge with our access licences so every user counts.....

            Deleted Account (Inactive) added a comment - Is there any update on this?? We have Access Synced with Azure AD and Atlassians workaround on this is hell. Remove user from sync, Remove user from SCIM with rest API, delete user in directory, re-enable sync, recreate user. Not even once that worked well.... and of course user looses all history, permissions, etc. and of course we are on the edge with our access licences so every user counts.....

            I second what Adam England said.

            Alex Koxaras -Relational- added a comment - I second what Adam England said.

            I just came up with another use case where this inability to control users bit us - StatusPage provides free SAML connectivity for users, but admins going to manage.statuspage.io to manage their page use their Atlassian Cloud account. This requires them to verify their domain and connect SAML if they want to enforce SSO for their admins. However, once they do that, they are bitten by the same "free" Trello user problem.

            Derek Fields (RightStar) added a comment - I just came up with another use case where this inability to control users bit us - StatusPage provides free SAML connectivity for users, but admins going to manage.statuspage.io to manage their page use their Atlassian Cloud account. This requires them to verify their domain and connect SAML if they want to enforce SSO for their admins. However, once they do that, they are bitten by the same "free" Trello user problem.

            Sorry for the delay, been fighting this along with other things.

            So our process as it stands.

            • Joe Brown - a faithful JSM internal customer who loves his access via our easy-to-use single sign-on provider hears good things about Trello and downloads it and installs, logs in.
            • Joe Brown converts from Free Guy Customer to Billed Guy User as per (quite frankly ridiculous) Atlassian Access rules.
            • We spot this on our now daily audits.
            • Fire up Postman to use Atlassian SCIM API - don't forget the API bearer token which you have documented during setting up iDP or you'll need to generate a new one.
            • Curl script to get user ID from username : [How to filter users in provisioning SCIM using REST API | Atlassian Cloud | Atlassian Documentation|https://confluence.atlassian.com/cloudkb/how-to-filter-users-in-provisioning-scim-using-rest-api-1108090980.html]
            • Curl script to deactivate Joe Brown using his User ID : The User provisioning REST API REST API (atlassian.com)
            • Move Joe Brown from Billed SSO policy into Non Billed - Joe Brown has lost his SSO rights with his curiosity in free Trello unless he parts ways with Trello.
            • Reactivate Joe Brown.

            Few days and it seems to have stuck, we don't have him moving back into billed policies but keeping a watchful eye on him appearing.  I assume this is what Atlassian are doing when you open a ticket to move users from Billed to Non-Billed.

            Please Atlassian, help us out here... this is a logistical nightmare!

            Adam England added a comment - Sorry for the delay, been fighting this along with other things. So our process as it stands. Joe Brown - a faithful JSM internal customer who loves his access via our easy-to-use single sign-on provider hears good things about Trello and downloads it and installs, logs in. Joe Brown converts from Free Guy Customer to Billed Guy User as per (quite frankly ridiculous) Atlassian Access rules. We spot this on our now daily audits. Fire up Postman to use Atlassian SCIM API - don't forget the API bearer token which you have documented during setting up iDP or you'll need to generate a new one. Curl script to get user ID from username : [How to filter users in provisioning SCIM using REST API | Atlassian Cloud | Atlassian Documentation|https://confluence.atlassian.com/cloudkb/how-to-filter-users-in-provisioning-scim-using-rest-api-1108090980.html] Curl script to deactivate Joe Brown using his User ID : The User provisioning REST API REST API (atlassian.com) Move Joe Brown from Billed SSO policy into Non Billed - Joe Brown has lost his SSO rights with his curiosity in free Trello unless he parts ways with Trello. Reactivate Joe Brown. Few days and it seems to have stuck, we don't have him moving back into billed policies but keeping a watchful eye on him appearing.  I assume this is what Atlassian are doing when you open a ticket to move users from Billed to Non-Billed. Please Atlassian, help us out here... this is a logistical nightmare!

            Murty Cherukumilli added a comment - - edited

            Ability for Admins to manage user's trello access is MUST and not working now. As an Admin, I should have option to remove Trello access like any other product.

             

            and .. Users should not have option to self register / associate with company managed accounts.

            Murty Cherukumilli added a comment - - edited Ability for Admins to manage user's trello access is MUST and not working now. As an Admin, I should have option to remove Trello access like any other product.   and .. Users should not have option to self register / associate with company managed accounts.

            Could not agree more!

            We have stalled our expansion of Jira Service Management because of this issue. 

            Jim Anderson added a comment - Could not agree more! We have stalled our expansion of Jira Service Management because of this issue. 

            GI added a comment -

            @Atlassian I've bee reading the comments in this issue, I think most of us are frustrated more or less for the same reasons. Here a few suggestions I hope you can have a look at:

            • SSO should ALWAYS be free of charge and available even in the free versions of any application.
            • Claiming a domain means the company has FULL control on whoever created an account with that domain:
              • no new accounts sign up with that domain (i.e. Trello, Bitbucket) IF is not provisioned through IdP or manually from the Atlassian Access interface
              • not being able to create your own free instances of Jira Cloud, Confluence Cloud, etc from scratch
              • being able to administer and access existing cloud products without having to contact the admins (they may have left the company and not being able to access and administer those products anymore)
            • Not having control on how many users are licensed is a nightmare:
              • for budgeting and foreseeing the amount of licenses in advance
              • for having to justify to the your company the increase and the unexpected cost in the middle of the budgeted year
              • for maintaining and justifying the debate about Atlassian being a company you can trust and that cares about customers

            GI added a comment - @Atlassian I've bee reading the comments in this issue, I think most of us are frustrated more or less for the same reasons. Here a few suggestions I hope you can have a look at: SSO should ALWAYS be free of charge and available even in the free versions of any application. Claiming a domain means the company has FULL control on whoever created an account with that domain: no new accounts sign up with that domain (i.e. Trello, Bitbucket) IF is not provisioned through IdP or manually from the Atlassian Access interface not being able to create your own free instances of Jira Cloud, Confluence Cloud, etc from scratch being able to administer and access existing cloud products without having to contact the admins (they may have left the company and not being able to access and administer those products anymore) Not having control on how many users are licensed is a nightmare: for budgeting and foreseeing the amount of licenses in advance for having to justify to the your company the increase and the unexpected cost in the middle of the budgeted year for maintaining and justifying the debate about Atlassian being a company you can trust and that cares about customers

            GI added a comment -

            Short term they ask you to use the API to deactivate which breaks the idp link so you can move them

            @Adam England this is interesting in my case.

            Does this mean that the provision breaks when you deactivate an account in Atlassian Access with the APIs when a user NOT provisioned with your IdP signed up trough the Trello home page?

            Thanks

            GI added a comment - Short term they ask you to use the API to deactivate which breaks the idp link so you can move them @Adam England this is interesting in my case. Does this mean that the provision breaks when you deactivate an account in Atlassian Access with the APIs when a user NOT provisioned with your IdP signed up trough the Trello home page? Thanks

            @Adam England - "Long story short - they can deactivate your users with a ticket, pretty quickly if you have a list of them. "

            This part is interesting, can you elaborate more on what the outcome was? When you say deactivate users, what did that entail with regards to Trello access and other Atlassian services (like Jira, for example)? Did support remove them entirely from Atlassian, remove their account from Trello, or keep the account intact but limit their ability to use Trello?

            Non-billable policy sounded good at first but we'd prefer to keep SSO and sync.

            Mike Zaweski (OTL) added a comment - @Adam England - "Long story short - they can deactivate your users with a ticket, pretty quickly if you have a list of them. " This part is interesting, can you elaborate more on what the outcome was? When you say deactivate users, what did that entail with regards to Trello access and other Atlassian services (like Jira, for example)? Did support remove them entirely from Atlassian, remove their account from Trello, or keep the account intact but limit their ability to use Trello? Non-billable policy sounded good at first but we'd prefer to keep SSO and sync.

            We got stung by this recently during our go-live.

            We claimed our domains, setup SSO and started provisioning.  In our mind we have relatively few users who should be billed because we have the rest of the organization as free "customers".

            Then the trello users from 2017 started filtering in - Billing skyrocketed to ridiculous levels and we had to pull provisioning to move them back to unbilled.  Problem is, you start provisioning again - Atlassian moves them back to a billed policy.

            What we ended up doing is taking an export of the legacy trello users and carving them out of user provisioning into the non billable policies.  The iDP doesn't attempt to sync them again with rules on Okta.

            This last week we've had one user sign up with Trello, so I opened a ticket with Atlassian to find out how on earth we can manage this going forward.

            Long story short - they can deactivate your users with a ticket, pretty quickly if you have a list of them. 

            Short term they ask you to use the API to deactivate which breaks the idp link so you can move them - you have to reactivate them.

            Adam England added a comment - We got stung by this recently during our go-live. We claimed our domains, setup SSO and started provisioning.  In our mind we have relatively few users who should be billed because we have the rest of the organization as free "customers". Then the trello users from 2017 started filtering in - Billing skyrocketed to ridiculous levels and we had to pull provisioning to move them back to unbilled.  Problem is, you start provisioning again - Atlassian moves them back to a billed policy. What we ended up doing is taking an export of the legacy trello users and carving them out of user provisioning into the non billable policies.  The iDP doesn't attempt to sync them again with rules on Okta. This last week we've had one user sign up with Trello, so I opened a ticket with Atlassian to find out how on earth we can manage this going forward. Long story short - they can deactivate your users with a ticket, pretty quickly if you have a list of them.  Short term they ask you to use the API to deactivate which breaks the idp link so you can move them - you have to reactivate them.

            This wouldn’t be an issue if Atlassian Access was FREE.

            We already pay for licenses on each Atlassian tool for each user.

            Good security (which a sane user management is part of) shouldn't be an extra feature priced on top of the real service.

            Olivier Voortman added a comment - This wouldn’t be an issue if Atlassian Access was FREE. We already pay for licenses on each Atlassian tool for each user. Good security (which a sane user management is part of) shouldn't be an extra feature priced on top of the real service.

            Another big +1 here.

            We have just claimed accounts for our verified domain, enabled User Provisioning and SSO.

            Right after this, we found out that:

            • a customer is using the company mail also on another instance;
            • a customer had an unverified Trello account, so it didn't showed up as billable at the beginning, but it became billable after the claim.

            And now we are probably forced to use very uncomfortable workaround (create another account for the first user -> he will lose all historical data + have non billable policy on the second one -> will he be able to use SSO? who knows?)

            Sometimes it's very difficult to explain Atlassian decisions to our customers.

            Roberto Martignano added a comment - Another big +1 here. We have just claimed accounts for our verified domain, enabled User Provisioning and SSO. Right after this, we found out that: a customer is using the company mail also on another instance; a customer had an unverified Trello account, so it didn't showed up as billable at the beginning, but it became billable after the claim. And now we are probably forced to use very uncomfortable workaround (create another account for the first user -> he will lose all historical data + have non billable policy on the second one -> will he be able to use SSO? who knows?) Sometimes it's very difficult to explain Atlassian decisions to our customers.

            Instead of listening & supporting Atlassian Admins (who are often your biggest cheerleader in an organization), Atlassian has chosen to focus on revenue only. Making it more difficult to admin thousands of users won't in the end generate revenue, it'll force organizations to move to Atlassian's competitors. Atlassian–wake up and listen. Help us help you.

            Karen Rogalski added a comment - Instead of listening & supporting Atlassian Admins (who are often your biggest cheerleader in an organization), Atlassian has chosen to focus on revenue only. Making it more difficult to admin thousands of users won't in the end generate revenue, it'll force organizations to move to Atlassian's competitors. Atlassian–wake up and listen. Help us help you.

            Mike, you're absolutely right! There are no words to describe how unfortunate (f*cked up) Atlassian Access users are when it comes to free Trello signups.

            Atlassian staff, please raise this up the ladder.

            Kalin Uzhdrin added a comment - Mike, you're absolutely right! There are no words to describe how unfortunate ( f*cked up ) Atlassian Access users are when it comes to free Trello signups. Atlassian staff, please raise this up the ladder.

            Atlassian Access is a great add-on that allows user sync and SSO. Trello is a trap that's been sprung after subscribing to Access.

            Our organization has 3,500 users with high turnover rates (K-12 school system). Manually managing them in Atlassian is out of the question, and we want these users to SSO into public Jira portals for submitting tickets. We also would like a handful of admins to be tied to other products, also configured with SSO.

            According to Atlassian, it is impossible to prevent users in our domain from signing into Trello (free tier) with our domain, and when they do, they immediately become "billable" users in our Atlassian Access subscription. At no point was this described as an outcome anywhere in the documentation and discussion with Atlassian support prior to purchase.

            The only options that support has come up with are:

            1. Just pay more money. Pay for a higher Access tier every time your billable users increase because they signed into a free product that we never wanted in the first place
            2. Just don't use Atlassian Access. Don't sync your users or provide them SSO.
            3. Just forget about a consistent account syntax for your organization. Create a brand new org account for the user (AD, Google, student information system, these are all synced) and then delete their old one from Atlassian. Oh, then cross your fingers that they don't sign into Trello again with the new account.
            4. Just block access to Trello with your content filter. A sloppy solution that only works on specific devices and deprives users who have personal Trello accounts from using the service. 

            It is unbelievable and unacceptable that is actually a problem. It genuinely feels like a scam.

            Mike Zaweski (OTL) added a comment - Atlassian Access is a great add-on that allows user sync and SSO. Trello is a trap that's been sprung after subscribing to Access. Our organization has 3,500 users with high turnover rates (K-12 school system). Manually managing them in Atlassian is out of the question, and we want these users to SSO into public Jira portals for submitting tickets. We also would like a handful of admins to be tied to other products, also configured with SSO. According to Atlassian, it is impossible to prevent users in our domain from signing into Trello (free tier) with our domain, and when they do, they immediately become "billable" users in our Atlassian Access subscription. At no point was this described as an outcome anywhere in the documentation and discussion with Atlassian support prior to purchase. The only options that support has come up with are: Just pay more money. Pay for a higher Access tier every time your billable users increase because they signed into a free product that we never wanted in the first place Just don't use Atlassian Access. Don't sync your users or provide them SSO. Just forget about a consistent account syntax for your organization. Create a brand new org account for the user (AD, Google, student information system, these are all synced) and then delete their old one from Atlassian. Oh, then cross your fingers that they don't sign into Trello again with the new account. Just block access to Trello with your content filter. A sloppy solution that only works on specific devices and deprives users who have personal Trello accounts from using the service.  It is unbelievable and unacceptable that is actually a problem. It genuinely feels like a scam.

            "...there is no way to delete just your Trello account instead of your Atlassian account, as they are one and the same. On top of this, anyone from your organization can add Trello access to their Atlassian accounts at any time and we do not have the ability to manage Trello product access from your Atlassian Organisation at this time."

            We have over 150 active Trello accounts and the fact that our team is unable to delete those instances is unacceptable. The only solution would be to delete the entire Atlassian account and that makes no sense to us. 

            In this use case, Trello hasn't been approved by IT or our infosec team and this can become a legal nightmare if there is potential proprietary and/or sensitive data that is managed on those boards. 

            I'm not sure what more it takes for this "suggestion" to implement much sooner than later. 

            Jeff Gunawan added a comment - "...there is no way to delete just your Trello account instead of your Atlassian account, as they are one and the same. On top of this, anyone from your organization can add Trello access to their Atlassian accounts at any time and we do not have the ability to manage Trello product access from your Atlassian Organisation at this time." We have over 150 active Trello accounts and the fact that our team is unable to delete those instances is unacceptable. The only solution would be to delete the entire Atlassian account and that makes no sense to us.  In this use case, Trello hasn't been approved by IT or our infosec team and this can become a legal nightmare if there is potential proprietary and/or sensitive data that is managed on those boards.  I'm not sure what more it takes for this "suggestion" to implement much sooner than later. 

            NSP IT added a comment - - edited

            Not having this feature has derailed our Jira Cloud migration project days before we were to go live after weeks of work migrating data and workflows to Jira Cloud.  We'll have to renew our on-prem Server implementation for another year instead and watch this ticket closely.  If there's no resolution then we will be forced to find an alternative to Jira for our organization as the on-prem Server edition approaches end of support.  We can't justify unnecessarily spending tens of thousands of dollars for a feature we have no ability to manage cost on.

            The hardest part for me to understand is why this is even charged on a per-user basis instead of a single, low-cost flat fee for the extension/feature for an organization, which is what I have experienced with every other cloud service provider I've worked with – if they even charge at all!  Most offer SSO at no additional cost whatsoever.

            Here's what needs to happen:

            1) Add product management tools to be able to add/remove product access from "managed" users
            2) Allow the organization to block signup using claimed/managed domains

            NSP IT added a comment - - edited Not having this feature has derailed our Jira Cloud migration project days before we were to go live after weeks of work migrating data and workflows to Jira Cloud.  We'll have to renew our on-prem Server implementation for another year instead and watch this ticket closely.  If there's no resolution then we will be forced to find an alternative to Jira for our organization as the on-prem Server edition approaches end of support.  We can't justify unnecessarily spending tens of thousands of dollars for a feature we have no ability to manage cost on. The hardest part for me to understand is why this is even charged on a per-user basis instead of a single, low-cost flat fee for the extension/feature for an organization, which is what I have experienced with every other cloud service provider I've worked with – if they even charge at all!  Most offer SSO at no additional cost whatsoever. Here's what needs to happen: 1) Add product management tools to be able to add/remove product access from "managed" users 2) Allow the organization to block signup using claimed/managed domains

            Robert Ross added a comment - - edited

            Two years, almost 500 votes and still no movement on this issue.  The way this works, if a user is "managed" and they create an unwanted account, even Site Admin cannot remove them.  We have to log support tickets to remove the unwanted accounts.  This is just a very sloppy attempt at enticing users to test out products, but these are not personal users.  These are managed paid Enterprise accounts and we deserve the right to restrict access to services and eliminate unwanted security vectors for Atlassian products we choose not to use as a corporation.

            Robert Ross added a comment - - edited Two years, almost 500 votes and still no movement on this issue.  The way this works, if a user is "managed" and they create an unwanted account, even Site Admin cannot remove them.  We have to log support tickets to remove the unwanted accounts.  This is just a very sloppy attempt at enticing users to test out products, but these are not personal users.  These are managed paid Enterprise accounts and we deserve the right to restrict access to services and eliminate unwanted security vectors for Atlassian products we choose not to use as a corporation.

            +1

            chen.g added a comment -

            In our domain that I manage, the regular users are have the ability to opening an organization and products.
            The options to block this ability is necessary to manage the our organization.

            Please helps us to improve our control on the users help us to block this options.

            chen.g added a comment - In our domain that I manage, the regular users are have the ability to opening an organization and products. The options to block this ability is necessary to manage the our organization. Please helps us to improve our control on the users help us to block this options.

            chen.g added a comment -

            In our domain that I manage, the regular users are have the ability to opening an organization and products.
            The options to block this ability is necessary to manage the our organization.

            Please helps us to improve our control on the users help us to block this options.

            chen.g added a comment - In our domain that I manage, the regular users are have the ability to opening an organization and products. The options to block this ability is necessary to manage the our organization. Please helps us to improve our control on the users help us to block this options.

            Completely agree with Joe Delat.  The ability to discover, manage, and stomp on "Shadow IT" sites is mandatory for any large organization.  We need to be able to reject anyone creating a 'test' site with their 'managed' account, and direct them to the organizational offerings.  This is both a billing/license count issue and a Data Security, Compliance and Governance issue.

            Tracy Stimac added a comment - Completely agree with Joe Delat.  The ability to discover, manage, and stomp on "Shadow IT" sites is mandatory for any large organization.  We need to be able to reject anyone creating a 'test' site with their 'managed' account, and direct them to the organizational offerings.  This is both a billing/license count issue and a Data Security, Compliance and Governance issue.

            EMPrice added a comment -

            Please implement this feature as soon as possible.  This is a huge security risk for our company, as users are inadvertently creating sites that they do not know how to manage.

            EMPrice added a comment - Please implement this feature as soon as possible.  This is a huge security risk for our company, as users are inadvertently creating sites that they do not know how to manage.

            Uprising? I'm sure you meant "Russian invasion".

            Scott Paist added a comment - Uprising? I'm sure you meant "Russian invasion".

            With the uprising in Ukraine it is imperative that Jira administrators control permissions and sites.  Please work this issue soon!

            Ann Rumenapp added a comment - With the uprising in Ukraine it is imperative that Jira administrators control permissions and sites.  Please work this issue soon!

            and 1 more

            Matijs Visser added a comment - and 1 more

            Vini S (Inactive) added a comment - https://getsupport.atlassian.com/browse/JST-733100

            We have people rather consistently creating thier own instances under our managed domain, and it causes not only security risk but process nightmare as they then create business work streams we cannot manage and potentially have to pay for. This feature is long overdue.

            beacon.grayson added a comment - We have people rather consistently creating thier own instances under our managed domain, and it causes not only security risk but process nightmare as they then create business work streams we cannot manage and potentially have to pay for. This feature is long overdue.

            Casey added a comment -

            I'm both surprised and disappointed that this isn't resolved yet. Administering Trello is not efficient at all for my team, and quite frankly, I will not allow a renewal unless a proper solution is implemented. 

            Casey added a comment - I'm both surprised and disappointed that this isn't resolved yet. Administering Trello is not efficient at all for my team, and quite frankly, I will not allow a renewal unless a proper solution is implemented.  

            Atlassian's lack of a solution for this is super aggravating.

            Maybe the revenue stream from users signing try a product, only to end up as extraneous users that are billed for Atlassian Access, is just too lucrative. That's a pretty screwy business model.  

            It's ridiculous that this issue has languished so long without being addressed. That certainly paints Atlassian as just another vendor out to maximize profits, despite all their marketing and friendly, down under charm.

            I'm happy to pay for licensed users, but only for the users we really need to license.

            C'mon folks!!  Fix this already!!!

            Jim Anderson added a comment - Atlassian's lack of a solution for this is super aggravating. Maybe the revenue stream from users signing try a product, only to end up as extraneous users that are billed for Atlassian Access, is just too lucrative. That's a pretty screwy business model.   It's ridiculous that this issue has languished so long without being addressed. That certainly paints Atlassian as just another vendor out to maximize profits, despite all their marketing and friendly, down under charm. I'm happy to pay for licensed users, but only for the users we really need to license. C'mon folks!!  Fix this already!!!

            Is there any update this case?

            I just received an unexpected bill from Atlassian because of 96 people who have left the company but who are still registered at Trello.

            Colin Sydes added a comment - Is there any update this case? I just received an unexpected bill from Atlassian because of 96 people who have left the company but who are still registered at Trello.

            +1 Please give us this control!  Our students and faculty should not be able to add products to our Atlassian Cloud instance billing.  As if migrating to the cloud wasn't difficult enough...this adds insult to injury.

            Michael Price added a comment - +1 Please give us this control!  Our students and faculty should not be able to add products to our Atlassian Cloud instance billing.  As if migrating to the cloud wasn't difficult enough...this adds insult to injury.

            Agree, please enable.

            Nikita Simanenkov added a comment - Agree, please enable.

            I fully agree with Adrian Vital. We won't even consider Atlassian Access given this. We have more users with unneeded, legacy logins to Trello than access to our paid Atlassian products. Why would we pay extra for Atlassian Access for these Trello users that will continue to accrue over time – all outside our control?

            Ryan Beller added a comment - I fully agree with Adrian Vital. We won't even consider Atlassian Access given this. We have more users with unneeded, legacy logins to Trello than access to our paid Atlassian products. Why would we pay extra for Atlassian Access for these Trello users that will continue to accrue over time – all outside our control?

            It might be a good Idea to create tickets on their support and scalate it. Probably we won't do much about it and it is crazy having to get to that point. But they do not listen.

            Greivin Guevara added a comment - It might be a good Idea to create tickets on their support and scalate it. Probably we won't do much about it and it is crazy having to get to that point. But they do not listen.

            Adrian Vital added a comment - - edited

            Atlassian, 

            Please listen to your customers!  

            We are struggling here  not being able to manage our Atlassian Access bill.   

            We have thousands who see cools features in trello and Bitbucket and they sign up for free accounts  not even knowing this will cause our company to be charged.  It puts an unnecessary burden on Site Administrators to keep going after these users and kindly asking them to unsubscribe - many users don't know how to unsubscribe  causing us to  waste so much time explaining the 'why" the 'how'    over and over.    Some users don't even respond  and we are stuck with a bill we can't manage.     This is not a smart way to manage a business.   This is urgent.    Listen to you customers. 

             

            PS: creating a non-billing policy  (removing SSO) even temporarily is not option, please stop offering this is a solution.  It doesn't make sense from a security and point of view. 

            Adrian Vital added a comment - - edited Atlassian,  Please listen to your customers!   We are struggling here  not being able to manage our Atlassian Access bill.    We have thousands who see cools features in trello and Bitbucket and they sign up for free accounts  not even knowing this will cause our company to be charged.  It puts an unnecessary burden on Site Administrators to keep going after these users and kindly asking them to unsubscribe - many users don't know how to unsubscribe  causing us to  waste so much time explaining the 'why" the 'how'    over and over.    Some users don't even respond  and we are stuck with a bill we can't manage.     This is not a smart way to manage a business.   This is urgent.    Listen to you customers.    PS: creating a non-billing policy  (removing SSO) even temporarily is not option, please stop offering this is a solution.  It doesn't make sense from a security and point of view. 

            We are a large public transport company in the Netherlands and are waiting urgently for the release of this feature. We use Atlassian Access and we see users registering their business e-mail addresses with Trello and Bitbucket, resulting in Atlassian Access licenses. The only workarounds offered by Atlassian are kindly asking users no to do so (who's going to listen?) and creating a non-billing policy (which means loss of features like SSO). 
            The only real solution is full integration into Atlassian user management tools, making it possbile to simply revoke the Trello and Bitbucket products from users.

            Jeroen van den Berg added a comment - We are a large public transport company in the Netherlands and are waiting urgently for the release of this feature. We use Atlassian Access and we see users registering their business e-mail addresses with Trello and Bitbucket, resulting in Atlassian Access licenses. The only workarounds offered by Atlassian are kindly asking users no to do so (who's going to listen?) and creating a non-billing policy (which means loss of features like SSO).  The only real solution is full integration into Atlassian user management tools, making it possbile to simply revoke the Trello and Bitbucket products from users.

            Agree, please enable.

            Michael Sawyer added a comment - Agree, please enable.

            I am fairly disappointed this has not been addressed yet. Even the Atlassian support team are directing me to this Suggestion and upvoting on my behalf. Clearly shows I am not the first person to reach out to them with this issue. 

            max.bradshaw added a comment - I am fairly disappointed this has not been addressed yet. Even the Atlassian support team are directing me to this Suggestion and upvoting on my behalf. Clearly shows I am not the first person to reach out to them with this issue. 

            Why is this not done?  Why am I paying so much for Atlassian Access if I can't manage all of my users' accounts across all Atlassian products?

            Nate Cluett added a comment - Why is this not done?  Why am I paying so much for Atlassian Access if I can't manage all of my users' accounts across all Atlassian products?

            It's been almost two years in "Gathering Interest". I don't think they will do it soon

            Greivin Guevara added a comment - It's been almost two years in "Gathering Interest". I don't think they will do it soon

            selleos added a comment -

            When is this being rolled out?

            selleos added a comment - When is this being rolled out?

            This is a huge pain point for our organization when it comes to Trello.  Both users and administrators are completely powerless to get rid of trello access without terminating access to all licensed Atlassian products.  It results in us being charged for access license against our will, unless we break the sync and no longer use SSO for individual users.  this needs to be addressed immediately.  

            Jo Nakashima added a comment - This is a huge pain point for our organization when it comes to Trello.  Both users and administrators are completely powerless to get rid of trello access without terminating access to all licensed Atlassian products.  It results in us being charged for access license against our will, unless we break the sync and no longer use SSO for individual users.  this needs to be addressed immediately.  

            A user created an instance of their own and they've been unresponsive for several weeks now. 

            I can't imagine the pain that it would be we had to deal with 100 users like that. 

            This is an urgent need for our team...

            Jeff Gunawan added a comment - A user created an instance of their own and they've been unresponsive for several weeks now.  I can't imagine the pain that it would be we had to deal with 100 users like that.  This is an urgent need for our team...

            Preventing domain-managed accounts from setting up an entirely new Confluence/Jira site, and circumventing existing policies is a needed function for us as well.

            Michiel Spoor added a comment - Preventing domain-managed accounts from setting up an entirely new Confluence/Jira site, and circumventing existing policies is a needed function for us as well.

            This is a huge need in our organization. We absolutely support this

            Rory Strickler added a comment - This is a huge need in our organization. We absolutely support this

            Upvoting this one as well!  We're concerned not only about billing but Data privacy, governance, compliance, and shadow IT as mentioned already in this thread.

            Jeremy Long added a comment - Upvoting this one as well!  We're concerned not only about billing but Data privacy, governance, compliance, and shadow IT as mentioned already in this thread.

            It's really necessary!!!

            Vladyslav.Yarmoliuk added a comment - It's really necessary!!!

            This issue is really important to our enterprise customers not only to control "shadow IT" but it is a necessity because every piece of content that is created with an account from a domain of a company is in many countries legally speaking their property and responsibility, meaning they are liable for any and all content created with their accounts and therefore need to be able to access all content and restrict users with their domain accounts from creating certain types of content.

             

            To reach this, we need to provide:

            1. A way to allow Enterprises to control Access by groups or individuals to any or all of our applications connected via Atlassian Access. Ideally this works with a sync to groups to a directory used by the enterprise (e.g. AD Group Atlassian Jira Cloud gets access to Jira Cloud instance through Access)
            2. Ability to access any content created with any of their domain accounts on any platform, including personal confluence spaces and Trello Boards
            3. Being able to restrict the creation of personal spaces in confluence and Trello Boards for private use with company domain account.

             

            Björn Wiehe added a comment - This issue is really important to our enterprise customers not only to control "shadow IT" but it is a necessity because every piece of content that is created with an account from a domain of a company is in many countries legally speaking their property and responsibility, meaning they are liable for any and all content created with their accounts and therefore need to be able to access all content and restrict users with their domain accounts from creating certain types of content.   To reach this, we need to provide: A way to allow Enterprises to control Access by groups or individuals to any or all of our applications connected via Atlassian Access. Ideally this works with a sync to groups to a directory used by the enterprise (e.g. AD Group Atlassian Jira Cloud gets access to Jira Cloud instance through Access) Ability to access any content created with any of their domain accounts on any platform, including personal confluence spaces and Trello Boards Being able to restrict the creation of personal spaces in confluence and Trello Boards for private use with company domain account.  

            I wonder if the words "class action lawsuit" might trigger a response....

            Greg Schuler added a comment - I wonder if the words "class action lawsuit" might trigger a response....

            Joe Dolat added a comment -

            The ability to discover, manage, and stomp on "Shadow IT" sites is mandatory for any large organization. Especially true of one that has just started using Atlassian's enterprise solutions.  We need to be able to reject anyone creating a 'test' site with their 'managed' account, and direct them to the organizational offerings.  This is not just from a 'billing' standpoint, but from a Data Security, Compliance and Governance standpoint.

            Joe Dolat added a comment - The ability to discover, manage, and stomp on "Shadow IT" sites is mandatory for any large organization. Especially true of one that has just started using Atlassian's enterprise solutions.  We need to be able to reject anyone creating a 'test' site with their 'managed' account, and direct them to the organizational offerings.  This is not just from a 'billing' standpoint, but from a Data Security, Compliance and Governance standpoint.

            I'm totally agree with Rick Hadsall

            Bernat Real added a comment - I'm totally agree with Rick Hadsall

            @Rick Hadsall is spot on!

            Michael Roos added a comment - @Rick Hadsall is spot on!

             

            This is yet another example of Atlassian being tone-deaf to Enterprise customers. They just simply do not get large organizations. They're stuck in the four guys in a garage mentality.

            If a user from a work e-mail account that's managed - that is, synchronized with Atlassian Access from the identity provider - creates a free Bitbucket or Trello account (and this is VERY easy to do - click on the wrong link!), suddenly, they're billed in Atlassian Access forever with no way to avoid it even if they don't have access to Jira, Confluence, etc.  

            The workarounds don't work - for the reasons mentioned above. Simply put, if Access is a thing, then administration needs to work with all the billable tools that Atlassian offers in the cloud. Full stop, that's it.  Anything not working is a bug, not an enhancement.  If you can see Trello and Bitbucket, even if free tier, you need to be able to boot users off of those from the Admin panel or force-migrate them to a non-managed account separate from the work account. There needs to be the ability to restrict what non-admins can create - Jira tenants, Bitbucket accounts, Trello... whatever. 

            I can't believe I'm paying for tons of user accounts that aren't being used - empty Bitbucket and trello accounts that were clicked on once, are in the "free" tier, and forever consuming Atlassian Access licenses.  This is somewhat fraudulent. 

            Rick Hadsall added a comment -   This is yet another example of Atlassian being tone-deaf to Enterprise customers. They just simply do not get large organizations. They're stuck in the four guys in a garage mentality. If a user from a work e-mail account that's managed - that is, synchronized with Atlassian Access from the identity provider - creates a free Bitbucket or Trello account (and this is VERY easy to do - click on the wrong link!), suddenly, they're billed in Atlassian Access forever with no way to avoid it even if they don't have access to Jira, Confluence, etc.   The workarounds don't work - for the reasons mentioned above. Simply put, if Access is a thing, then administration needs to work with all the billable tools that Atlassian offers in the cloud. Full stop, that's it.  Anything not working is a bug, not an enhancement.  If you can see Trello and Bitbucket, even if free tier, you need to be able to boot users off of those from the Admin panel or force-migrate them to a non-managed account separate from the work account. There needs to be the ability to restrict what non-admins can create - Jira tenants, Bitbucket accounts, Trello... whatever.  I can't believe I'm paying for tons of user accounts that aren't being used - empty Bitbucket and trello accounts that were clicked on once, are in the "free" tier, and forever consuming Atlassian Access licenses.  This is somewhat fraudulent. 

            Completely agree with you comment David Kirkland

            Bernat Real added a comment - Completely agree with you comment David Kirkland

            I am in complete agreement with previous comments - this is basic functionality that needs to be implemented as soon as possible.  It's coming up on 2 years since this issue was first raised and we're still waiting.  Meanwhile Atlassian are happy to hit us with a price increase.

            David Kirkland added a comment - I am in complete agreement with previous comments - this is basic functionality that needs to be implemented as soon as possible.  It's coming up on 2 years since this issue was first raised and we're still waiting.  Meanwhile Atlassian are happy to hit us with a price increase.

            Dan Aussem added a comment - - edited

            We need Atlassian Access to work for Trello the same way it works for Jira.  Because we have all our company users provisioned for Jira and Jira Service Desk, we can't limit who has access to Trello to a subset of all company employees.  And all company employees become billable for Atlassian Access by Trello... Atlassian Access for Trello is a non-starter for us.

            Dan Aussem added a comment - - edited We need Atlassian Access to work for Trello the same way it works for Jira.  Because we have all our company users provisioned for Jira and Jira Service Desk, we can't limit who has access to Trello to a subset of all company employees.  And all company employees become billable for Atlassian Access by Trello... Atlassian Access for Trello is a non-starter for us.

            Yeah that's right - non-billable is a solid option IF you don't require those accounts to have SSO for your other products (ie support portal). Unfortunately the non-billable policy does not allow for SAML/SSO.

            Tom Anderson added a comment - Yeah that's right - non-billable is a solid option IF you don't require those accounts to have SSO for your other products (ie support portal). Unfortunately the non-billable policy does not allow for SAML/SSO.

            tleclerc added a comment -

            While that is a solid workaround, it does not work for Managed Accounts, as they cannot be added to a Non-billable Atlassian Access Authentication Policy.

            tleclerc added a comment - While that is a solid workaround, it does not work for Managed Accounts, as they cannot be added to a Non-billable Atlassian Access Authentication Policy.

            As mentioned before, a great solution for many cases involving this issue, especially the ones involving Trello accounts, is to create a Non-billable Atlassian Access Authentication Policy, as described here: Understand Authentication Policies.
            Can it be added to the FR description as a workaround?
            Thanks!

            Luciano Bongiorni (Inactive) added a comment - As mentioned before, a great solution for many cases involving this issue, especially the ones involving Trello accounts, is to create a Non-billable Atlassian Access Authentication Policy , as described here:  Understand Authentication Policies . Can it be added to the FR description as a workaround? Thanks!

            tleclerc added a comment -

            As a smaller business, managing users is highly critical for us.  We do not have the resources to add additional Atlassian Access licenses to our account and it is hard to even justify when 2/3 of our used licenses are from managed users who signed up for a free trello account BEFORE we set up the managed accounts.   A fair number of those users no longer access Trello and have not for multiple years, but I am not able to remove the license from them and we are constantly at our license capacity because of this.

            Please add this feature soon to allow this functionality.

            tleclerc added a comment - As a smaller business, managing users is highly critical for us.  We do not have the resources to add additional Atlassian Access licenses to our account and it is hard to even justify when 2/3 of our used licenses are from managed users who signed up for a free trello account BEFORE we set up the managed accounts.   A fair number of those users no longer access Trello and have not for multiple years, but I am not able to remove the license from them and we are constantly at our license capacity because of this. Please add this feature soon to allow this functionality.

            +1

            Having the same issues with Trello users and users with their own Jira instances showing up in our list. This is frustrating. 

            Clifford Hull added a comment - +1 Having the same issues with Trello users and users with their own Jira instances showing up in our list. This is frustrating. 

            Tom Anderson is absolutely right on this one. Please subscribe to Atlassian Access so you can MANAGE your users, not.

            Michael Roos added a comment - Tom Anderson is absolutely right on this one. Please subscribe to Atlassian Access so you can MANAGE your users, not.

            This is a ludicrous issue.

             

            We have ~200 users with Trello accounts, the majority free.

            We want these users (and all of our other staff) to have customer access to Service Management portal.

            In addition, approx 60 of the users with Trello accounts are no longer using the product.

             

            We are now faced with having to PAY for an Atlassian Access license, for the FREE Trello users to access the FREE Service Management portal, while the other 200 staff attract no charge.

            Worse still, we have to pay for 60 licenses for people who are still on staff who have used Trello in the past but are no longer using it, with no way to shut down their account now that it is managed. This is absolutely ridiculous and a huge waste of money for us (approx 1/3 of our Atlassian Access bill for defunct instances).

            Tom Anderson added a comment - This is a ludicrous issue.   We have ~200 users with Trello accounts, the majority free. We want these users (and all of our other staff) to have customer access to Service Management portal. In addition, approx 60 of the users with Trello accounts are no longer using the product.   We are now faced with having to PAY for an Atlassian Access license, for the FREE Trello users to access the FREE Service Management portal, while the other 200 staff attract no charge. Worse still, we have to pay for 60 licenses for people who are still on staff who have used Trello in the past but are no longer using it, with no way to shut down their account now that it is managed. This is absolutely ridiculous and a huge waste of money for us (approx 1/3 of our Atlassian Access bill for defunct instances).

            Any update on this? As Tony mentioned above this is a company and security risk for us too. Why hasn't this been addressed yet? This ticket has been open since 2017!

            Kareem Judie added a comment - Any update on this? As Tony mentioned above this is a company and security risk for us too. Why hasn't this been addressed yet? This ticket has been open since 2017!

            This is a company and security risk that should be mitigated.

            Tony Ventura added a comment - This is a company and security risk that should be mitigated.

            Hi,

            @AtlassianTeam, could you share with us some information on your roadmap for these features?

            Thank you.

            Véronique added a comment - Hi, @AtlassianTeam, could you share with us some information on your roadmap for these features? Thank you.

            Any update on this?
            We are also experiencing all issues presented in previous comments:
            1. Unable to prevent users from creating Trello accounts with domain emails.
            2. Billed on Atlassian Acesss for free Trello accounts created using the domain mail.
            3. Unable to prevent users from creating new sites with their domain email (and no control of those sites after they are created).

            The security related points 1 and 3 have the highest impact for us.

            Admin Matias Arranz Garcia added a comment - Any update on this? We are also experiencing all issues presented in previous comments: 1. Unable to prevent users from creating Trello accounts with domain emails. 2. Billed on Atlassian Acesss for free Trello accounts created using the domain mail. 3. Unable to prevent users from creating new sites with their domain email (and no control of those sites after they are created). The security related points 1 and 3 have the highest impact for us.

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

                Created:
                Updated:
                Resolved: