I’ll save everyone the trouble of reading Sembly’s marketing copy about “AI-powered meeting summaries for every collaboration scenario.” Let’s cut to the chase: their Teams integration falls apart in breakout rooms. The documentation is predictably silent on this edge case, treating every meeting like a single, static conference call.
I’ve tried the obvious—installing the app at the tenant level, ensuring all users have licenses, and enabling the “Record automatically” setting. In the main meeting, it works (mostly). The moment you launch breakout rooms, Sembly either stops recording entirely or attributes all transcribed content post-breakout to the main room, creating a useless, garbled transcript. The “per-user” tracking feature seems to ignore the breakout room context completely.
Has anyone actually engineered a working configuration for this, or is the only reliable solution to run a separate Sembly instance *inside* each breakout room (which is, frankly, absurd)? I’m looking at the network traffic and it seems the bot gets confused when its own participant context is moved by Teams. Before I start writing a custom middleware bot to work around this, I wanted to see if the community has found a less cursed path.
—matt
No SLA, no problem.
I've spent a fair amount of time instrumenting and observing this exact failure mode. You're correct that the bot's participant context gets invalidated, but the core issue is deeper, it's an API limitation. The Graph API endpoints Sembly likely uses for onlineMeeting transcription don't have a real-time concept of dynamic sub-sessions like breakout rooms. The bot receives a single call roster and audio stream.
The workaround I've seen in a couple of large enterprises isn't a separate instance per room, it's even more baroque. They use a dedicated service account to rejoin the main meeting as a hidden participant *after* breakouts are launched, with the sole purpose of capturing that specific audio stream. It's terribly inefficient and you lose per-user attribution entirely.
Before you build middleware, check if your vendor has a "Direct Routing" or "stream capture" option that bypasses the Teams API altogether, pulling audio directly from a SIP endpoint. It's the only way I've seen to get clean, isolated streams for parallel sessions.
You're expecting a configuration fix for something that's fundamentally broken by design. Your network traffic observation about the bot's participant context being moved is correct, but the problem starts with Sembly selling a feature their underlying platform can't support. The Graph API limitations user918 mentioned are the real culprit, and no amount of tenant-level installs or license assignments will change that.
The idea of running a separate instance per breakout room isn't absurd, it's the logical endpoint of their flawed architecture. It's also completely unsustainable from a cost and management perspective. Your instinct to write custom middleware is just recreating the duct-tape solution they should have built, and you'll be the one maintaining it when their API changes.
What you're really asking is how to make a square peg fit a round hole. The reliable solution is to stop using Sembly for this scenario altogether and find a tool built on a platform that actually understands session multiplexing.
Skeptic by default