Reference architecture
From visitor to Teams, through a flow and safely back
In the documented WebChat pattern, a widget or social message reaches the selected Teams channel. A keyword is configured per channel in the Power Platform tab. Power Automate listens with the Microsoft Teams keyword trigger, then evaluates conditions, reads authorised data or publishes a structured card.
The return route is the critical proof. A CRM lookup does not itself reply to the visitor. The pilot must distinguish an internal Teams post from an @WebChat message returned to the customer and show when automation is disabled for a human. Internal notes must never escape because a mention or condition was misconfigured.
| Component | Documented role | Verify before production |
|---|---|---|
| WebChat channel | Inbound Teams channel and a channel keyword | Source, destination, internal versus customer-visible reply |
| Teams connector | Channel triggers plus message or card actions | Team, channel, connection owner, permissions and limits |
| Power Automate | Conditions, lookups, orchestration, reminders and handoff | Environment, error handling, retries, monitoring and licence context |
| CRM/ERP/helpdesk | Read current data or invoke an allowed action | Exact connector/API, roles, least data and write scope |
| AI/Adaptive Card | Suggested answer, structured context or operator action | Grounding, approval, injection resistance, card permissions and fallback |
Licensing and identity
Premium follows the actual flow, not the marketing label
WebChat's guide says its illustrated AI design uses premium connectors and recommends a clearly named dedicated Microsoft identity for the Teams connection. Microsoft distinguishes automated, scheduled and instant flows plus user and Process licence contexts. Therefore neither 'one Premium user always covers it' nor 'every agent needs Premium' is a defensible shortcut.
Inventory the owner, every connection, run-only users, service principals, development/test/production environments, premium or custom connectors and expected runs. Obtain a written licensing assessment from that design. WebChat's per-channel licence and Microsoft Power Platform or Azure consumption remain separate TCO blocks.
Governance
DLP is a guardrail, not an automatic compliance approval
- Classify every connector and custom-connector endpoint under an approved data policy.
- Separate development, test and production; move flows, connection references and environment variables deliberately.
- Give the flow and target systems only the minimum required read and write privileges.
- Log triggers, lookups, card actions, customer replies, handoffs and failures without retaining unnecessary chat content.
- Define timeouts, retries, an alert/dead-letter route and manual operation when a connector or flow fails.
- Review retention and deletion separately in Teams, Power Platform, the target system, the AI service and WebChat.
Production acceptance
Eight tests for a defensible Power Platform pilot
- 01
Freeze the scope
Choose one channel, trigger, target system, read-only record and explicit handoff.
- 02
Document identities
Name the flow owner, Teams connection, target-system account, administrators, secrets and cover.
- 03
Prove the happy path
Send a test message, retrieve the right data, inspect the card and verify the visitor reply.
- 04
Test denied access
Unauthorised records, manipulated identifiers and overly broad queries must fail safely.
- 05
Force handoff
Disable automation, let an agent take over and re-enable it without duplicate answers.
- 06
Simulate failure
Block connector, target system and AI separately; alert, retry and manual response must work.
- 07
Exercise concurrency
Rapid parallel messages must not create duplicate actions, cards or customer replies.
- 08
Approve cost and operations
Confirm licence context, Azure usage, connector limits, monitoring, support and rollback in writing.