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, size limits have to be respected, and so on.
- Differences in limits
Then there are the raw limits to manage: maximum message size, maximum file size, the maximum number of users per group chat or channel, the number of reactions per message, and more. Depending on the case, you can sometimes find a trade-off. Otherwise, the errors have to be handled.
Architecture
The business complexity described above is one thing, but linking Slack and Teams doesn't stop there. It also demands a serious architecture design to handle many of the following concerns.
- Low latency
One of the most important. It's critical that messages exchanged between Slack and Teams travel as fast as possible, despite the adaptation step needed to match the other platform's format. Here we're talking in milliseconds.
- Scalability
The necessary counterpart to low latency. The architecture has to absorb a large and growing volume of messages and users. Here we can be talking in millions of messages.
- API agnostic
Sitting between the Slack and Teams APIs, the architecture has to connect to both, knowing they work differently. Slack is standard REST, while Teams is REST through Microsoft Graph, with several services to account for (some of them overlapping).
- Error and retry management
Since most Slack/Teams connectivity is real time, over webhooks, solid error and retry handling is essential to ensure no message is lost or duplicated. That can call for multi-threaded queues, with sequencing to manage.
- Security and encryption
Last but not least, security has to be built in from the very start, so the project meets current industry standards: minimum permissions required, minimum data stored, and everything encrypted.
Conclusion
As we've seen throughout this article, building a Slack↔Teams connector is a large project, with many aspects to weigh in order to bridge the two platforms' significant differences: user management and experience, features mapping, architecture, security, and scalability. All without forgetting that both APIs keep changing over time. Or, if you'd rather not take on a project like this yourself, you can let convly handle it all for you. We've built up deep experience running a Slack↔Teams sync platform that takes user experience and security seriously.