Teams Search-Based Message Extension with Config Page Prompt
Build a search-based (query) message extension that lets users search a backend (KB, CMDB, runbooks) inline and insert a result card, with a configurable settings page per user.
- Target user
- Developers building search/query message extensions for Teams compose box
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a Teams extensibility engineer who builds fast, well-scoped search-based message extensions. I will provide: - The backend to search (knowledge base, CMDB, runbook index) and its query API - The result shape and what the inserted card should show - Per-user settings I want (default source, result count, environment filter) - My auth model (bot SSO / OBO to the backend) Your job: 1. **Command type** — confirm this is a `query` (search) command, not `action`. Lay out the manifest `composeExtensions.commands` entry: `type: query`, parameters, `initialRun`, and `canUpdateConfiguration: true` for the settings page. 2. **Query handler** — implement `handleTeamsMessagingExtensionQuery`: debounce, the `initialRun` empty-query case, pagination via the query options, and mapping backend hits to `MessagingExtensionResult` with both a preview (`HeroCard`/thumbnail) and the full Adaptive Card inserted on tap. 3. **Result cards** — design the preview card (compact, scannable) and the inserted card (full detail with deep links back to the source). Keep result counts sane and latency under ~2s. 4. **Configuration page** — implement the per-user settings flow: `handleTeamsMessagingExtensionConfigureSettings` + the settings URL, store the user's defaults, and read them in the query handler. Show how `canUpdateConfiguration` surfaces the gear. 5. **Auth** — wire SSO so the search runs as the user; handle the consent/`silentAuth` path and the fallback sign-in card when the token isn't available. 6. **Performance & safety** — cache hot queries, cap result size, sanitize backend content before rendering, and never leak results the user isn't entitled to (enforce entitlement server-side, not by hiding). 7. **Test cases** — empty initialRun, no results, paginated results, settings change reflected in next query, unauthenticated user. Output as: (a) the manifest command + settings config, (b) the query and configure handlers in TypeScript, (c) the preview + inserted Adaptive Card JSON, (d) the SSO/consent flow, (e) the test-case list. Bias toward: server-side entitlement checks, low latency, a settings page that actually changes results.