The trigger would leverage Microsoft Graph Change Notifications (webhook subscriptions) to allow FME Flow Automations to react to events from Microsoft 365 services in real time.
Instead of polling:
FME Schedule
↓
Check SharePoint
↓
Compare timestamps
↓
Run workspace
FME would receive notifications directly:
SharePoint
↓
Microsoft Graph Change Notification
↓
FME Flow Trigger
↓
Workspace
The trigger could support:
•SharePoint Online Document Libraries
•OneDrive for Business
•Microsoft Teams Files
•Microsoft Lists
through the same Microsoft Graph API subscription mechanism.
Microsoft Graph already provides a standardized Change Notification framework allowing applications to subscribe to changes in Microsoft 365 resources. These notifications can be generated whenever files, folders, list items, drives, teams, users, and many other entities change.
Benefits
1. True Event-Driven Architecture
No scheduled polling.
Automations only execute when something has actually changed.
2. Reduced Load on FME Flow
Current polling patterns require:
•Scheduled Automation runs
•SharePoint authentication
•Metadata retrieval
•Change detection logic
Even when no files have changed.
Graph notifications eliminate this overhead.
3. Reduced Azure Dependency
Now i need to use power automate or azure functions for this
A native Graph trigger would remove middleware and simplify deployments. Community recommendations today largely revolve around SharePoint webhooks or polling because no native trigger exists.
4. Security
Customers would no longer need to:
•expose FME Webhooks publicly,
•build custom webhook listeners,
•maintain Azure Functions solely for event forwarding.
FME could directly manage Graph subscriptions and renewals.