Loop Component (Adaptive Card-Based) for Live Incident Status Prompt
Design a Teams/Microsoft 365 Loop component backed by an Adaptive Card extension so an incident status block stays live and editable wherever it is pasted — chat, email, or a Loop page — without copy-paste drift.
- Target user
- Engineers building Loop-enabled collaborative components for ops
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior platform engineer who has shipped a Loop component that renders live incident status and stays in sync across every surface it is pasted into. I will provide: - The incident data to surface and its source of truth: [INCIDENT DATA AND SOURCE] - Which fields users may edit inline vs read-only: [EDITABLE VS READONLY FIELDS] - Where the component will be pasted (Teams chat, Outlook, Loop app): [TARGET SURFACES] - Your backend's update model and auth: [BACKEND AND AUTH] Your job: 1. **Card-based Loop component** — base the component on an Adaptive Card with Universal Actions (Action.Execute) so it works across Loop-enabled hosts, not just Teams; explain why Action.Submit alone won't give you the cross-host refresh. 2. **refresh model** — use the card's refresh action with userIds so each viewer gets the current incident state when they open the surface, instead of a frozen snapshot from when it was pasted. 3. **Inline edits** — wire editable fields ([EDITABLE FIELDS]) through Action.Execute to your backend, writing back to [SOURCE OF TRUTH] and returning a refreshed card; keep [READONLY FIELDS] non-interactive. 4. **Conflict handling** — two responders may edit the same field across two surfaces; define optimistic-concurrency handling (ETag or version field) so the second write doesn't silently clobber the first. 5. **Per-user authorization** — resolve edit permissions via SSO so only authorized responders can change status, severity, or commander; read-only viewers still see live data. 6. **Stale-link safety** — if the incident is closed, render a clear closed state rather than allowing edits to a resolved incident. Output as: (a) the Adaptive Card with refresh + Action.Execute, (b) the backend write-back handler pseudocode, (c) the concurrency/ETag scheme, (d) the per-user authorization gate, (e) the closed-incident state. Bias toward: Universal Actions for cross-host behavior, the refresh model over static snapshots, and ETag-aware writes.
Why this prompt works
Loop components are seductive because they promise a single living block of state that follows your team across chat, email, and Loop pages. The catch is that “living” only works if you build on the right primitive. This prompt insists on an Adaptive Card with Universal Actions (Action.Execute) plus the refresh model, because that is the combination that makes the component render current data on every host and every viewer — not a snapshot frozen at paste time. The prompt even calls out why Action.Submit alone fails the cross-host requirement, so the designer doesn’t reach for the familiar-but-wrong tool.
The genuinely hard parts of a collaborative incident component are concurrency and authorization, and the prompt makes both non-negotiable. When the same status block is editable from two surfaces, two responders will eventually edit the same field at the same time; the ETag/version requirement turns a silent overwrite into a detectable conflict. The per-user authorization gate via SSO means a read-only viewer who can paste the component still can’t quietly change severity or the incident commander — a distinction that matters enormously during a live incident.
Because the prompt also demands an explicit closed-incident state, the output avoids the embarrassing failure where someone edits a resolved incident days later. You end up with a component spec that is genuinely safe to hand to a responder under pressure: live for everyone, editable only by the right people, and conflict-aware when two of them act at once.