Brace yourself; this s***’s going to get hairy.
Not long ago, we posted an article “Teams/Skype Parity” about functional parity between Skype for Business and the parallel Microsoft Teams communications tools. In that post, we made a mistake, suggesting that federated chat was not working properly. It turns out that Teams does offer federated chat. There is a key difference between how the two platforms handle federated chat. however. That difference explains why our initial internal tests indicated that federated chat was not functioning properly. What we discovered is that there’s a crucial difference between the two services. Teams users really need to understand how and why the two differ. Because it could confuse users, as it at first confounded us, an explanation follows. But first, let’s examine what we’re talking about.
Just what is federated chat?
Federated chat enables a user in one organization to chat with users outside their organization when it is enabled (set to open federation or a whitelisted domain in a closed federation configuration. In Teams, that means a user can have a one-to-one chat with someone at a different company without having to add them as a guest user. And there’s the rub.
Open vs. closed federation
Open and closed federations are tenant-wide settings. Open federation will allow any person in a company to communicate with anyone at any other company that is also running open federation. However, a company can blacklist any domain it wants to exclude, or whitelist anyone it wants to all access. But that could become an administrative nightmare. The alternative is closed federation, which means chats are limited to internal use only. In that case, external domains ca be whitelisted. These, too, are tenant-wide settings.
So a tenant with open federation can communicate with any company that has either an open federation, or closed but has whitelisted your domain.
To send a federated chat message to someone outside of your business, all the end user has to do is create a new chat and type in a full SIP address (typically the same as their email address). The intended recipient needs to have open federation enabled, as well (Teams or Skype).
Here at WSC, we typically invite my regular contacts and clients into various extranets, so all are added as guests. This is a strategy that many not be useful for every user, but it works well for us.
Here’s where it gets tricky. In Microsoft Teams, “guest access” is how Microsoft refers to the act of adding an external user or granting and external user access to a Teams or external site (like an extranet) hosted by a company. In Teams, once you have been added as a guest to another tenant, a drop-down will appear in the top right corner of the Teams window. Toggling between these entities is known as changing tenants. As of this writing, it’s a cumbersome process that sometimes prompts users to re-enter usernames and passwords.
The Teams communication functions are intended to be a mirror image of Skype for Business. But Skype lacks many of the capabilities of Teams. For example, there is no guest access in Skype because it simply isn’t needed for Skype-only users.
Here’s the wrinkle. Teams supports federated chat as long as the person you are chatting with has not been added as a guest to your tenant. If you have been added as a guest, you won’t know the difference. The message will go to the guest account in your tenant and not to your native account. The preference is that it looks at guest accounts first and always sends the message to the guest account. Teams will only send the message outside of the tenant if there is no guest account. To anyone who uses client extranets, federated chat appears to be broken. You won’t see an error messages because the system delivered a message; but it may do so to an account that the intended recipient doesn’t check or doesn’t know he or she has.
So what’s the fix? Microsoft first needs to at least acknowledge to the end user that this is happening and either post an alert or a prompt — “Do you want to send to guest or external recipient?” But that’s a confusing function to label, so perhaps the message should be sent to both sender and intended recipient. That seems to be the best overall solution — but you can’t do that right now. Microsoft, are you listening?
The workaround is to continue to use Skype for Business, where it works because there’s no guest access. The lack of guest access makes for less complicated routing.
As long as you can find a way to clarify this single issue, federated chat does work in Teams.