We shipped Mattermost-Microsoft Teams integration to early customers and had to iterate on our approach a few times to go from prototype to a scaling service. There’s some remaining bottlenecks that we’re posting here about to connect with experts able to advise.
1 - Scaling Mattermost for MS Teams connected experience with a per user subscription and rich notifications
In organizations where every user has access to MS Teams, but some users prefer to use Mattermost, keeping both clients open creates a “swivel-chair” effect. The MS Teams plugin is an extension to Mattermost that syncs chats bidirectionally between platforms, allowing users to stay in the platform of their choice while remaining connected to the entire organization.
Current Architecture
The plugin maintains a single, global /chats subscription to MS Teams. On each change notification for a chat message, the plugin attempts to get chatMessage using a delegated access token for one of the members of the chat. Messages sent from Mattermost use the same delegated access token to create a chat and send a chat message.
Limitations
A high volume of change notifications results in a high volume of API requests. Rich notifications would avoid the API requests, but unnecessarily include the contents of all chats.
Proposed Architecture
The plugin shall maintain a /users/{id}/chats/getAllMessages subscription to MS Teams for each connected user. Each subscription shall be configured to receive rich notifications (generating a unique public key per subscription) and allowing the application to directly access the contents of the message without further get chatMessage calls.
Limitations
A per-organization limit of 10,000 total subscriptions limits the potential deployment size. Duplicate change notifications (for each member in a chat) also adds processing overhead. Finally, overall API usage may also induce rate limiting for a high volume of active users.
Seeking Feedback on Scaling Mattermost for MS Teams connected experience:
We are seeking feedback on whether the proposed architecture is a viable approach, specifically the impact of the per-organization limit of 10,000 total subscriptions, and if there are alternative approaches to scaling this solution for MS Teams that better meets this limitation.
2 - Mattermost for MS Teams embedded experience with an MS Teams App
In environments where access to the full Microsoft Graph API is restricted, Mattermost can be embedded as an app directly accessible from the Teams sidebar.
Current Architecture
MS Teams effectively acts as a parent window to Mattermost in an iframe. The user must authenticate directly to Mattermost, after which they can largely use the application unimpeded.
Limitations
Mattermost doesn’t remain active when the user uses other features in MS Teams, nor has a way to relay notifications to the user even when actively using the embedded experience.
Proposed Architecture
The embedded experience shall be extended with application credentials that allows Mattermost to enumerate all MS Teams users and map them by email address to existing Mattermost users. A new account settings option allows Mattermost users to configure MS Teams as their primary platform, after which any notifications are relayed to MS Teams via activity feed notifications. Finally, support for SSO via MS Teams simplifies authentication and onboarding.
Limitations
A consent flow per user is required to allow the app to use the activity feed, unless the Azure administrator regularly accepts that consent on behalf of all new users.
Seeking Feedback on Mattermost for MS Teams embedded experience:
We are seeking feedback on whether the proposed architecture is a viable approach, specifically if there are other MS Teams apps that use the activity feed to notify users on MS Teams about new updates, or if there are alternative recommendations that the community recommends.