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

            Olivier GRALL added a comment - - edited

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

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

            Mark Crum added a comment -

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

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

            Dana Frost added a comment -

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

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

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

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

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

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

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

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

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

             

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

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

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

            WE NEED THIS FEATURE.

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

            Hi Griffin,

             

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

             

            Thanks,

            Valentin

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

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

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

            Tim Leclerc added a comment - - edited

            Hi Griffin -

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

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

            Hi everyone,

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

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

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

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

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

            Best,

            Griffin

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

            Krista added a comment -

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

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

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

            Trello MUST be considered in phase 1....

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

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

            This is completely unacceptable and very unprofessional from Atlassian. 

            Atlassian is selling:

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

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

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

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

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

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

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

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

            Both of the 2 offered workarounds are not viable:

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

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

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

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

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

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

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

            Roberto Martignano added a comment - - edited

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

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

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

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

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

            luke west added a comment -

            I am cynical.

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

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

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

             

             

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

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

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

            Andrew Wright added a comment - - edited

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

             

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

             

            These are the ones that need urgently addressing!

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

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

            There may be contractual issues with this. 

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

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

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

            C'mon!!

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

             

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

            Great to hear

            darleneashleigh.jeter added a comment - Great to hear

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

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

             

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                Created:
                Updated:
                Resolved: