Switching between organizations in Microsoft Teams can be a chore, especially if you are participating in multiple chats.
This can be especially painful if you are a full member (as opposed to an "external guest") of multiple organizations. The app will often force you to sign out and sign back in when you switch. It's also impossible to glance up at two different calendars to see what events are coming up as you can't have both organizations visible at the same time on the same screen.
Or can you?
In a nutshell, the idea is to run two different instances of the Teams desktop application under two different Windows user accounts.
One of the accounts will be your default Windows account. The second account will likely be some sort of dummy account. I re-used my "Little Bobby Tables" local account that I created for testing low-privileged SQL Server access:
In the steps below, I use "bobbyT" when referring to the second user account. You can name your second user account whatever you want; I'm using "bobbyT" in my instructions to keep things easier to follow.
- Create an additional local user account (e.g., bobbyT)
- Log into Windows as bobbyT and launch Teams (only need to do this once)
- Log out
- Log in with your normal account
- Launch Teams as normal
- Navigate to
C:\Users\bobbyT\AppData\Local\Microsoft\Teams\current\(or just search Teams.exe with Everything)
- Shift-right click on
Teams.exeand choose "Run as different user"
- Enter your credentials for the bobbyT local account
- Log in to Teams with the credentials for your other organization
Note that you may have to provide your credentials for the other organization more frequently than for your primary user account (e.g., after each reboot). I tend to open both instances and leave them up split screen on one of my monitors while I'm developing
If you've done everything correctly, you should have two instances of Microsoft Teams running, each signed into a different organization.
Be aware that when you are running two different instances of Teams in two different Windows accounts that those instances are executing in two different execution environments. That can result in some seemingly odd behavior, such as I documented in the following article: