The Graph surface for Teams (and its edges)
Objects: teams, channels, members, messages (with the migration/export APIs and change notifications for message flows), onlineMeetings + attendance, shifts, apps/installations. The edges that shape designs:
- Policies mostly are NOT in Graph — the Cs* engine remains PowerShell's (the previous concept); plan hybrid automation stacks.
- Message access is licensed territory: export/high-volume message APIs carry model requirements (metered/protected APIs) — budget and register intent, don't discover this at review time.
- Change notifications (webhooks) for messages/membership power integrations — with lifecycle (renewals!) that unattended systems must own or silently go deaf.
- Beta vs v1.0 discipline: prod on v1.0; beta explorations flagged with a migration owner (admin-surfaces rule, API edition).
RSC — the delegated trust model
Resource-specific consent lets a TEAM OWNER (or chat member, for
chat-RSC) grant an app permissions ON THAT RESOURCE ONLY —
ChannelMessage.Read.Group, TeamSettings.ReadWrite.Group and family.
The point: team-level agility without tenant-wide grants. The governance
catch: these consents live per-resource — the tenant's enterprise-app
permission blade won't enumerate them the way admins expect; RSC-bearing
apps' install BASE is the real exposure map. Org-level switches control
whether RSC is grantable at all and by whom (group-owner consent
settings) — decide that stance deliberately.
What to watch (proofs)
- The tenant stance: RSC consent settings (Teams admin app permission settings + Entra group-owner consent controls) — grantable-by-whom, as configured fact.
- The exposure map: app installations per team joined to each app's manifest RSC block (Graph: installedApps expand) — 'which teams has this app got powers in' answered as data.
- Notification liveness: subscription inventory with expiry timestamps from your integration's store — renewals succeeding is the difference between event-driven and quietly-dead.
- Metered-API posture: registrations/consent for protected message APIs and their billing telemetry — before the invoice, not after.