1
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.