Managing Trello accounts from admin.atlassian.com

[#1]

This page originally appeared on confluence.atlassian.com and was first published in February 2020.

We are integrating Trello managed accounts with your Atlassian organization. If you’re an organization admin, read on for more details of how this integration impacts your organization and how to manage your Trello users throughout this process.

What’s happening?

In early 2020 we began the process of integrating Trello with Atlassian accounts. This integration enables organization admins to view and manage their organization’s Trello users from admin.atlassian.com, in a similar manner as their Jira and Confluence users.

As an organization admin, you will be able to edit, deactivate, and delete these managed accounts and profile changes will be reflected within Trello. Your organization’s authentication policies (SAML single sign-on, enforced two-step verification, password policy, etc.) will automatically apply to their accounts.

If your organization has SAML configured, these Trello users must have a user identity in your identity provider to be able to log in with SAML.

Who is impacted?

Only Trello accounts using a company email with a verified domain are impacted, and their accounts will soon be immediately visible and manageable from your organization.

In the past, we’ve allowed these Trello users to voluntarily connect their Trello accounts to their Atlassian account from a banner on Trello in their web browser. Moving forward, users' Trello accounts will be automatically connected to their managed Atlassian account. We will create an Atlassian account for any users that do not already have one, and those users will receive an email informing them that an Atlassian account has been created for them. Users who are logged in to Trello will stay logged in and be prompted to finish connecting their Trello account to their Atlassian account. If users don’t finish this onboarding process while logged in, they will need to finish the process the next time they try to log back in. You can learn about the end-user onboarding experience in the Trello end-user experience section of this doc.

This change will not affect:

• Trello users with only personal emails on their account or only emails in domains that are not verified

• Trello Enterprise users that are already claimed by a Trello Enterprise admin

Audit Trello users in your organization

To audit Trello users in your organization before Jun 22, 2020, use the following steps:

We have added a CSV file you can download to get details on Trello users that are new to your managed accounts. To download the CSV file:

1. Go to your organization at admin.atlassian.com.

2. Click Directory > Managed accounts.

3. From the message at the top, click Export accounts with Trello product access.

 To audit Trello users in your organization after Jun 22, 2020 , use the following steps:

1. Go to your organization at admin.atlassian.com.

2. Click Directory > Managed accounts.

3. Click the Export accounts button.

Retaining control over your Trello users

If you want to retain control over your Trello users, you don’t need to do anything. You can view and manage these Trello users from your organization directory.

Preventing your Trello users from using Trello with a company account

If you do not want to manage your Trello users from the context of your organization, you can do the following:

1. Ask your end users to remove your company’s email address. You can change your Trello users' email addresses from admin.atlassian.com to a users’s non-Company owned email address. This will effectively un-manage those users and they will not count towards your Access bill. You should work with your user to determine the best non-Company owned email address for their Trello account. You can learn more about working with your users to change their email addresses in the Working with your Trello users section of this doc.

2. Deactivate your Trello users before June 1. When you deactivate a user, they’ll immediately lose access to all of their Atlassian products, including Trello. To keep using Trello, they will have to create a new account on another email address. That account would not have access to the boards on the organization-owned Atlassian account that you deactivated. You can learn more about deactivating your users in the Deactivating Trello access for users with access to multiple products section of this doc.

Deactivate instead of delete your Trello users

We don't recommend you delete your users. Deleting your Trello users could result in their account and boards, including personal boards, being permanently deleted. Furthermore, deleting users isn’t an effective way to prevent Trello usage because users can sign back up for Trello with the same email.

Atlassian Access customers with Trello users

If a user only uses Trello and doesn’t use any of your other Atlassian products, we will count them towards your Atlassian Access bill. 

If you don’t want to pay for these additional users, you can change their email addresses to a non-company owned email address or deactivate their accounts. Either action will remove them from your Atlassian Access bill. Read more about how Trello impacts your Access bill. You can learn more about changing users' emails addresses or deactivating users in the Preventing your Trello users from using Trello with a company account section of this doc.

Organizations with SAML single sign-on

If your organization uses SAML single sign-on, your Trello users must have a user identity in your identity provider to be able to log in with SAML. Otherwise, they may run into an error when trying to authenticate via your identity provider.

Working with your Trello users

Some users may have personal as well as work content in their Trello accounts. Deactivating those users' accounts would result in them losing access to all of their content in all Atlassian products, including their personal content.

If you don’t mind those users having access to Trello for personal content, you can change their email from admin.atlassian.com to non-company owned email address to un-manage them, rather than deactivating. This will ensure that they can continue to use Trello for personal use cases, while still removing them from your Access bill and organization.

Please note that changing a user’s email to a non-company owned email address to un-manage them will only work if:

• they have completed the onboarding steps shown above in the Trello end-user experience section of this doc. If they have not yet completed those steps, work with your users to ensure they have completed the steps first, and then change their email address to a personal one.

• users are not provisioned via SCIM. If you use SCIM to provision users, you will need to deactivate those users and create new Atlassian accounts for those users in your identity provider. Then, you can give the new Atlassian accounts access to the products you want those users to have. 

Trello users that were using company-owned email addresses will be unable to login to Trello if you have deactivated their account. If these users contact support, we will provide them with your contact information so that you can work with them to reactivate their account and change it to a personal, non-company owned email address. Alternatively, you can proactively work with users to change their emails to a personal email address from admin.atlassian.com rather than deactivating them.

Deactivating Trello access for users with access to multiple products

While working with your users to change their email addresses, or deactivating them, will ensure they they lose access to Trello, they may also lose access to the other Atlassian products in your organization. For example, if someone is a user of both Jira Service Desk and Trello, you will not be able to disable their Trello access while retaining their Jira Service Desk access.

One solution to this issue is to deactivate the account and create a new one with a different work email address, and give it access to the non-Trello products you’d like the user to have access to. However, the Trello user will both lose access to all of their Trello content, and still be able to sign back up for Trello with the new work email address at any point, so you may need to work with end-users to move their personal boards off of their managed account and to refrain from signing up for Trello on their managed work email address.

Preventing users from signing up for Trello in the future

There are two ways to prevent users from signing up for Trello in the future.

1. If you use SAML SSO in your organization, you can remove the user’s work email address from your Identity Provider. If you do this, the user will be unable to login to Trello, which will prevent them from signing up with the same email address in the future. However, this will also mean that the user is unable to login to other Atlassian products in your organization.

2. Whether or not you use SSO, you can deactivate their Atlassian account from admin.atlassian.com. This will ensure that users are unable to access Trello in the future with the same email address, but will also mean they can’t access any other Atlassian products in your organization.

It is not possible to prevent users from signing up for Trello in the future with their work email address without also removing their access to other Atlassian products that they use the same account with. If you need the user to retain access to other products, they will be able to sign up for Trello again in the future. If a user signs up for Trello with their managed work email address, they will show up in your organization administration settings at admin.atlassian.com. At that point, you can work with the user to change their email address to un-manage them, or deactivate them.

Deleting Trello accounts as a last resort

So far, we have covered:

1. Working with your users to change their email addresses to a personal email address, so that they are un-managed and removed from your Access bill and organization administration panels.

2. Deactivating a user’s Atlassian account to remove their access from Trello (and all other Atlassian products) and prevent them from signing up for Trello in the future.

3. Removing users from your Identity Provider to ensure that they are unable to login to Trello (and all other Atlassian products) now and in the future.

These three options are preferable to deleting Trello users' accounts because they prevent users from losing access to their personal content and from signing up for Trello again in the future. Deleting accounts may, in rare cases, make sense if you require that all of the user’s Trello content be destroyed. Note that this may include all of the user’s personal Trello content as well as work content associated with that account, depending on how the user was using Trello.

If Trello users contact Atlassian about losing their content or about their account being deleted, we will provide them with the contact information of their organization admins to recover their content. After 14 days, admins will not be able to undo an account deletion, and we will not be able to recover any content that was destroyed through the deactivation.

Trello end-user experience

The rest of this post has answers to commonly-asked questions about the Trello end-users' experience.

Starting in June 2020, domain-claimed Trello users will see a banner when they use Trello from a web browser. The exact experience that users see depends on whether:

• They are already logged in to Trello

• They have not yet logged in to Trello

Trello users that are already logged in to Trello

If they are logged into Trello already, they can finish setting up their Atlassian account by following the instructions they’ll see in a banner.

1. We let your users know about their new Atlassian account.

2. After clicking Continue in the previous screen, they will see a button to authenticate their Atlassian account.

3. After clicking Continue in the previous screen, we’ll direct your users to an Atlassian account login or signup page.

4. Once they’ve logged in or signed up for their Atlassian account, we return them to Trello where they can see their new Atlassian account profile that displays in all Atlassian cloud products they use.

5. If they were unable to complete the flow in steps 1-4, they can complete it anytime by clicking the banner at the top of the screen.

Trello users that are not logged in to Trello

They will need to finish setting up their Atlassian account the next time they try to log in to Trello.

1. When they try to log in to Trello they will see a message informing them that they can’t log in and that we’ve sent them an email with instructions.

2. That email will explain that their account is now managed, and will provide a link to finish setting up their managed account. Following that link will launch a short process to connect their accounts.

If you enforce SSO for your managed accounts, then users will be blocked from completing these steps, and will see an error from your company’s SSO provider (like Okta). They may have to contact you and ask to be added to your organization’s group in your SSO provider. Once you have added those users to your SSO provider, they will be able to complete the steps and log in with SSO.

 3. We let your users know about their new Atlassian account.

4. After clicking Continue in the previous screen, they will see a button to authenticate their Atlassian account.

5. After clicking Continue in the previous screen, we’ll direct your users to an Atlassian account login or signup page.

6. Once they’ve logged in or signed up for their Atlassian account, we return them to Trello where they can see their new Atlassian account profile that displays in all Atlassian cloud products they use.

[Muhammad Fahad]

Thanks for the comprehensive article @Caitlin Cecic 

[David Meredith]

OR Atlassian could just not bill Trello (Free) users in Atlassian Access...?

The alternative is that you have the overly complex and frankly unmanagable workarounds described in this article.

Atlassian Access doesn't allow you to prevent an extra two thousand managed users signing up to Trello tomorrow, which would significantly increase the Atlassian Access bill... Unless you delete them from your identity provider and break their access to the rest of your Atlassian products.

I don't know if anyone is still reading this 8 month old article... But it makes me feel better to write this.

[ian]

Thanks @David Meredith I know this is an old thread but felt I needed to comment.

I'm not sure why it is so difficult to trigger a message to the user and the organisation admin when someone tries to sign up to Trello Free using a managed domain. That would be so much better and far less time consuming for everyone including Atlassian Support, than the process required after the fact. Especially when using SSO/SCIM with an IdP like Azure AD. Which requires input from Atlassian Support to deactivate these Trello accounts while maintaining the users access to JSM. 

We need users to be able to access our JSM help desk but don't want them adding to our Atlassian Access bill w/o some control over the process.

Thanks for the comprehensive article @Caitlin Cecic but please fix this Atlassian!

[Steven Drury]

Re: Preventing users from signing up for Trello in the future

From an administrator perspective these suggestions are horrible. 

Don't want someone to access Trello? Just delete their account??? Just create a new account for them with a different email?

I know this is an old thread, but without those challenges resolved this was not ready to incorporate into Atlassian Access. 

[Kerli Loopman]

In my ideal scenario, Free Trello users would not be considered in the billing calculation for Atlassian Access. Unfortunately, this is currently not an option for users with verified domains in conjunction with Atlassian Access.

I strongly recommend supporting and voting on the feature request outlined in this link: https://jira.atlassian.com/browse/CLOUD-11684.

I encountered this issue while implementing JSM for a customer. Prior to implementation, I conducted a comprehensive analysis with estimated pricing. Upon domain verification, we discovered that more users were being billed for Atlassian Access than initially estimated, putting me in a challenging position.

The suggestions provided by the community and support were as follows:

1. Deactivate or delete unnecessary accounts: Unfortunately, Trello accounts were managed, and we couldn't delete them.
2. Add users to a non-billable authentication policy: This was not an ideal solution as it would compromise the use of Atlassian Access functionalities like SSO for all users.
3. Remove all workspaces and boards from Trello accounts: While a viable solution, it was not the most efficient, as manually assisting each user in deleting their Trello data was not practical.

Ultimately, we opted for the following solution:

• Update users' email addresses for Trello accounts ✔️

Since we already had user provisioning set up and managed accounts, we couldn't directly update email addresses in the Atlassian Admin panel. Atlassian Support assisted by making those accounts unmanaged and updating their email addresses. We then re-synced the users with their correct email addresses, ensuring that the newly created users were not linked to Trello. Subsequently, we disabled the incorrect accounts, as their Trello data was not needed and they were no longer using it.

For users actively using Trello, an alternative would be to create a separate email address for Trello use or utilize their personal email address and add this to their account that is linked to Trello. This account can then be designated as a non-billable policy.

Luckily in our case the users didn't have data in Atlassian products with their Trello user account, which made this possible to create new accounts. Im not sure what to do if you do have data in other Atlassian products already associated with their account but I encourage you to contact support either way.