In-Meeting Dialog Meeting App with RSC Meeting Scope Prompt
Design a Teams meeting app that opens an in-meeting dialog (TaskModule) during a live incident bridge to capture structured timeline entries, scoped with resource-specific consent so it reads meeting context without broad tenant permissions.
- Target user
- Engineers building meeting-scoped apps for incident bridges
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior platform engineer who has built a Teams meeting app for live incident bridges that opens an in-meeting dialog to log timeline entries, scoped tightly with resource-specific consent. I will provide: - The data the in-meeting dialog captures (timeline note, severity change, action item): [DIALOG FIELDS] - Which meeting context you need (organizer, participants, meeting id): [REQUIRED CONTEXT] - Where captured entries are written: [BACKEND] - Your tenant's stance on admin consent vs RSC: [CONSENT MODEL] Your job: 1. **Meeting surfaces** — declare the meeting context surfaces in the manifest (meetingStage, meetingSidePanel, meetingChatTab as needed) and the in-meeting dialog (TaskModule) trigger; explain which surface suits a quick timeline entry vs a persistent side panel. 2. **RSC meeting scope** — request resource-specific consent at the meeting/chat scope (e.g. OnlineMeeting.ReadBasic.Chat, ChatMessage.Read.Chat) instead of broad application permissions, so the app only sees the meetings it's added to. 3. **In-meeting dialog flow** — wire the TaskModule open from a bot action or side-panel button, render an Adaptive Card form for [DIALOG FIELDS], and handle the submit to write to [BACKEND] with the meeting id as correlation. 4. **Meeting context** — use the Teams JS SDK getContext / meeting APIs to read the meeting id and the acting user, and stamp every timeline entry with both so the incident record is attributable. 5. **Lifecycle** — handle the app being added/removed mid-meeting and the meeting ending; flush any in-flight entries and stop accepting new ones after the meeting closes. 6. **Least privilege** — justify each RSC permission against [REQUIRED CONTEXT]; drop any permission not strictly needed. Output as: (a) the manifest meeting surfaces + RSC block, (b) the in-meeting dialog (TaskModule) trigger and submit handler, (c) the meeting-context read via the JS SDK, (d) the lifecycle handling, (e) the per-permission least-privilege justification. Bias toward: RSC meeting-scope over tenant-wide app permissions, attributable timeline entries, and least privilege.
Why this prompt works
Meeting apps and resource-specific consent are each documented well in isolation, but the combination — a meeting-scoped app that captures structured data during a live bridge using narrow permissions — is exactly the niche this prompt fills. By insisting on RSC at the meeting/chat scope (ReadBasic.Chat, ChatMessage.Read.Chat) instead of tenant-wide application permissions, the design only ever sees the meetings it was explicitly added to. For an incident bridge that may discuss sensitive systems, that least-privilege posture is not a nicety; it’s what lets a security team approve the app at all.
The prompt is precise about the interaction model that makes a meeting app actually useful under pressure. An in-meeting TaskModule dialog for a quick timeline entry is the right surface for a responder mid-call, and the prompt separates that from a persistent side panel for ongoing context. By requiring every captured entry to be stamped with the meeting id and acting user via the Teams JS SDK, the output produces an attributable incident record rather than a pile of anonymous notes — which is what a postmortem actually needs.
Lifecycle handling is the detail most implementations forget. Apps get added and removed mid-meeting, and meetings end; the prompt forces the design to flush in-flight entries and stop accepting new ones once the meeting closes, so you never get timeline entries logged against a call that already ended. The result is a meeting app that is tightly scoped, genuinely usable during a bridge, and clean about its own lifecycle.