Microsoft Graph And SharePoint Provider Boundary
Summary
Microsoft Graph and SharePoint are useful provider-boundary examples because a single provider surface can span mail, Teams, files, sites, users, and permissions. Workflows should not speak Graph directly; they should call capabilities such as notification delivery or document access.
Reader Question
How should a platform use a broad collaboration provider without scattering auth, identity lookup, destination handling, and provider error semantics across every workflow?
Boundary Pattern
The integration edge owns Graph-specific authentication, request shape, pagination, throttling, and provider errors. Services expose workflow-friendly capabilities such as sending a message, resolving a destination, or accessing a document artifact.
That service layer prevents a workflow from depending on whether the underlying provider operation is mail, Teams, SharePoint, or another Graph resource. It also gives the platform one place to record diagnostics and convert provider failure into actionable workflow state.
Reusable Lessons
- Broad collaboration providers should be wrapped as capabilities, not called directly from jobs or UI.
- Destination identity and permissions are part of the operation contract.
- Provider errors should become structured diagnostics.
- Shared notification/document services keep channels replaceable.
- Workflows should depend on internal intent, not provider endpoints.
Source Evidence
integrations/ext_microsoftservices/notifications/microsoft.pydocs/domains/notifications.md