Challenges of Connecting Slack and Microsoft Teams | convly

Toggle menu<br>All articles In this article

Bridge type - user management

“Other side” users

Asymmetrical features and limits

Architecture

Conclusion

FAQ

We live in a world where most tools are connected, either natively or through connectors like Zapier, Make, or n8n.

It's become natural to open a newly adopted tool, check its available integrations, and wire it into your existing stack.

Natural for most tools, yes, but surprisingly not for the collaboration tools themselves. Slack, Teams, Google Chat, WhatsApp, Discord: none of them offer a native way to connect to each other.

Why? Most likely because they see each other as competitors. Their vendors want to maximize seat subscriptions, and connecting to a rival platform could mean fewer seats sold.

We've already covered the different options to connect Slack and Teams in this article. This time, we'll dig into the obstacles you'll face when building a custom Slack↔Teams bridge yourself.

Bridge type - user management

The first thing to define, because it shapes the entire project, is the type of bridge you're building.

From far away, connecting Slack and Teams can look straightforward. In reality, there are many ways to do it, and none of them are obvious.

Here are the main options, with a focus on how each represents "other side" users:\

Dual licenses on both sides

Every user needs both a Slack and a Teams license, whether they use them or not. This delivers a symmetrical experience on both sides, but it's the most expensive option.

Dual licenses on one side only

Just one side (Slack or Teams) holds dual licenses. This gives a smooth experience on that side, while the other still has to manage "absent" users. A middle-ground option cost-wise, and the one convly chose.

No dual licenses

No user holds a dual license. "Absent" users must be handled on both sides via dedicated apps. This has the lowest running cost, but a suboptimal experience on both sides, and it requires installing an app for each new external company you communicate with.

Multiple apps

A more exotic approach, representing "other side" users through multiple apps. It can work when only a limited number of users need representing, but it gets messy fast otherwise.

Multiple guests

This can sound like the ideal way to represent "other side" users, but there's a catch. Guest users aren't unlimited on Slack, and they usually can't be created programmatically. Best suited to cases where the user list stays fairly static.

"Other side" users

By "other side" or "absent" users, we mean users who are on the other collaboration platform: Teams users seen from Slack, or Slack users seen from Teams.

In most scenarios, these users have to be represented on a platform where they don't actually exist. How to represent them is essential, and it comes with a whole set of related questions:

How do you materialize their messages?

How do you initiate DMs with them?

How do you represent DMs exchanged with them?

How do you represent their shared files and images?

How do you add or remove them from channels?

How do you tell whether they're actually part of a channel?

How do you represent their reactions?

And many more like these. Each question comes with its own specifics to handle, and the answers can change depending on the Slack or Teams license in play, or with API updates.

Asymmetrical features and limits

Once you've chosen your bridge type to connect Slack and Teams and defined how to represent absent users, you can start looking at the platform-specific challenges.

Slack and Teams are both collaboration tools where, for the most part, people exchange chat messages, so on the surface they look equivalent. But when you get into the details, each has its own specifics that can't be worked around.

Channels, group chats, multiple DMs, meeting chats

On Slack, it's all about "channels." Teams, on the other hand, has several chat types: channels (which don't really behave like Slack channels), group chats (named or unnamed) that are actually closer to Slack channels, multiple DMs, and meeting chats. Part of the challenge is deciding whether to link them and, if so, how, accounting for the specifics of each chat type.

Threads and replies

Slack is well known for threading across all messages, which can confuse new joiners. In Teams, threads exist only in channels. In "chats," you only get standard "replies." Defining the workflow logic to keep them in sync gets tricky once you account for every sub-case: a message is deleted, forwarded, edited, or carries reactions.

Files and images

Slack handles images simply, storing them within its own infrastructure. On the Teams side, all shared content relies on SharePoint and OneDrive. That sounds minor, but there's real complexity behind it: whether to use OneDrive or SharePoint depends on the context (the chat type), the right people need permissions to access each file,...