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 misspoke, suggesting there was no federated chat function within Teams. It turns out that Teams does include federated chat.
There is a key difference between how the two platforms handle federated chat. That difference explains why our initial internal tests indicated that federated chat was not there. Teams users need to understand how and why the two differ. Because it could confuse users, as it at first confounded us, we’ve provided an explanation. But first, let’s examine what we’re talking about.
Brace yourself; this s***’s going to get hairy.
Just what is federated chat?
Federated chat enables a user in one organization to chat with users outside their organization. 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. Open federation allows access to anyone not specifically blacklisted from that tenant. Closed federation means chats are limited to internal use and whitelisted domains.
To send a federated chat message to someone outside of your business, all you need 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 (in Teams or Skype).
Here at WSC, we typically invite our regular contacts and clients into various Teams extranets, so all are added as guests. This is a strategy that many not be useful for everyone, 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 external user access to a Teams or external site (like an extranet) hosted by a company.
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. When you send a message to someone who you’ve added as a guest to your tenant, he or she will receive a notification to their guest account, but not to their native account. Teams prioritizes guest accounts first and always sends a message to the guest account, if one exists. Teams will only send the message to the native account if there is no guest account. To anyone who uses client extranets, federated chat appears to be broken. You won’t see an error message because the system delivered a message; but it may have done so to an account that the intended recipient doesn’t check or doesn’t know he or she has. It’s a good idea to remind guests of this so they know to check their guest account for messages.
What to do?
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 guest and native accounts. That seems to be the best overall solution. Unfortunately, you can’t do that yet. Microsoft, are you listening?
One 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 communicate the existence of this issue to your team and design a plan to work with it, federated chat is a useful tool in Teams.