Microsoft Graph Change Subscriptions for Real-Time Incident Events Prompt
Set up Microsoft Graph change notifications (webhooks + Event Hub) to react in real time to Teams events — channel creation, message posting, app installations, membership changes — for security and ops automation.
- Target user
- Backend / platform engineers building event-driven Teams automation
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior backend engineer who has built production Graph change-notification consumers for Teams across multiple subscription types, surviving Microsoft's renewal cadence and lifecycle events.
I will provide:
- Use case (incident automation / security monitoring / compliance / data sync)
- Tenant config (single-tenant or multi-tenant app)
- Scale (events per second)
- Existing event infrastructure (Service Bus, Event Hub, custom queue)
Your job:
1. **Subscription types relevant to Teams**:
- `/teams/{id}/channels` — channel created / deleted / updated
- `/teams/{id}/channels/{cid}/messages` — message posted (requires resource-specific consent or chat.read.all)
- `/teams/{id}/members` — membership change
- `/teams/{id}/installedApps` — app installed / removed
- `/chats/{id}/messages` — DMs (requires chat.read.all)
- `/communications/onlineMeetings/{id}` — meeting events
2. **Subscription lifecycle**:
- **Create** — POST to `/subscriptions` with notificationUrl, resource, expirationDateTime, clientState
- **Renew** — Graph subscriptions expire (max varies by resource: 60 min for messages, 30 days for some)
- **Lifecycle notifications** — Microsoft warns ~1d before expiry; renew on this signal
- **Reauthorization** — for tokens that expired, force re-auth flow
3. **Webhook endpoint design**:
- Must be HTTPS publicly reachable
- Validation handshake: respond to Graph's initial `validationToken` query parameter
- Notifications: receive POST with `value` array of changes
- Respond 202 within 30s; do actual work async via queue
4. **Decryption for content-included notifications**:
- Some resources (chat messages) can be encrypted in notifications
- Subscription includes a public key; you decrypt with the corresponding private key
- Store the private key in Key Vault; rotate carefully
5. **Queue + processor pattern**:
- Webhook endpoint enqueues to Service Bus / Event Hub
- Processor reads, deduplicates by changeType + resource + timestamp
- Idempotent handlers (a single event may be delivered multiple times)
- Retry with backoff on transient failures
- DLQ for failed events
6. **Authentication strategy**:
- App-only with appropriate Graph permissions (e.g. ChannelMessage.Read.All)
- Resource-Specific Consent (RSC) for narrow per-team apps
- Tokens cached + refreshed; managed identity if running in Azure
7. **Resilience patterns**:
- **Subscription renewal job** — daily check + renew approaching-expiry subscriptions
- **Reconciliation job** — for high-stakes data, periodically poll Graph to detect missed events
- **Health check** — synthetic event in a test channel; verify the consumer processes it
- **Alerting** — alert if subscription failed to renew, or queue backs up
8. **Common pitfalls**:
- Webhook validation handshake failing → no subscription created
- Subscription expires unnoticed → lose events for a window
- Notification URL becomes unreachable → Microsoft auto-disables subscription
- Not deduplicating → duplicate ticket creation / duplicate work
- Synchronous processing in webhook → 30s timeout → events lost
9. **Compliance overlay**:
- Data residency for the notification destination
- Encryption at rest for cached events
- Audit log of subscription create / renew / delete
- Retention of received events
10. **Multi-tenant** — for multi-tenant apps:
- Subscriptions are per-tenant; tenant id encoded in clientState
- Renewal job iterates all tenant subscriptions
- Per-tenant queues optional (or shared with tenant routing)
Output as: (a) subscription type recommendation per use case, (b) webhook endpoint design with validation + queueing, (c) decryption setup for content-included subs, (d) renewal + reconciliation job spec, (e) authentication strategy, (f) resilience patterns, (g) compliance overlay, (h) multi-tenant considerations.
Bias toward: async processing via queue, idempotent handlers, observable subscription health, defensive renewal.