Microsoft Graph Change Notifications - Simply Explained
Welcome to another episode of Knowledge Nuggets with Mirko Peters. Today we're exploring Microsoft Graph Change Notifications, one of the most important capabilities for building modern, event-driven Microsoft 365 applications. Imagine your application needs to know whenever a new email arrives, a SharePoint document is updated, a Teams message is posted, or a user account changes inside Microsoft Entra ID. The traditional approach is simple—but inefficient. Your application repeatedly asks Microsoft Graph whether anything has changed. Most of the time the answer is "no," wasting API calls, increasing latency, and potentially triggering Microsoft Graph throttling. Microsoft Graph Change Notifications solve this problem by turning Microsoft 365 into an event-driven platform. Instead of continuously asking for updates, your application simply subscribes to the resources it cares about, and Microsoft Graph automatically notifies your application whenever something changes. In this episode, we'll explain how Change Notifications work, how subscriptions and webhooks fit together, why subscription renewal matters, and how organizations use this capability to build real-time Microsoft 365 solutions.
THE PROBLEM WITH POLLING
Before understanding Change Notifications, it's important to understand the problem they were designed to solve. Traditionally, applications relied on polling. Every few minutes an application would call Microsoft Graph asking whether anything had changed since the previous request. This approach creates several problems. If nothing has changed, every request wastes processing power, bandwidth, and API quota. If something changes immediately after the last request, users may wait several minutes before the application notices. Developers are forced to choose between frequent polling that wastes resources or slower polling that introduces delays. Microsoft Graph also protects its services through throttling. Applications making excessive requests may temporarily receive rate limits, forcing developers to slow down even further. Instead of repeatedly asking Microsoft Graph for updates, Microsoft introduced Change Notifications so that Microsoft Graph can notify applications only when something actually happens. This shift from polling to event-driven communication dramatically reduces unnecessary API traffic while providing much faster response times.
WHAT ARE MICROSOFT GRAPH CHANGE NOTIFICATIONS?
Microsoft Graph Change Notifications provide a push-based event system for Microsoft 365. Rather than checking repeatedly for updates, an application tells Microsoft Graph which resources it wants to monitor. Microsoft Graph then watches those resources continuously. Whenever a matching event occurs, Microsoft Graph immediately sends an HTTP POST request to the application's endpoint. A useful analogy is a mailbox with a motion sensor. Without Change Notifications, you repeatedly walk outside to see whether new mail has arrived. With Change Notifications, the motion sensor alerts you the instant the mail is delivered. The same concept applies to Microsoft 365. Whether monitoring Outlook emails, SharePoint files, Microsoft Teams messages, users, groups, calendars, contacts, or security alerts, Microsoft Graph automatically informs your application whenever relevant activity occurs. Instead of constantly asking, your application simply reacts.
SUBSCRIPTIONS: TELLING GRAPH WHAT TO WATCH
Everything begins with a subscription. A subscription tells Microsoft Graph exactly which resource should be monitored and what kinds of changes should trigger notifications. When creating a subscription, several pieces of information must be provided. The application specifies the resource path, such as users, Outlook mail folders, calendars, or SharePoint libraries. It also selects which changes should trigger notifications, including newly created items, updates, deletions, or combinations of these events. Next, the application provides a secure HTTPS notification endpoint where Microsoft Graph will deliver notifications. Finally, every subscription includes an expiration date. Unlike permanent registrations, subscriptions automatically expire after a limited period. Different Microsoft 365 resources support different maximum subscription lifetimes, making renewal an essential part of every production solution. Once Microsoft Graph accepts the subscription request, it returns a unique subscription identifier that applications later use to renew, update, or delete the subscription.
THE VALIDATION HANDSHAKE
Before Microsoft Graph begins sending notifications, it first verifies that the notification endpoint actually belongs to the application. This process is called the validation handshake. Immediately after a subscription is created, Microsoft Graph sends a verification request containing a validation token. The application's endpoint must return that exact token as plain text within a short time window. A helpful analogy is a courier delivering an important package. Before handing over the package, the courier rings the doorbell to confirm that someone is actually home. If nobody answers, the delivery never happens. The validation handshake works the same way. Only after the endpoint successfully returns the validation token does Microsoft Graph activate the subscription and begin delivering real notifications. This simple verification process prevents malicious applications from redirecting notifications to unauthorized destinations.
KEEPING SUBSCRIPTIONS ALIVE
Subscriptions do not last forever. Every subscription eventually reaches its expiration time, after which Microsoft Graph stops sending notifications entirely. Because different resources have different maximum subscription durations, production applications must continuously monitor expiration times and renew subscriptions before they expire. Renewal is performed by sending an update request using the subscription identifier together with a new expiration timestamp. Microsoft also provides lifecycle notifications, allowing applications to receive advance warnings before subscriptions expire or when access tokens require renewal. A practical strategy is to inspect expiration information whenever notifications arrive and renew subscriptions well before they expire, avoiding unnecessary outages while reducing operational complexity. Proper subscription management is one of the most important aspects of building reliable event-driven Microsoft Graph applications.
BUILDING RELIABLE SOLUTIONS
Real-world systems occasionally experience failures. Endpoints may become temporarily unavailable, networks may experience interruptions, or notifications may occasionally fail to arrive. Microsoft Graph therefore expects webhook endpoints to acknowledge notifications very quickly. Applications should return an immediate success response while processing notifications asynchronously in the background. Rather than performing lengthy business logic inside the webhook itself, notifications should typically be placed into queues where background services can process them safely without delaying Microsoft Graph. Microsoft also recommends combining Change Notifications with Delta Queries. Change Notifications provide immediate awareness whenever something changes, while Delta Queries periodically compare current data with previous synchronization states. Together they create a highly reliable synchronization strategy where notifications deliver real-time updates while Delta Queries recover any events that might have been missed because of temporary outages or expired subscriptions. This combination gives organizations both speed and reliability.
REAL WORLD BUSINESS SCENARIOS
Microsoft Graph Change Notifications enable numerous automation scenarios across Microsoft 365. Human Resources systems can automatically provision new employees when Microsoft Entra ID creates user accounts, triggering downstream onboarding processes immediately. Security platforms can react instantly whenever user accounts become disabled or security-sensitive changes occur, allowing security teams to investigate potential incidents without waiting for scheduled scans. Document processing solutions monitor SharePoint libraries, automatically classifying newly uploaded files with AI before routing invoices, contracts, or forms into appropriate business workflows. Analytics platforms synchronize Microsoft 365 activity into Microsoft Fabric or Power BI almost immediately, allowing dashboards to reflect operational changes in near real time. Microsoft Copilot connectors also leverage event-driven synchronization so AI assistants receive updated business information as soon as source systems change, allowing Copilot experiences to remain current without repeatedly scanning entire datasets. In every scenario, Change Notifications eliminate unnecessary polling while dramatically reducing response times.
CHOOSING THE RIGHT DELIVERY OPTION
Microsoft supports several delivery models depending on application scale. For many organizations, webhooks provide the simplest solution. Microsoft Graph sends HTTP POST requests directly to the application's notification endpoint, making implementation straightforward for low and medium notification volumes. Larger enterprise environments often choose Azure Event Hubs, allowing millions of notifications to flow through highly scalable event streaming infrastructure before applications process them at their own pace. Organizations building serverless architectures frequently integrate Change Notifications with Azure Event Grid, allowing Azure Functions, Logic Apps, and other cloud-native services to react automatically while Microsoft handles retries and message delivery.
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
00:00:00,000 --> 00:00:04,480
Today's topic is one that almost everyone building with Microsoft 365 has heard of,
2
00:00:04,480 --> 00:00:07,520
but most people don't really get how it works behind the scenes.
3
00:00:07,520 --> 00:00:10,800
I'm talking about Microsoft Graph change notifications.
4
00:00:10,800 --> 00:00:13,360
What exactly are they? And why should you care?
5
00:00:13,360 --> 00:00:15,120
Let's start with the problem they solve.
6
00:00:15,120 --> 00:00:19,120
Imagine you build an app that needs to know when something changes in Microsoft 365,
7
00:00:19,120 --> 00:00:21,800
maybe a new email arrives, someone updates a file in SharePoint,
8
00:00:21,800 --> 00:00:25,440
or a new user gets added to your company directory. How does your app find out?
9
00:00:25,440 --> 00:00:27,800
Here's the thing, the old way is polling.
10
00:00:27,800 --> 00:00:31,320
Your app sends a request to Microsoft Graph every few minutes and asks,
11
00:00:31,320 --> 00:00:35,320
"Anything new since I last checked? If nothing changed, you wasted a request,
12
00:00:35,320 --> 00:00:39,640
and if something changed five seconds after your check, you won't know until the next cycle."
13
00:00:39,640 --> 00:00:42,920
You're either checking too often, wasting resources and risking throttling,
14
00:00:42,920 --> 00:00:45,160
or too rarely, which means you miss things.
15
00:00:45,160 --> 00:00:48,520
Microsoft actually throttles apps that poll too aggressively,
16
00:00:48,520 --> 00:00:53,800
developers call it GraphJail, and your app gets blocked for a while because it's making too many requests.
17
00:00:53,800 --> 00:00:55,880
So the question becomes, "Isn't there a better way?"
18
00:00:55,880 --> 00:00:58,840
What if instead of your app constantly asking anything new,
19
00:00:58,840 --> 00:01:04,040
the system just told you when something changed? That's exactly what change notifications do.
20
00:01:04,040 --> 00:01:06,360
What are Microsoft Graph change notifications?
21
00:01:06,360 --> 00:01:09,480
Here's the simplest definition, change, notifications,
22
00:01:09,480 --> 00:01:14,440
let your app react instantly to events in Microsoft 365 without constant checking.
23
00:01:14,440 --> 00:01:16,600
Think of it like a motion sensor on your mailbox.
24
00:01:16,600 --> 00:01:19,000
Instead of walking past it every hour to peak inside,
25
00:01:19,000 --> 00:01:22,040
you install a sensor that pings you the moment mail arrives.
26
00:01:22,040 --> 00:01:24,760
You stop wasting time when empty checks are never miss a delivery.
27
00:01:24,760 --> 00:01:26,760
That's what change notifications do for your app.
28
00:01:26,760 --> 00:01:31,240
When something changes, like a new email, an updated file or a calendar event,
29
00:01:31,240 --> 00:01:35,480
Microsoft Graph sends a notification to your app automatically, no polling required.
30
00:01:35,480 --> 00:01:39,560
Now this system has two pieces, a subscription and a notification,
31
00:01:39,560 --> 00:01:40,600
and they work together.
32
00:01:40,600 --> 00:01:44,120
The subscription is where you tell Microsoft Graph what you want to watch.
33
00:01:44,120 --> 00:01:47,800
You say things like, "Hey, let me know when someone sends a new message to this inbox,"
34
00:01:47,800 --> 00:01:51,320
or "Tell me when a file gets updated in this SharePoint library."
35
00:01:51,320 --> 00:01:53,320
You register your interest and Graph takes note.
36
00:01:53,320 --> 00:01:55,160
The notification is what happens next.
37
00:01:55,160 --> 00:01:59,160
When the change occurs, Graph sends an HTTP post to an endpoint you provide.
38
00:01:59,160 --> 00:02:02,120
Your app receives that post and knows something happened,
39
00:02:02,120 --> 00:02:05,160
and it can then decide what to do, like fetch the new data,
40
00:02:05,160 --> 00:02:07,400
trigger a workflow, or update a database.
41
00:02:07,400 --> 00:02:09,640
Here's the key difference from polling.
42
00:02:09,640 --> 00:02:11,800
Notifications are delivered automatically.
43
00:02:11,800 --> 00:02:15,480
Your app doesn't have to ask, the system pushes the information the moment it happens.
44
00:02:15,480 --> 00:02:16,600
That's the magic of it.
45
00:02:16,600 --> 00:02:20,680
Microsoft Graph supports change notifications for a wide range of resources.
46
00:02:20,680 --> 00:02:24,280
Messages, events, contacts, users, groups, files, teams, messages,
47
00:02:24,280 --> 00:02:28,680
security alerts, pretty much anything you can access through Graph can be monitored for changes.
48
00:02:28,680 --> 00:02:30,200
But how do you actually set this up?
49
00:02:30,200 --> 00:02:33,000
How do you tell Graph what to watch and where to send the alerts?
50
00:02:33,000 --> 00:02:35,800
Creating a subscription, telling Graph what to watch.
51
00:02:35,800 --> 00:02:37,000
So what is a subscription?
52
00:02:37,000 --> 00:02:38,440
It's just a registration request.
53
00:02:38,440 --> 00:02:40,520
Your app says, "Let me know when this thing happens,"
54
00:02:40,520 --> 00:02:43,080
and you send that request to the Microsoft Graph API.
55
00:02:43,080 --> 00:02:44,600
Graph stores it and waits.
56
00:02:44,600 --> 00:02:47,240
You need to give Graph a few details in that request.
57
00:02:47,240 --> 00:02:49,160
First, the resource you want to watch.
58
00:02:49,160 --> 00:02:50,360
The path to the data.
59
00:02:50,360 --> 00:02:53,480
For example, then users if you're monitoring changes to user accounts
60
00:02:53,480 --> 00:02:58,360
or me, male, folders, inbox messages if you want to know about new emails.
61
00:02:58,360 --> 00:02:59,640
Next, the change type.
62
00:02:59,640 --> 00:03:02,680
Do you want to know when something is created, updated, deleted?
63
00:03:02,680 --> 00:03:04,840
You can pick one or you can ask for all three.
64
00:03:04,840 --> 00:03:06,280
Third, the notification URL.
65
00:03:06,280 --> 00:03:07,800
This is your endpoints address.
66
00:03:07,800 --> 00:03:10,520
The place where Graph should send the notification when something happens.
67
00:03:10,520 --> 00:03:13,160
It has to be a publicly accessible HTTPS endpoint.
68
00:03:13,160 --> 00:03:14,520
No shortcuts there.
69
00:03:14,520 --> 00:03:15,880
Fourth, the expiration date.
70
00:03:15,880 --> 00:03:17,400
Subscriptions don't last forever.
71
00:03:17,400 --> 00:03:20,280
You pick a future date in time when the subscription expires.
72
00:03:20,280 --> 00:03:23,080
But different resources have different max lifetimes.
73
00:03:23,080 --> 00:03:25,320
Outlook messages can last up to seven days.
74
00:03:25,320 --> 00:03:27,640
Teams chat messages max out at three days.
75
00:03:27,640 --> 00:03:29,800
SharePoint files can last about 30 days.
76
00:03:29,800 --> 00:03:30,680
Present information?
77
00:03:30,680 --> 00:03:32,680
That expires after just one hour.
78
00:03:32,680 --> 00:03:33,960
Here's a concrete example.
79
00:03:33,960 --> 00:03:37,080
Say you want to know when someone in your company changes their job title.
80
00:03:37,080 --> 00:03:41,160
You create a subscription for the user's resource with a change type of updated.
81
00:03:41,160 --> 00:03:43,080
You point it to your notification URL
82
00:03:43,080 --> 00:03:44,920
and set the expiration a few days out.
83
00:03:44,920 --> 00:03:47,160
When someone updates their profile in Enter ID,
84
00:03:47,160 --> 00:03:50,360
Graph sends a post to your endpoint with a notification payload.
85
00:03:50,360 --> 00:03:53,320
That payload includes the user's ID and tells you what changed.
86
00:03:53,320 --> 00:03:58,360
Your app can then act on it, update an HR system, trigger a notification to their manager, whatever you need.
87
00:03:58,360 --> 00:04:01,560
Graph responds to your subscription request with a subscription ID.
88
00:04:01,560 --> 00:04:03,880
You'll need that ID later to manage the subscription,
89
00:04:03,880 --> 00:04:05,880
renew it, update it, or delete it.
90
00:04:05,880 --> 00:04:06,680
But here's the thing.
91
00:04:06,680 --> 00:04:08,920
Before Graph starts sending notifications,
92
00:04:08,920 --> 00:04:12,120
it needs to confirm your endpoint is actually alive and listening.
93
00:04:12,120 --> 00:04:13,800
That requires a handshake.
94
00:04:13,800 --> 00:04:14,680
The handshake.
95
00:04:14,680 --> 00:04:16,760
Validation token explained.
96
00:04:16,760 --> 00:04:18,040
When you create a subscription,
97
00:04:18,040 --> 00:04:20,840
Microsoft Graph doesn't just trust your endpoint blindly.
98
00:04:20,840 --> 00:04:24,120
It sends a test ping first, a verification request.
99
00:04:24,120 --> 00:04:27,480
That ping includes a validation token, a random string of characters.
100
00:04:27,480 --> 00:04:31,560
Your endpoint has to catch that token and send it back as plain text within 10 seconds.
101
00:04:31,560 --> 00:04:36,040
Think of it like a delivery driver ringing your doorbell to confirm your home before leaving a package.
102
00:04:36,040 --> 00:04:38,440
If nobody answers, the driver leaves nothing.
103
00:04:38,440 --> 00:04:39,240
Same here.
104
00:04:39,240 --> 00:04:41,880
If your endpoint doesn't echo back the validation token,
105
00:04:41,880 --> 00:04:43,800
Graph won't send notifications to it.
106
00:04:43,800 --> 00:04:48,680
The response must be plain text, not JSON or XML, just the raw token string.
107
00:04:48,680 --> 00:04:50,840
Get the format wrong and the handshake fails.
108
00:04:50,840 --> 00:04:51,960
It's a security check.
109
00:04:51,960 --> 00:04:55,560
It proves your endpoint is alive, listening, and under your control.
110
00:04:55,560 --> 00:04:58,920
It stops someone from pointing a subscription at a URL they don't own,
111
00:04:58,920 --> 00:05:01,480
hoping to intercept notifications meant for someone else.
112
00:05:01,480 --> 00:05:03,240
No handshake means no subscription.
113
00:05:03,240 --> 00:05:06,200
Graph rejects the creation request and you get an error.
114
00:05:06,200 --> 00:05:07,720
You fix your endpoint and try again.
115
00:05:07,720 --> 00:05:08,920
Once the handshake succeeds,
116
00:05:08,920 --> 00:05:11,960
the subscription is active and notifications start flowing.
117
00:05:11,960 --> 00:05:13,240
But here's the thing.
118
00:05:13,240 --> 00:05:14,360
They don't flow forever.
119
00:05:14,360 --> 00:05:16,360
Keeping the connection alive.
120
00:05:16,360 --> 00:05:18,360
Subscription renewal.
121
00:05:18,360 --> 00:05:20,440
Every subscription has an expiration date.
122
00:05:20,440 --> 00:05:21,880
You set it when you created.
123
00:05:21,880 --> 00:05:22,840
Graph enforces it.
124
00:05:22,840 --> 00:05:25,000
When that date arrives, the subscription stops.
125
00:05:25,000 --> 00:05:26,040
No more notifications.
126
00:05:26,040 --> 00:05:28,760
Think of it like a parking meter.
127
00:05:28,760 --> 00:05:32,600
You put in the time and when it runs out, the meter flags expire.
128
00:05:32,600 --> 00:05:34,440
Different resources have different limits.
129
00:05:34,440 --> 00:05:36,600
Outlook messages can run for seven days.
130
00:05:36,600 --> 00:05:38,200
Teams chat messages three days.
131
00:05:38,200 --> 00:05:40,040
SharePoint files last about 30 days.
132
00:05:40,040 --> 00:05:41,160
Presence information.
133
00:05:41,160 --> 00:05:41,880
Just one hour.
134
00:05:42,680 --> 00:05:45,240
So your app can't just create a subscription and forget about it.
135
00:05:45,240 --> 00:05:47,000
You need a process that keeps it alive.
136
00:05:47,000 --> 00:05:48,200
Renewing is simple.
137
00:05:48,200 --> 00:05:50,600
Send a patch request with the subscription ID.
138
00:05:50,600 --> 00:05:52,280
Include a new expiration date.
139
00:05:52,280 --> 00:05:54,040
Do it before the current one expires.
140
00:05:54,040 --> 00:05:56,040
And graph extends the subscription.
141
00:05:56,040 --> 00:05:57,880
Here's the best practice I recommend.
142
00:05:57,880 --> 00:06:00,680
Check the expiration timestamp on every notification you receive.
143
00:06:00,680 --> 00:06:02,840
If it's close to expires, say within a day,
144
00:06:02,840 --> 00:06:03,960
renew it right then.
145
00:06:03,960 --> 00:06:05,960
That way you don't need a separate background job
146
00:06:05,960 --> 00:06:07,640
just to manage subscriptions.
147
00:06:07,640 --> 00:06:10,440
Microsoft also added life cycle notifications.
148
00:06:10,440 --> 00:06:12,840
These alerts warn you before a subscription expires.
149
00:06:12,840 --> 00:06:14,680
They tell you when your subscription is about to end
150
00:06:14,680 --> 00:06:17,320
or when your access token needs reauthorization,
151
00:06:17,320 --> 00:06:20,680
subscribe to these and your app can renew before anything breaks.
152
00:06:20,680 --> 00:06:22,200
But what if your endpoint goes down?
153
00:06:22,200 --> 00:06:23,400
Or you miss a renewal window?
154
00:06:23,400 --> 00:06:24,920
That's where the safety net comes in.
155
00:06:24,920 --> 00:06:28,760
When things go wrong, reliability and safety nets.
156
00:06:28,760 --> 00:06:29,960
Your subscription is active.
157
00:06:29,960 --> 00:06:30,920
Your endpoint is listening.
158
00:06:30,920 --> 00:06:32,200
Notifications are flowing.
159
00:06:32,200 --> 00:06:33,080
Everything looks good.
160
00:06:33,080 --> 00:06:34,680
But what happens when something breaks?
161
00:06:34,680 --> 00:06:36,680
Maybe your endpoint goes down for maintenance.
162
00:06:36,680 --> 00:06:38,760
A network issue drops a notification.
163
00:06:38,760 --> 00:06:40,360
Or you simply miss the renewal window
164
00:06:40,360 --> 00:06:41,640
and the subscription expires.
165
00:06:41,640 --> 00:06:42,520
These things happen.
166
00:06:42,520 --> 00:06:44,280
The question is, how do you recover?
167
00:06:44,280 --> 00:06:47,080
Microsoft Graph expects your webhook endpoint to respond quickly
168
00:06:47,080 --> 00:06:47,960
within three seconds.
169
00:06:47,960 --> 00:06:48,920
If it takes longer,
170
00:06:48,920 --> 00:06:50,040
Graph marks it as slow.
171
00:06:50,040 --> 00:06:52,680
If more than 10% of your responses exceed three seconds
172
00:06:52,680 --> 00:06:53,960
in any 10-minute period,
173
00:06:53,960 --> 00:06:56,360
Graph delays your notifications by 10 minutes.
174
00:06:56,360 --> 00:06:58,760
It sends only a small sample to check if you've recovered.
175
00:06:58,760 --> 00:06:59,800
It gets worse.
176
00:06:59,800 --> 00:07:01,960
If more than 15% of your responses exceed
177
00:07:01,960 --> 00:07:03,320
the 10-second retry timeout,
178
00:07:03,320 --> 00:07:04,920
Graph marks your endpoint as drop.
179
00:07:04,920 --> 00:07:06,760
Notifications stop entirely for 10 minutes.
180
00:07:06,760 --> 00:07:07,400
They're gone.
181
00:07:07,400 --> 00:07:08,600
You can't get them back.
182
00:07:08,600 --> 00:07:10,760
So your endpoint needs to be fast and reliable.
183
00:07:10,760 --> 00:07:13,240
That doesn't mean you have to process every notification
184
00:07:13,240 --> 00:07:14,520
in under three seconds.
185
00:07:14,520 --> 00:07:15,800
Just acknowledge receipt quickly
186
00:07:15,800 --> 00:07:17,800
with a 202 accepted response.
187
00:07:17,800 --> 00:07:19,880
Then process the notification asynchronously,
188
00:07:19,880 --> 00:07:21,400
queue it up, handle it later.
189
00:07:21,400 --> 00:07:22,840
The key is that fast response.
190
00:07:22,840 --> 00:07:24,120
Even with a perfect endpoint,
191
00:07:24,120 --> 00:07:25,480
things can still go wrong.
192
00:07:25,480 --> 00:07:26,920
Subscriptions expire.
193
00:07:26,920 --> 00:07:28,280
Network blips happen.
194
00:07:28,280 --> 00:07:31,560
Microsoft Graph itself might miss a notification in rare cases.
195
00:07:31,560 --> 00:07:33,080
That's why you need a safety net.
196
00:07:33,080 --> 00:07:33,880
Delta queries.
197
00:07:33,880 --> 00:07:34,680
Think of it this way.
198
00:07:34,680 --> 00:07:36,680
Change notifications are the fire alarm.
199
00:07:36,680 --> 00:07:38,440
They tell you something is happening right now.
200
00:07:38,440 --> 00:07:40,280
Delta queries are the sprinkler system.
201
00:07:40,280 --> 00:07:41,800
They catch anything the alarm missed.
202
00:07:41,800 --> 00:07:42,760
They work together.
203
00:07:42,760 --> 00:07:44,840
Notifications give you real-time awareness.
204
00:07:44,840 --> 00:07:46,520
Delta queries give you a complete picture
205
00:07:46,520 --> 00:07:48,200
you can reconcile at any time.
206
00:07:48,200 --> 00:07:49,720
The recommended pattern is simple.
207
00:07:49,720 --> 00:07:52,200
Use change notifications for instant awareness.
208
00:07:52,200 --> 00:07:53,720
Run a Delta query periodically.
209
00:07:53,720 --> 00:07:55,400
Maybe every few hours or once a day
210
00:07:55,400 --> 00:07:56,920
to catch anything that slipped through.
211
00:07:56,920 --> 00:07:59,160
This way, even if a notification was lost
212
00:07:59,160 --> 00:08:00,440
or a subscription expired,
213
00:08:00,440 --> 00:08:02,440
you never miss a change permanently.
214
00:08:02,440 --> 00:08:04,040
Real-world use cases.
215
00:08:04,040 --> 00:08:05,160
What you can build.
216
00:08:05,160 --> 00:08:06,840
So what does this actually enable?
217
00:08:06,840 --> 00:08:08,440
Let me walk you through some real examples.
218
00:08:08,440 --> 00:08:09,640
Take HR automation.
219
00:08:09,640 --> 00:08:11,800
Imagine someone joins your company tomorrow.
220
00:08:11,800 --> 00:08:13,880
The moment EntraID creates a new user
221
00:08:13,880 --> 00:08:15,480
a change notification fires.
222
00:08:15,480 --> 00:08:16,840
Your app grabs their profile
223
00:08:16,840 --> 00:08:18,840
and creates accounts in your HR platform.
224
00:08:18,840 --> 00:08:20,440
Time tracking and building access.
225
00:08:20,440 --> 00:08:22,520
All in seconds, no polling, no delays.
226
00:08:22,520 --> 00:08:25,960
For security alerts, say a user's account gets disabled.
227
00:08:25,960 --> 00:08:28,040
A change notification triggers a workflow
228
00:08:28,040 --> 00:08:29,640
that checks for suspicious changes
229
00:08:29,640 --> 00:08:31,240
and alerts your security team
230
00:08:31,240 --> 00:08:33,160
before you'd pull every few minutes.
231
00:08:33,160 --> 00:08:34,200
Now it's instant.
232
00:08:34,200 --> 00:08:36,040
Content processing works the same way.
233
00:08:36,040 --> 00:08:38,440
When a file lands in a SharePoint document library,
234
00:08:38,440 --> 00:08:40,040
you want to know if it's an invoice.
235
00:08:40,040 --> 00:08:42,280
The notification tells you a new file exists.
236
00:08:42,280 --> 00:08:43,960
Your app grabs it, runs it through AI
237
00:08:43,960 --> 00:08:46,440
to classify it and sends it to the right expense system.
238
00:08:46,440 --> 00:08:47,640
All automatic.
239
00:08:47,640 --> 00:08:49,960
Real-time dashboards let you see analytics as they happen.
240
00:08:49,960 --> 00:08:51,160
Not from hours ago.
241
00:08:51,160 --> 00:08:52,520
Change notifications.
242
00:08:52,520 --> 00:08:54,440
Sync dataverse to fabric instantly.
243
00:08:54,440 --> 00:08:57,160
Your Power BI dashboards update in near real-time.
244
00:08:57,160 --> 00:08:58,680
Here's one I find interesting.
245
00:08:58,680 --> 00:08:59,960
Co-pilot connectors.
246
00:08:59,960 --> 00:09:02,040
Microsoft adds real-time sync through webhooks
247
00:09:02,040 --> 00:09:04,840
so AI agents respond the second data changes.
248
00:09:04,840 --> 00:09:08,040
When a customer records updates in Dynamics 365,
249
00:09:08,040 --> 00:09:10,760
a co-pilot agent generates a follow-up immediately.
250
00:09:10,760 --> 00:09:12,520
No waiting.
251
00:09:12,520 --> 00:09:14,520
All these examples share one thing.
252
00:09:14,520 --> 00:09:16,040
Before change notifications,
253
00:09:16,040 --> 00:09:19,080
you build scheduled jobs that hold every hour or day.
254
00:09:19,080 --> 00:09:22,360
It worked, but was slow, wasteful, and fragile.
255
00:09:22,360 --> 00:09:24,280
Change notifications, flip that model.
256
00:09:24,280 --> 00:09:27,480
Real-time, event-driven, instant.
257
00:09:27,480 --> 00:09:29,160
Choosing the right delivery channel,
258
00:09:29,160 --> 00:09:31,080
not every app needs the same delivery.
259
00:09:31,080 --> 00:09:32,200
Let's look at your options.
260
00:09:32,200 --> 00:09:33,640
Webhooks are the simplest.
261
00:09:33,640 --> 00:09:36,200
Graph sends an HTTP post to your endpoint.
262
00:09:36,200 --> 00:09:37,720
You process it and move on.
263
00:09:37,720 --> 00:09:40,440
For low-to-medium volumes, say a few hundred notifications an hour,
264
00:09:40,440 --> 00:09:41,400
that works fine.
265
00:09:41,400 --> 00:09:43,240
But what if you're building something bigger?
266
00:09:43,240 --> 00:09:44,840
Thousands of notifications per second
267
00:09:44,840 --> 00:09:46,600
can overwhelm a single endpoint.
268
00:09:46,600 --> 00:09:48,280
You need something more powerful.
269
00:09:48,280 --> 00:09:51,000
Event hubs handles millions of events per second.
270
00:09:51,000 --> 00:09:53,240
Instead of graph sending notifications one by one,
271
00:09:53,240 --> 00:09:54,600
it sends them to a hub.
272
00:09:54,600 --> 00:09:56,040
Your app reads at its own pace.
273
00:09:56,040 --> 00:09:57,160
No risk of flooding.
274
00:09:57,160 --> 00:09:58,760
This is for large enterprise scenarios
275
00:09:58,760 --> 00:10:01,640
like thousands of SharePoint sites or millions of mailboxes.
276
00:10:01,640 --> 00:10:03,480
Then there's Event Grid, the serverless option.
277
00:10:03,480 --> 00:10:06,520
It sends notifications to Azure Functions or Logic Apps
278
00:10:06,520 --> 00:10:09,240
and automatically handles retries and dead lettering.
279
00:10:09,240 --> 00:10:11,160
If you're building automated workflows in the cloud
280
00:10:11,160 --> 00:10:13,640
and don't want to manage servers, Event Grid is your friend.
281
00:10:13,640 --> 00:10:15,000
Here's how you decide.
282
00:10:15,000 --> 00:10:17,800
For simple, low-to-medium volume, Webhooks.
283
00:10:17,800 --> 00:10:19,080
Need massive scale?
284
00:10:19,080 --> 00:10:22,040
Event hubs, serverless automation, Event Grid.
285
00:10:22,040 --> 00:10:24,920
But remember, all three require a subscription.
286
00:10:24,920 --> 00:10:26,840
The difference is how notifications arrive,
287
00:10:26,840 --> 00:10:28,280
not whether they arrive.
288
00:10:28,280 --> 00:10:29,320
Same core concept.
289
00:10:29,320 --> 00:10:31,480
Subscribe, listen, renew.
290
00:10:31,480 --> 00:10:32,760
So what's the big picture?
291
00:10:32,760 --> 00:10:34,520
Change notifications are the alert system
292
00:10:34,520 --> 00:10:37,000
that makes Microsoft 365 reactive.
293
00:10:37,000 --> 00:10:39,240
You subscribe to tell Microsoft Graph what to watch,
294
00:10:39,240 --> 00:10:40,920
listen for notifications on your endpoint
295
00:10:40,920 --> 00:10:42,920
and renew before the subscription expires.
296
00:10:42,920 --> 00:10:44,760
It's that handshake between you and the cloud.
297
00:10:44,760 --> 00:10:46,360
But what if you miss a notification?
298
00:10:46,360 --> 00:10:47,880
Delta queries are your safety net.
299
00:10:47,880 --> 00:10:49,800
They catch you up on everything that changed.
300
00:10:49,800 --> 00:10:51,720
Notifications give instant awareness.
301
00:10:51,720 --> 00:10:54,120
Delta queries give complete reconciliation.
302
00:10:54,120 --> 00:10:56,120
Together, they ensure nothing gets lost.
303
00:10:56,120 --> 00:10:57,480
Best way to understand it?
304
00:10:57,480 --> 00:10:59,080
Start small with Graph Explorer.
305
00:10:59,080 --> 00:11:00,520
Subscribe to your own inbox.
306
00:11:00,520 --> 00:11:01,800
Watch the notification arrive
307
00:11:01,800 --> 00:11:03,160
and see the handshake happen.
308
00:11:03,160 --> 00:11:04,120
That's the quickest path.
309
00:11:04,120 --> 00:11:05,960
That's change notifications in plain English.
310
00:11:05,960 --> 00:11:07,800
I'm Mirko Peters from M365.
311
00:11:07,800 --> 00:11:09,000
FM, subscribe and share.
312
00:11:09,000 --> 00:11:10,520
We'll see you next time.
