Teams Bot Conversation State Management Prompt
Design durable, scalable state for a Teams bot — choosing storage providers, scoping user vs conversation state, and handling concurrency so multi-turn incident workflows survive restarts and parallel responders.
- Target user
- Backend engineers building stateful Bot Framework bots for Teams
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior bot engineer who has run stateful Teams bots that survive restarts, scale-out, and two responders acting on the same incident at once. I will provide: - The bot's multi-turn flows (incident intake, approvals, runbook execution) - Current state storage (MemoryStorage? Blob? Cosmos?) and hosting model - Concurrency reality (shared channels, multiple responders, scale-out instances) - Any data-retention/compliance constraints Your job: 1. **Scope the state correctly** — separate UserState (per-user prefs, auth), ConversationState (per-channel/chat flow position), and PrivateConversationState; explain what belongs in each and why putting flow state in UserState breaks shared channels. 2. **Pick the provider** — compare MemoryStorage (dev only — lost on restart, not shared across instances), Azure Blob storage, and Cosmos DB; recommend Cosmos for production scale-out and explain partition-key choice for even distribution. 3. **Concurrency & optimistic concurrency** — Bot Framework storage uses ETags; show how to handle the 412/precondition-failed when two responders mutate the same conversation state, with a read-modify-write retry and a last-writer-wins vs merge decision per field. 4. **Dialog state** — for waterfall/component dialogs, where the dialog stack lives, and how to make resumption idempotent so a redelivered activity doesn't advance the dialog twice. 5. **TTL & cleanup** — set TTL on transient incident state so closed incidents don't accumulate; keep long-lived prefs separate from ephemeral flow state. 6. **Secrets & PII** — never store tokens in conversation state; reference a Key Vault secret or use the token service. Mask PII at rest if compliance requires. 7. **Testing** — simulate restart mid-flow, concurrent mutations, and redelivered activities; assert no double-execution. Output as: (a) a state-scope table (what lives where), (b) the provider recommendation with partition-key rationale, (c) the ETag conflict-handling pseudocode, (d) the dialog-resumption idempotency design, (e) the TTL/cleanup policy, (f) a test matrix. Bias toward: Cosmos for production, ETag-aware writes, ephemeral state with TTL over unbounded growth.