ENGINEERING
A Teams assistant on your own gateway — no Copilot seat required
A Teams assistant without a Copilot seat
Microsoft 365 Copilot is priced per seat, on top of whatever M365 license the person already has. For a team that wants an AI assistant answering questions in one or two channels — not a copilot woven into every app on every seat — that's a lot of licensing to buy for a narrow use case. The no-code path to the same outcome, scoped to what you actually need, is a Power Automate flow triggered by Teams channel messages.
The flow: trigger, HTTP, post
The pattern is three steps, all standard Power Automate actions:
- Trigger: "When a new channel message is added," scoped to a channel — or a trigger that fires on a keyword mention if you want this to fire only on messages that actually ask the assistant something, rather than every message in the channel.
- HTTP action: POST to your gateway's chat completions endpoint, the same shape as any other integration —
model,messages(the triggering message text as the user turn, plus a system prompt defining the assistant's scope),max_tokens— with the bearer key in theAuthorizationheader. - "Post message in a chat or channel": the response's
choices[0].message.content, pulled out with a Parse JSON step, posted back into the same channel or thread.
That's the entire assistant. No bot registration in the Azure Bot Framework, no app package to sideload — if channel triggers and channel posting cover what you need, the whole thing lives inside one flow.
Where users actually see this
Inside Teams, this surfaces through the Workflows app — the rebranded, embedded version of Power Automate that ships in Teams by default. A user who opens the Workflows tab in a channel sees the flow you built listed there, and can trigger it manually if you build a manual-trigger version alongside the automatic one. Anyone building Teams-native automation without leaving Teams is, in practice, already using Power Automate through this surface.
What this honestly is, and what it isn't
Worth being precise here, because it's easy to oversell: this is not Copilot embedded in the Teams UI. There's no Copilot icon appearing across chat, meetings, and Loop components. What you get is a bot-like presence that answers in the specific channels you wire it into, backed by your model, logged through your gateway. For a support channel, an internal FAQ channel, or a channel where people ask the same categories of question repeatedly, that's the actual requirement — not a platform-wide assistant.
The HTTP action carries the same premium-connector requirement here as anywhere else in Power Automate — a per-flow or premium plan, not included in a standard Microsoft 365 license. Factor that into the cost comparison against a Copilot seat; it isn't free, but for most tenants it's a license already covering other flows, not a new per-user recurring cost that scales with headcount.
Latency is flow latency, not chat latency — a few seconds between a message posting and the assistant's reply appearing, because the request goes trigger → HTTP call → parse → post, not a live typing indicator. For channel Q&A, where a question sits for a few seconds either way while people read it, that's not a noticeable tradeoff. It's a poor fit for anything that needs to feel like a live conversation.
The upside underneath the licensing math: the channel content going into these requests goes to your gateway and your model, not to a Microsoft-operated Copilot backend where you don't control logging or retention. For teams handling anything sensitive in a channel — HR, legal, security incident channels — that's often the actual reason to build this instead of waiting on a Copilot rollout, not just the seat cost.
Scoping it so it doesn't get noisy
A channel-wide trigger on every message will answer things nobody asked it to answer, and burn tokens doing it. The keyword or @mention trigger is worth the extra setup for any channel with regular human conversation, not just Q&A traffic — it keeps the assistant from injecting a reply into a thread that was two colleagues talking to each other. For channels that exist mainly to be asked things — an IT helpdesk channel, an onboarding-questions channel — the plain "new message" trigger is fine, since near enough everything posted there is already a question.
One more thing worth building in early: a short system prompt that tells the model what it doesn't know, not just what it does. "If the question isn't about X, say you can only help with X" keeps the assistant from confidently answering something outside its actual scope in a channel where people will take the answer at face value. That's a one-line addition to the system message in the HTTP action's body, and it's the difference between a useful narrow assistant and one that quietly becomes a liability the first time someone asks it something unrelated.
Try it on ours
Our gateway (iSol API) is the endpoint behind that HTTP action — your model, your logs, no Copilot seat. US$ 99/month, 14-day trial.