Design Copilot Studio agents for reliable Teams deployment
Diesen Beitrag auf Deutsch lesen
Eight Copilot Studio patterns address Teams reinstalls, persistent conversations, stale context, resets, errors, diagnostics, and suggested prompts.
TL;DR
Copilot Studio agents deployed to Teams should handle InstallationUpdate events, clear stale conversations after inactivity, re-establish global context, and customize Reset Conversation and Start Over topics. The examples use a 12-hour inactivity period, Adaptive Cards for user guidance and diagnostics, and latest-published-content behavior for persistent sessions.
Original by Henry Jammes, on The Custom Engine. Read the original
This is our own summary, not a republication or full translation.
Governance takeaway
- Makers: Add InstallationUpdate and inactivity topics, then test reset behavior in Teams because Test Chat does not expose persistent sessions and reinstall conditions.
- Admins/CoE: Apply the published-content behavior to relevant topics and provide diagnostic details through Start Over only when support needs them, so users can recover from stale state and teams can troubleshoot consistently.
Frequently asked questions
How does Copilot Studio handle a Teams app reinstall?
An InstallationUpdate trigger can redirect the agent to Conversation Start, because Conversation Start does not run automatically after reinstalls.
What inactivity duration does the Copilot Studio Teams example use?
The example uses durationInSeconds 43200, equal to 12 hours, then clears conversation history and variables before marking the conversation inactive.
Which diagnostics can a Copilot Studio Start Over card display?
The Adaptive Card can display environment, tenant, agent, user, and conversation identifiers, along with the current UTC timestamp.