The Hidden Logic of Microsoft Graph

1
00:00:00,000 --> 00:00:02,800
Most Microsoft 365 admins know three graph endpoints,

2
00:00:02,800 --> 00:00:06,080
users, groups, teams, that's it.

3
00:00:06,080 --> 00:00:07,720
Behind those three sits an ecosystem

4
00:00:07,720 --> 00:00:12,120
most organizations never touch, reporting APIs, audit logs,

5
00:00:12,120 --> 00:00:15,880
identity governance, security signals, meeting intelligence,

6
00:00:15,880 --> 00:00:19,480
places data, organizational insights, all of it queryable,

7
00:00:19,480 --> 00:00:21,600
all of it sitting there, unused.

8
00:00:21,600 --> 00:00:23,840
But here's the problem, the organizations that do use it

9
00:00:23,840 --> 00:00:26,360
aren't just more efficient, they're structurally different,

10
00:00:26,360 --> 00:00:28,640
they see things others can't, they catch problems

11
00:00:28,640 --> 00:00:31,200
before they become incidents, they make governance decisions

12
00:00:31,200 --> 00:00:33,360
based on data, not assumptions.

13
00:00:33,360 --> 00:00:35,080
Graph isn't a developer tool anymore,

14
00:00:35,080 --> 00:00:37,200
it's the logic layer your entire organization

15
00:00:37,200 --> 00:00:39,120
is already running on, whether you know it or not,

16
00:00:39,120 --> 00:00:42,440
and if you want more of this, subscribe to the M365FM podcast.

17
00:00:42,440 --> 00:00:45,040
Every episode is built for IT pros and decision makers

18
00:00:45,040 --> 00:00:47,560
who need to stay ahead in the Microsoft ecosystem.

19
00:00:47,560 --> 00:00:50,160
By the end of this episode, you'll see graph differently,

20
00:00:50,160 --> 00:00:52,280
not as a set of endpoints, as the control plane

21
00:00:52,280 --> 00:00:56,000
your organization is already running on, what graph actually is

22
00:00:56,000 --> 00:00:57,800
and what most people think it is.

23
00:00:57,800 --> 00:01:00,120
Here's the mental model most people carry.

24
00:01:00,120 --> 00:01:02,840
Microsoft Graph is a REST API, you authenticate, you query,

25
00:01:02,840 --> 00:01:05,680
you get JSON-VAC users, groups, maybe some teams data,

26
00:01:05,680 --> 00:01:07,680
that's the surface most teams ever see,

27
00:01:07,680 --> 00:01:10,840
but that model is wrong, not slightly wrong, fundamentally wrong.

28
00:01:10,840 --> 00:01:14,400
Graph isn't a REST API you call to get data,

29
00:01:14,400 --> 00:01:17,200
it's the unified abstraction layer that sits over identity,

30
00:01:17,200 --> 00:01:19,880
collaboration, security, compliance,

31
00:01:19,880 --> 00:01:22,520
and analytics across the entire Microsoft Cloud.

32
00:01:22,520 --> 00:01:25,960
Every single thing that happens in your Microsoft 365 environment,

33
00:01:25,960 --> 00:01:27,920
every co-pilot responds, every team's message,

34
00:01:27,920 --> 00:01:30,360
every SharePoint file access, every enter sign in,

35
00:01:30,360 --> 00:01:33,080
every defender alert, all of it is mediated by graph.

36
00:01:33,080 --> 00:01:34,960
Graph isn't a window into your organization,

37
00:01:34,960 --> 00:01:36,600
it's the foundation underneath it.

38
00:01:36,600 --> 00:01:37,720
To understand why that matters,

39
00:01:37,720 --> 00:01:40,040
you need to understand where graph came from.

40
00:01:40,040 --> 00:01:42,800
Before graph existed, every Microsoft 365 service

41
00:01:42,800 --> 00:01:45,240
had its own API, exchange had EWS.

42
00:01:45,240 --> 00:01:47,360
Azure AD had its own graph endpoint at graph,

43
00:01:47,360 --> 00:01:49,760
Windows.net, SharePoint had its own REST API,

44
00:01:49,760 --> 00:01:51,160
Teams had its own surface.

45
00:01:51,160 --> 00:01:53,120
If you want a data that crossed service boundaries,

46
00:01:53,120 --> 00:01:54,280
you had to build integrations

47
00:01:54,280 --> 00:01:56,560
against multiple different authentication models,

48
00:01:56,560 --> 00:01:59,800
different data schemers, different throttling behaviors,

49
00:01:59,800 --> 00:02:01,400
different versioning patterns.

50
00:02:01,400 --> 00:02:03,720
It was fragmented, it was expensive to maintain.

51
00:02:03,720 --> 00:02:05,120
Microsoft graph changed that.

52
00:02:05,120 --> 00:02:08,240
It unified all of those surfaces behind a single endpoint,

53
00:02:08,240 --> 00:02:11,520
graph.microsoft.com, with a single authentication model,

54
00:02:11,520 --> 00:02:13,120
a single permission framework,

55
00:02:13,120 --> 00:02:16,160
and a single place where organizational data becomes queryable.

56
00:02:16,160 --> 00:02:18,240
That's the architectural shift most people miss.

57
00:02:18,240 --> 00:02:19,760
Graph isn't just a convenience layer,

58
00:02:19,760 --> 00:02:21,800
it's the strategic bet Microsoft made

59
00:02:21,800 --> 00:02:23,760
that all organizational data should be accessible

60
00:02:23,760 --> 00:02:25,280
through one coherent surface.

61
00:02:25,280 --> 00:02:28,600
And that bet has paid off because now every new Microsoft 365

62
00:02:28,600 --> 00:02:31,800
capability, co-pilot, Viva, security co-pilot,

63
00:02:31,800 --> 00:02:33,920
purview, ships with graph support first,

64
00:02:33,920 --> 00:02:38,320
legacy APIs get frozen, then deprecated, then retired.

65
00:02:38,320 --> 00:02:40,000
Graph is the direction of travel.

66
00:02:40,000 --> 00:02:41,520
And it's been that way for years.

67
00:02:41,520 --> 00:02:43,160
Why does this matter for executives?

68
00:02:43,160 --> 00:02:46,120
Because graph is the only place in your entire Microsoft 365

69
00:02:46,120 --> 00:02:49,280
estate where organizational behavior becomes queryable data,

70
00:02:49,280 --> 00:02:51,640
not just configuration data, behavioral data.

71
00:02:51,640 --> 00:02:52,720
Who's meeting with whom?

72
00:02:52,720 --> 00:02:54,560
Which licenses aren't being used?

73
00:02:54,560 --> 00:02:56,880
Which accounts haven't signed in since a departed employee

74
00:02:56,880 --> 00:02:58,080
left six months ago?

75
00:02:58,080 --> 00:03:00,600
Which teams channels are active and which ones are ghost towns

76
00:03:00,600 --> 00:03:02,360
with sensitive files still attached?

77
00:03:02,360 --> 00:03:05,080
That's not IT data, that's organizational intelligence.

78
00:03:05,080 --> 00:03:06,480
And it only exists in one place.

79
00:03:06,480 --> 00:03:07,960
There's a company called Structural.

80
00:03:07,960 --> 00:03:10,880
Microsoft references them directly in adoption materials

81
00:03:10,880 --> 00:03:13,840
that doubled their growth by leveraging graph within teams,

82
00:03:13,840 --> 00:03:16,800
not by building more features, not by acquiring more customers,

83
00:03:16,800 --> 00:03:18,920
by understanding the logic layer underneath

84
00:03:18,920 --> 00:03:21,040
their collaboration environment and using it

85
00:03:21,040 --> 00:03:23,640
to make better decisions about how work actually happened.

86
00:03:23,640 --> 00:03:25,120
That's the shift we're talking about,

87
00:03:25,120 --> 00:03:26,960
from graph as a developer convenience,

88
00:03:26,960 --> 00:03:29,920
to graph as a strategic asset, from querying endpoints

89
00:03:29,920 --> 00:03:31,720
to understanding your organization.

90
00:03:31,720 --> 00:03:34,160
Now you might be thinking, if graph is this central,

91
00:03:34,160 --> 00:03:37,520
why do most organizations only ever touch users and groups?

92
00:03:37,520 --> 00:03:39,760
Why does the 90% of available capabilities

93
00:03:39,760 --> 00:03:40,840
sit completely unused?

94
00:03:40,840 --> 00:03:42,800
Because the gap between knowing graph exists

95
00:03:42,800 --> 00:03:45,280
and knowing what it can do isn't a technical gap.

96
00:03:45,280 --> 00:03:47,160
It's a discovery gap, it's a cultural gap,

97
00:03:47,160 --> 00:03:48,720
it's a permission anxiety gap.

98
00:03:48,720 --> 00:03:50,640
And that's exactly where we're going next.

99
00:03:50,640 --> 00:03:52,920
Why organizations stop at users and groups?

100
00:03:52,920 --> 00:03:54,080
So why does this happen?

101
00:03:54,080 --> 00:03:57,080
Why do teams with access to one of the most powerful data

102
00:03:57,080 --> 00:04:00,120
services in software end up using it like a phone book?

103
00:04:00,120 --> 00:04:01,840
There are five reasons, and none of them

104
00:04:01,840 --> 00:04:03,400
are technical incompetence.

105
00:04:03,400 --> 00:04:05,000
The first is the discovery problem.

106
00:04:05,000 --> 00:04:08,120
Graph has thousands of endpoints, the documentation is vast.

107
00:04:08,120 --> 00:04:10,480
When most teams encounter graph for the first time,

108
00:04:10,480 --> 00:04:12,280
they're solving a specific problem,

109
00:04:12,280 --> 00:04:14,800
like automating user provisioning or pulling a group list.

110
00:04:14,800 --> 00:04:16,360
They solve that problem, they move on,

111
00:04:16,360 --> 00:04:18,160
and they never come back to ask what else is there.

112
00:04:18,160 --> 00:04:20,320
The learning happens inside a single use case.

113
00:04:20,320 --> 00:04:22,080
And that use case becomes the mental boundary

114
00:04:22,080 --> 00:04:23,120
for what graph can do.

115
00:04:23,120 --> 00:04:25,880
Nobody has time to read every API reference page,

116
00:04:25,880 --> 00:04:29,160
looking for possibilities their organization hasn't asked for yet.

117
00:04:29,160 --> 00:04:30,920
The second is permission anxiety.

118
00:04:30,920 --> 00:04:33,560
Graph operates on a model where you request specific grants

119
00:04:33,560 --> 00:04:35,920
called scopes, and broad scopes feel risky.

120
00:04:35,920 --> 00:04:38,920
User.read write all sounds alarming while directory.

121
00:04:38,920 --> 00:04:41,160
Read all trigger security reviews.

122
00:04:41,160 --> 00:04:42,720
So teams request the minimum.

123
00:04:42,720 --> 00:04:44,520
They get what they need for today's task.

124
00:04:44,520 --> 00:04:46,880
And because they never request the permissions to explore,

125
00:04:46,880 --> 00:04:48,880
they never discover what exploring would reveal.

126
00:04:48,880 --> 00:04:52,000
The permission model, which is actually a well designed architecture,

127
00:04:52,000 --> 00:04:55,360
paradoxically becomes a ceiling on organizational curiosity.

128
00:04:55,360 --> 00:04:59,120
The third is the tooling gap, most Microsoft 365 administrators

129
00:04:59,120 --> 00:05:00,680
don't interact with graph directly.

130
00:05:00,680 --> 00:05:02,080
They use PowerShell modules.

131
00:05:02,080 --> 00:05:05,360
The Microsoft Graph SDK, the older MSO and Azure AD modules,

132
00:05:05,360 --> 00:05:07,080
or Exchange Online PowerShell.

133
00:05:07,080 --> 00:05:08,680
Those modules are abstractions.

134
00:05:08,680 --> 00:05:11,680
They call graph underneath, but they don't expose the full surface.

135
00:05:11,680 --> 00:05:15,120
They only expose the command someone decided to build CMD LEDs for.

136
00:05:15,120 --> 00:05:17,840
Everything else, the reporting API is the audit log endpoints

137
00:05:17,840 --> 00:05:19,600
and the identity governance surfaces.

138
00:05:19,600 --> 00:05:20,680
Stays invisible.

139
00:05:20,680 --> 00:05:23,960
You can spend years as an admin, never once seeing a raw graph query

140
00:05:23,960 --> 00:05:25,760
because the tooling layer hides the plumbing.

141
00:05:25,760 --> 00:05:26,840
The fourth is cultural.

142
00:05:26,840 --> 00:05:28,840
IT builds what's asked for.

143
00:05:28,840 --> 00:05:32,560
When a business stakeholder asks for a report, IT builds that report.

144
00:05:32,560 --> 00:05:35,400
When security asks for an alert, IT builds that alert.

145
00:05:35,400 --> 00:05:36,840
But here's the problem.

146
00:05:36,840 --> 00:05:38,840
Nobody asks for the things they don't know exist.

147
00:05:38,840 --> 00:05:40,680
So the cycle reinforces itself.

148
00:05:40,680 --> 00:05:43,240
The business doesn't ask for graph driven governance dashboards

149
00:05:43,240 --> 00:05:44,960
because they don't know they're possible.

150
00:05:44,960 --> 00:05:46,920
It doesn't build them because nobody asked.

151
00:05:46,920 --> 00:05:50,000
And the organization runs on assumptions instead of data.

152
00:05:50,000 --> 00:05:51,520
The fifth reason is real friction.

153
00:05:51,520 --> 00:05:53,640
And this one deserves an honest acknowledgement.

154
00:05:53,640 --> 00:05:54,760
Graph isn't frictionless.

155
00:05:54,760 --> 00:05:57,560
There was a piece published in March of 2026,

156
00:05:57,560 --> 00:05:59,680
a widely circulated one in the community.

157
00:05:59,680 --> 00:06:03,040
Titled something like "The sad state of Microsoft Graph."

158
00:06:03,040 --> 00:06:05,080
It describes genuine operational pain,

159
00:06:05,080 --> 00:06:07,080
throttling limits that feel inconsistent,

160
00:06:07,080 --> 00:06:09,520
documentation that lags behind actual behavior.

161
00:06:09,520 --> 00:06:11,960
Breaking changes that hit production without warning.

162
00:06:11,960 --> 00:06:13,360
These aren't invented complaints.

163
00:06:13,360 --> 00:06:14,080
They're real.

164
00:06:14,080 --> 00:06:15,640
Organizations that have gone deep on graph

165
00:06:15,640 --> 00:06:17,880
know exactly what this article was talking about.

166
00:06:17,880 --> 00:06:19,480
But here's the distinction that matters.

167
00:06:19,480 --> 00:06:21,160
Those are operational challenges.

168
00:06:21,160 --> 00:06:22,360
They're engineering problems.

169
00:06:22,360 --> 00:06:23,920
They're not reasons to stay shallow.

170
00:06:23,920 --> 00:06:25,640
The organization's dealing with throttling

171
00:06:25,640 --> 00:06:27,840
are the ones getting value from graph at scale.

172
00:06:27,840 --> 00:06:29,520
The ones who never hit a limit are the ones

173
00:06:29,520 --> 00:06:32,000
who never pushed the surface hard enough to matter.

174
00:06:32,000 --> 00:06:33,840
What's sitting on the other side of that friction?

175
00:06:33,840 --> 00:06:36,440
Reporting APIs that expose exchange activity,

176
00:06:36,440 --> 00:06:40,000
teams usage, SharePoint file behavior, and license utilization.

177
00:06:40,000 --> 00:06:41,840
All curable on demand.

178
00:06:41,840 --> 00:06:45,560
Audit logs that tell you exactly who changed what, when, and from where.

179
00:06:45,560 --> 00:06:48,000
Identity governance surfaces that let you automate

180
00:06:48,000 --> 00:06:51,160
join a mover lever processes without a single manual step.

181
00:06:51,160 --> 00:06:53,640
Security APIs that aggregate alerts across defender,

182
00:06:53,640 --> 00:06:56,320
enter ID and in tune into one normalized data plane.

183
00:06:56,320 --> 00:06:57,880
And a collection of hidden endpoints.

184
00:06:57,880 --> 00:07:00,280
Planner, search, places, and Viva insights.

185
00:07:00,280 --> 00:07:02,080
That most teams don't even know exist.

186
00:07:02,080 --> 00:07:03,800
That's the 90% nobody's using.

187
00:07:03,800 --> 00:07:06,200
And the organizations that are using it aren't doing so

188
00:07:06,200 --> 00:07:07,520
because they have bigger budgets.

189
00:07:07,520 --> 00:07:09,520
They're doing it because someone, at some point,

190
00:07:09,520 --> 00:07:13,000
stopped asking, how do we do what we're already doing faster?

191
00:07:13,000 --> 00:07:15,520
And started asking, what does graph make possible?

192
00:07:15,520 --> 00:07:17,800
That we haven't even considered yet.

193
00:07:17,800 --> 00:07:20,920
Let's start with the layer most executives ask about first.

194
00:07:20,920 --> 00:07:24,400
The reporting APIs, your organization's behavior in data.

195
00:07:24,400 --> 00:07:27,680
Let's talk about what the reporting APIs actually expose.

196
00:07:27,680 --> 00:07:30,200
Because most people, when they hear usage reports,

197
00:07:30,200 --> 00:07:32,080
picture the admin center dashboard,

198
00:07:32,080 --> 00:07:34,640
the bar charts, the weekly active user count,

199
00:07:34,640 --> 00:07:37,520
the stuff you glance at before a leadership meeting and close again,

200
00:07:37,520 --> 00:07:39,000
that's not what we're talking about.

201
00:07:39,000 --> 00:07:41,520
The reporting APIs in graph give you programmatic access

202
00:07:41,520 --> 00:07:44,440
to the raw behavioral signals underneath every major workload,

203
00:07:44,440 --> 00:07:47,520
exchange mailbox activity, how many emails were sent,

204
00:07:47,520 --> 00:07:51,400
received, or read per user, teams usage, meetings organized,

205
00:07:51,400 --> 00:07:53,680
chat messages, and audio duration.

206
00:07:53,680 --> 00:07:57,560
SharePoint file activity, files accessed, modified, or shared.

207
00:07:57,560 --> 00:08:01,200
OneDrive analytics, files uploaded or shared externally.

208
00:08:01,200 --> 00:08:03,760
And license utilization, which features assigned users

209
00:08:03,760 --> 00:08:06,120
are actually using across every SQL in your tenant.

210
00:08:06,120 --> 00:08:09,400
All of it queryable, all of it available in four-time windows,

211
00:08:09,400 --> 00:08:13,240
seven days, 30 days, 90 days, and 180 days.

212
00:08:13,240 --> 00:08:15,880
Now here's the critical distinction most teams miss.

213
00:08:15,880 --> 00:08:17,800
The reporting APIs don't give you KPIs.

214
00:08:17,800 --> 00:08:19,200
They give you raw signals.

215
00:08:19,200 --> 00:08:22,600
There's no endpoint that returns your team's adoption is 73%

216
00:08:22,600 --> 00:08:23,800
and trending up.

217
00:08:23,800 --> 00:08:26,240
What you get is the behavioral data, the meaning,

218
00:08:26,240 --> 00:08:29,400
the business meaning, that's something your organization has to define,

219
00:08:29,400 --> 00:08:32,360
that distinction matters enormously for how you design dashboards.

220
00:08:32,360 --> 00:08:36,440
Because the mistake most teams make is treating the raw signal

221
00:08:36,440 --> 00:08:38,000
as if it were the finished inside.

222
00:08:38,000 --> 00:08:40,280
They pull the report, they drop the numbers into a slide,

223
00:08:40,280 --> 00:08:42,680
and they present team's active users this month.

224
00:08:42,680 --> 00:08:45,160
As if that number means something in isolation, it doesn't.

225
00:08:45,160 --> 00:08:47,080
Active users relative to license users.

226
00:08:47,080 --> 00:08:48,280
That's a meaningful ratio.

227
00:08:48,280 --> 00:08:51,120
Active users by department compare it against the same period

228
00:08:51,120 --> 00:08:52,280
after a training rollout.

229
00:08:52,280 --> 00:08:54,000
That tells you whether the training worked.

230
00:08:54,000 --> 00:08:57,600
Meeting hours per user per week tracked against productivity self-reporting.

231
00:08:57,600 --> 00:08:58,880
That's a burnout signal.

232
00:08:58,880 --> 00:09:01,440
The data is only as useful as the question you're asking of it.

233
00:09:01,440 --> 00:09:04,200
There's also a timing reality you need to design around.

234
00:09:04,200 --> 00:09:07,960
These reports lag, typically 24 to 72 hours behind real time.

235
00:09:07,960 --> 00:09:10,720
Some workloads lag more depending on how Microsoft processes

236
00:09:10,720 --> 00:09:12,040
the underlying telemetry.

237
00:09:12,040 --> 00:09:14,120
So if you're building a dashboard that's supposed to show you

238
00:09:14,120 --> 00:09:16,360
what happened yesterday, you need to account for that.

239
00:09:16,360 --> 00:09:18,600
The reporting APIs are built for trend analysis,

240
00:09:18,600 --> 00:09:20,280
not operational monitoring.

241
00:09:20,280 --> 00:09:22,840
Design your systems accordingly, rolling 30 day averages,

242
00:09:22,840 --> 00:09:25,160
week-over-week trend lines, directional signals,

243
00:09:25,160 --> 00:09:26,680
not live counters.

244
00:09:26,680 --> 00:09:29,720
With that in mind, four report families are worth building against,

245
00:09:29,720 --> 00:09:32,520
specifically because executives ask about them directly.

246
00:09:32,520 --> 00:09:35,360
First, adoption reports, who is using which services

247
00:09:35,360 --> 00:09:37,840
at what depth across which parts of the organization?

248
00:09:37,840 --> 00:09:40,560
This is the are we getting value from our licenses question.

249
00:09:40,560 --> 00:09:43,600
Second, engagement reports, not just whether people logged in,

250
00:09:43,600 --> 00:09:45,640
but whether they're actually using the capabilities.

251
00:09:45,640 --> 00:09:48,480
Are they participating in Teams meetings or just attending passively?

252
00:09:48,480 --> 00:09:50,600
Are they co-authoring documents or just reading them?

253
00:09:50,600 --> 00:09:53,720
Engagement is a depth signal, not a volume signal.

254
00:09:53,720 --> 00:09:56,120
Third, governance reports, which SharePoint sites

255
00:09:56,120 --> 00:09:57,760
have had no activity in six months?

256
00:09:57,760 --> 00:10:00,760
Which teams channels were created used twice and abandoned?

257
00:10:00,760 --> 00:10:03,880
Which one driver counts belong to people who left the organization?

258
00:10:03,880 --> 00:10:06,520
Governance reporting via graph isn't about compliance.

259
00:10:06,520 --> 00:10:09,240
It's about organizational housekeeping at scale.

260
00:10:09,240 --> 00:10:11,960
Fourth, operational health, license utilization

261
00:10:11,960 --> 00:10:14,080
is the most immediate cost signal here.

262
00:10:14,080 --> 00:10:17,120
Which users have E5 licenses, but only use capabilities

263
00:10:17,120 --> 00:10:18,360
that come with E3.

264
00:10:18,360 --> 00:10:20,320
That's a direct cost optimization question.

265
00:10:20,320 --> 00:10:22,000
Graph gives you the data to answer it,

266
00:10:22,000 --> 00:10:23,480
not through a consultant engagement,

267
00:10:23,480 --> 00:10:25,560
not through a quarterly spreadsheet exercise,

268
00:10:25,560 --> 00:10:27,880
programmatically, on a schedule, automatically.

269
00:10:27,880 --> 00:10:29,520
The organization's getting the most out of this,

270
00:10:29,520 --> 00:10:32,320
aren't just pulling reports that they're building metric pipelines.

271
00:10:32,320 --> 00:10:35,320
Graph on a scheduled pull, normalized into a data model,

272
00:10:35,320 --> 00:10:38,640
published into Power BI with executive-friendly definitions.

273
00:10:38,640 --> 00:10:41,040
The raw signal becomes institutional intelligence,

274
00:10:41,040 --> 00:10:44,360
but usage data, as rich as it is, only tells you what happened.

275
00:10:44,360 --> 00:10:45,560
It tells you the behavior.

276
00:10:45,560 --> 00:10:48,080
It doesn't tell you the decisions underneath the behavior.

277
00:10:48,080 --> 00:10:50,120
For that, you need the audit logs.

278
00:10:50,120 --> 00:10:52,880
Building executive dashboards from graph report data.

279
00:10:52,880 --> 00:10:55,680
Let's look at what happens when you stop treating raw signals as noise

280
00:10:55,680 --> 00:10:57,600
and start building something real with them.

281
00:10:57,600 --> 00:10:59,880
Microsoft partnered with a company called GainX

282
00:10:59,880 --> 00:11:01,720
on a project that proves this point.

283
00:11:01,720 --> 00:11:05,120
They used graph data connect to analyze collaboration patterns

284
00:11:05,120 --> 00:11:09,200
and work distribution across a portfolio worth nearly $900 million.

285
00:11:09,200 --> 00:11:10,560
What they found was a wake-up call.

286
00:11:10,560 --> 00:11:13,840
Over 800 resources were sitting idle across active projects

287
00:11:13,840 --> 00:11:15,800
while teams were drowning in work elsewhere.

288
00:11:15,800 --> 00:11:18,920
They identified $29 million in productivity losses

289
00:11:18,920 --> 00:11:21,080
because employees were isolated from the information

290
00:11:21,080 --> 00:11:22,520
they needed to do their jobs.

291
00:11:22,520 --> 00:11:25,680
On top of that, they found $38 million in duplicate work

292
00:11:25,680 --> 00:11:28,440
where different teams were solving the exact same problems

293
00:11:28,440 --> 00:11:30,280
because they couldn't see each other's efforts.

294
00:11:30,280 --> 00:11:32,880
None of those numbers showed up on a standard status report.

295
00:11:32,880 --> 00:11:34,960
You couldn't find them in a project dashboard.

296
00:11:34,960 --> 00:11:37,520
They only became visible when someone asked graph

297
00:11:37,520 --> 00:11:40,120
the right questions about behavioral data at scale.

298
00:11:40,120 --> 00:11:43,080
That is the real executive case for building against these APIs.

299
00:11:43,080 --> 00:11:45,800
It isn't about saving a few minutes of efficiency here and there.

300
00:11:45,800 --> 00:11:48,600
It's about quantifying value at the portfolio level.

301
00:11:48,600 --> 00:11:51,080
When you design an executive dashboard from graph data,

302
00:11:51,080 --> 00:11:53,360
the first question isn't which endpoint to call.

303
00:11:53,360 --> 00:11:56,280
The question is, what your leadership team actually needs to know

304
00:11:56,280 --> 00:11:57,280
to make a decision?

305
00:11:57,280 --> 00:11:58,680
Start with the business problem

306
00:11:58,680 --> 00:12:01,240
and then find the graph fields that provide the answer.

307
00:12:01,240 --> 00:12:04,480
I recommend using a five panel scorecard to keep things clear.

308
00:12:04,480 --> 00:12:06,400
The first panel covers security and risk to show

309
00:12:06,400 --> 00:12:08,800
if the organization is getting safer or more exposed.

310
00:12:08,800 --> 00:12:11,360
The second focuses on compliance and data governance

311
00:12:11,360 --> 00:12:13,800
to ensure policies cover the right areas.

312
00:12:13,800 --> 00:12:16,200
The third tracks adoption and AI to see if people

313
00:12:16,200 --> 00:12:18,240
are actually using tools like co-pilot.

314
00:12:18,240 --> 00:12:20,040
The fourth looks at cost and efficiency

315
00:12:20,040 --> 00:12:22,320
to make sure licensing matches actual usage.

316
00:12:22,320 --> 00:12:24,520
Finally, the fifth panel monitors governance health

317
00:12:24,520 --> 00:12:25,960
to see if the structure is holding

318
00:12:25,960 --> 00:12:27,840
or if sprawl is creating new risks.

319
00:12:27,840 --> 00:12:30,480
Each of these panels pulls from different graph report families

320
00:12:30,480 --> 00:12:33,000
to tell a specific part of the story.

321
00:12:33,000 --> 00:12:35,920
Adoption panels use teams and SharePoint usage reports

322
00:12:35,920 --> 00:12:38,040
while security panels pull from sign-in logs

323
00:12:38,040 --> 00:12:39,320
and secure score data.

324
00:12:39,320 --> 00:12:41,560
Cost panels rely on license utilization

325
00:12:41,560 --> 00:12:44,320
and governance panels look at stale resource detection.

326
00:12:44,320 --> 00:12:46,440
These five areas don't compete with each other,

327
00:12:46,440 --> 00:12:48,280
but instead they work together to explain

328
00:12:48,280 --> 00:12:50,360
how the organization is actually functioning.

329
00:12:50,360 --> 00:12:51,960
Power BI is almost always the best way

330
00:12:51,960 --> 00:12:53,560
to show this data to leadership.

331
00:12:53,560 --> 00:12:56,440
You set up a service principle to pull graph data on a schedule

332
00:12:56,440 --> 00:12:58,840
and then normalize it into a model with clear labels

333
00:12:58,840 --> 00:13:00,240
that humans can understand.

334
00:13:00,240 --> 00:13:02,080
Executives don't want to look at JSON files

335
00:13:02,080 --> 00:13:03,240
or raw data strings.

336
00:13:03,240 --> 00:13:05,680
They need to see trend lines and threshold indicators

337
00:13:05,680 --> 00:13:07,280
that tell them when to take action.

338
00:13:07,280 --> 00:13:09,480
Your job is to translate that raw signal

339
00:13:09,480 --> 00:13:10,800
into a clear direction.

340
00:13:10,800 --> 00:13:13,080
One dashboard you should definitely build right now

341
00:13:13,080 --> 00:13:15,000
is a co-pilot adoption tracker.

342
00:13:15,000 --> 00:13:17,480
Graph telemetry shows you exactly who is using the tool

343
00:13:17,480 --> 00:13:19,520
and which departments have licensed seats

344
00:13:19,520 --> 00:13:20,960
that are just sitting empty.

345
00:13:20,960 --> 00:13:23,880
This is important because of the 3.3% problem

346
00:13:23,880 --> 00:13:26,560
where only about a third of licensed users are actually active.

347
00:13:26,560 --> 00:13:29,520
Most organizations assume everyone is using what they paid for

348
00:13:29,520 --> 00:13:31,320
but graph tells you the truth about what's happening

349
00:13:31,320 --> 00:13:32,160
on the ground.

350
00:13:32,160 --> 00:13:35,440
There was also a major structural shift in January of 2026

351
00:13:35,440 --> 00:13:36,600
that you need to understand.

352
00:13:36,600 --> 00:13:38,520
Microsoft redesigned the adoption score

353
00:13:38,520 --> 00:13:41,560
and retired the technology experience component entirely.

354
00:13:41,560 --> 00:13:43,840
The full score now reflects only people experiences

355
00:13:43,840 --> 00:13:45,760
based on behavioral signals from graph.

356
00:13:45,760 --> 00:13:47,880
It measures how people communicate, how they meet

357
00:13:47,880 --> 00:13:49,440
and how they collaborate.

358
00:13:49,440 --> 00:13:51,720
This is now the official measure of digital transformation

359
00:13:51,720 --> 00:13:53,000
progress for Microsoft.

360
00:13:53,000 --> 00:13:55,560
If you're reporting on M365 value to your leadership,

361
00:13:55,560 --> 00:13:57,240
you're reporting on graph derived behavior

362
00:13:57,240 --> 00:13:58,600
whether you realize it or not.

363
00:13:58,600 --> 00:14:00,480
The reality is that usage data isn't just

364
00:14:00,480 --> 00:14:01,760
a reporting exercise.

365
00:14:01,760 --> 00:14:04,760
It's the only way your organization can truly see itself.

366
00:14:04,760 --> 00:14:06,880
The quality of that image depends entirely

367
00:14:06,880 --> 00:14:09,680
on whether you've built the pipeline to bring it to the surface.

368
00:14:09,680 --> 00:14:11,800
Usage data shows you the surface of the water.

369
00:14:11,800 --> 00:14:14,360
Audit logs show you what's happening underneath.

370
00:14:14,360 --> 00:14:17,440
Audit logs and sign in logs, the organizational memory.

371
00:14:17,440 --> 00:14:20,440
Think of audit logs as the flight recorder for your entire organization.

372
00:14:20,440 --> 00:14:22,920
They don't just show what the company looks like from the outside

373
00:14:22,920 --> 00:14:26,320
but they record exactly what happened inside second by second.

374
00:14:26,320 --> 00:14:28,600
Graph gives you access to three different log types

375
00:14:28,600 --> 00:14:32,200
through the audit logs endpoint and each one solves a different problem.

376
00:14:32,200 --> 00:14:34,480
Directory audit logs are for your governance questions.

377
00:14:34,480 --> 00:14:36,080
They tell you who changed the role,

378
00:14:36,080 --> 00:14:37,920
who added a user to a sensitive group

379
00:14:37,920 --> 00:14:39,920
or who modified a security policy.

380
00:14:39,920 --> 00:14:42,840
Every administrative action taken against your enter ID tenant

381
00:14:42,840 --> 00:14:43,880
leaves a record here.

382
00:14:43,880 --> 00:14:46,880
This is your evidence for how well your governance is actually working.

383
00:14:46,880 --> 00:14:49,520
Sign in logs are where you see your real security posture.

384
00:14:49,520 --> 00:14:51,440
They show who authenticated where they were

385
00:14:51,440 --> 00:14:54,400
and what the security engine decided about that request.

386
00:14:54,400 --> 00:14:57,760
You can see if MFA was used or if a device was flagged as risky.

387
00:14:57,760 --> 00:15:00,440
These logs aren't a theoretical policy on a shelf

388
00:15:00,440 --> 00:15:03,440
but a real time record of what your security infrastructure did

389
00:15:03,440 --> 00:15:05,320
during every single session.

390
00:15:05,320 --> 00:15:07,880
Provisioning logs handle the life cycle of your users.

391
00:15:07,880 --> 00:15:10,720
When HR hires someone, you can see if the account actually appeared

392
00:15:10,720 --> 00:15:12,400
on day one like it was supposed to.

393
00:15:12,400 --> 00:15:14,400
When someone leaves the company, these logs prove

394
00:15:14,400 --> 00:15:16,160
if the off-boarding happened on time.

395
00:15:16,160 --> 00:15:19,280
This is how you measure the effectiveness of your join-on-mover-leaver process

396
00:15:19,280 --> 00:15:20,280
in the real world.

397
00:15:20,280 --> 00:15:22,400
Before you start building, you have to understand

398
00:15:22,400 --> 00:15:24,120
how long this data stays around.

399
00:15:24,120 --> 00:15:26,200
Graph only gives you what the service retains

400
00:15:26,200 --> 00:15:29,000
and those windows change based on what you pay for.

401
00:15:29,000 --> 00:15:33,200
In October of 2023, Microsoft increased the default retention

402
00:15:33,200 --> 00:15:36,560
for audit standard from 90 days to 180 days.

403
00:15:36,560 --> 00:15:39,320
If you have audit premium through an E5 license

404
00:15:39,320 --> 00:15:41,320
that window extends to a full year.

405
00:15:41,320 --> 00:15:44,400
Some organizations even use a 10-year add-on for regulatory reasons.

406
00:15:44,400 --> 00:15:47,280
The best way to handle this is to use Graph for real-time access

407
00:15:47,280 --> 00:15:50,480
and then export the data to log analytics for long term storage.

408
00:15:50,480 --> 00:15:53,920
You use Graph for the live work and log analytics for the history.

409
00:15:53,920 --> 00:15:55,160
Once your storage is set up,

410
00:15:55,160 --> 00:15:58,560
there are five specific metrics you should build for your leadership team.

411
00:15:58,560 --> 00:16:00,760
First, track high-privileged access changes.

412
00:16:00,760 --> 00:16:04,000
You need to know how many people were given global admin rights this month

413
00:16:04,000 --> 00:16:06,280
and if that number is trending up or down.

414
00:16:06,280 --> 00:16:10,000
The direction of the trend is much more important than the number itself.

415
00:16:10,000 --> 00:16:13,000
Second, look at your MFA and conditional access coverage.

416
00:16:13,000 --> 00:16:16,320
You need to see what percentage of sign-ins actually used MFA

417
00:16:16,320 --> 00:16:18,160
and how many bypassed your policies.

418
00:16:18,160 --> 00:16:20,320
These gaps are exactly what attackers look for

419
00:16:20,320 --> 00:16:22,200
and Graph gives you the data to close them.

420
00:16:22,200 --> 00:16:24,480
Third, monitor sensitive group memberships.

421
00:16:24,480 --> 00:16:27,840
You should flag any time someone is added to a group that controls financial systems

422
00:16:27,840 --> 00:16:28,920
or executive emails.

423
00:16:28,920 --> 00:16:33,520
These changes should be rare and they should always be reviewed by someone else.

424
00:16:33,520 --> 00:16:36,760
Fourth, measure how well your off-boarding process actually works.

425
00:16:36,760 --> 00:16:39,160
Cross-reference your provisioning logs with HR records

426
00:16:39,160 --> 00:16:42,800
to see the average time it takes to disable an account after someone is fired.

427
00:16:42,800 --> 00:16:47,080
If accounts stay active for days after someone leaves, your process is broken.

428
00:16:47,080 --> 00:16:49,240
Fifth, watch the concentration of changes.

429
00:16:49,240 --> 00:16:52,680
You want to see how many high-impact configuration changes happened and who made them.

430
00:16:52,680 --> 00:16:57,640
Risk increases when only one or two people are making all the major changes to your environment.

431
00:16:57,640 --> 00:17:01,520
When you present this to your bosses, the format is just as important as the data.

432
00:17:01,520 --> 00:17:06,040
Start with a high-level summary that shows an overall risk rating and a few headline findings.

433
00:17:06,040 --> 00:17:08,080
Then use a simple structure for each point.

434
00:17:08,080 --> 00:17:09,120
What is the current state?

435
00:17:09,120 --> 00:17:10,080
What is the problem?

436
00:17:10,080 --> 00:17:11,200
And what should we do about it?

437
00:17:11,200 --> 00:17:15,040
Use heat maps for the big patterns and save the raw tables for the technical teams.

438
00:17:15,040 --> 00:17:18,080
Executives need a clear signal so they can make a decision.

439
00:17:18,080 --> 00:17:20,320
Audit logs tell you what changed in the past.

440
00:17:20,320 --> 00:17:23,320
Change notifications tell you the second it happens in the present.

441
00:17:23,320 --> 00:17:27,280
Delta queries and change notifications near real-time intelligence.

442
00:17:27,280 --> 00:17:30,400
Most integrations built on graph share a common design flaw.

443
00:17:30,400 --> 00:17:31,280
They poll.

444
00:17:31,280 --> 00:17:36,200
Every 15 minutes, every hour or every morning at 6 a script wakes up and fetches a full data set.

445
00:17:36,200 --> 00:17:40,480
It compares that data against what it found last time and tries to figure out what changed.

446
00:17:40,480 --> 00:17:42,240
That pattern works at small scale.

447
00:17:42,240 --> 00:17:43,920
At organizational scale it breaks.

448
00:17:43,920 --> 00:17:48,320
It's slow because the gap between an event and your awareness of it is the length of your polling interval.

449
00:17:48,320 --> 00:17:52,880
It's expensive because you're fetching everything just to find the tiny fraction that actually matters.

450
00:17:52,880 --> 00:17:53,880
And it's fragile.

451
00:17:53,880 --> 00:17:58,120
If your comparison logic misses a single edge case, you lose that change forever.

452
00:17:58,120 --> 00:18:01,480
Graph has two mechanisms designed specifically to eliminate that problem.

453
00:18:01,480 --> 00:18:03,600
Delta queries and change notifications.

454
00:18:03,600 --> 00:18:05,520
They solve different parts of the same challenge.

455
00:18:05,520 --> 00:18:09,600
When you use them together, they become the foundation of a serious real-time architecture.

456
00:18:09,600 --> 00:18:11,120
Delta queries work like this.

457
00:18:11,120 --> 00:18:14,640
The first time you call a delta enabled endpoint, you get the full data set.

458
00:18:14,640 --> 00:18:18,560
You get every user, every group and every security entity you're tracking.

459
00:18:18,560 --> 00:18:20,800
Along with that response, graph returns a delta token.

460
00:18:20,800 --> 00:18:21,840
Think of it as a cursor.

461
00:18:21,840 --> 00:18:24,600
It represents your exact position in the change stream.

462
00:18:24,600 --> 00:18:27,120
The next time you call that endpoint, you don't ask for everything.

463
00:18:27,120 --> 00:18:31,600
You pass the delta token and graph returns only what changed since that token was issued.

464
00:18:31,600 --> 00:18:35,200
New records, modified records, deleted records, nothing else.

465
00:18:35,200 --> 00:18:37,600
The payload is small, the latency is low,

466
00:18:37,600 --> 00:18:39,440
and because graph tracks the state on its side,

467
00:18:39,440 --> 00:18:42,960
your integration doesn't need to maintain a massive comparison database.

468
00:18:42,960 --> 00:18:46,080
That architecture scales in a way that polling simply cannot.

469
00:18:46,080 --> 00:18:50,400
You aren't fetching 10,000 user records just to find the three people who changed departments.

470
00:18:50,400 --> 00:18:54,240
You're fetching three records because graph already knows those are the only three that matter.

471
00:18:54,240 --> 00:18:55,680
Change notifications.

472
00:18:55,680 --> 00:18:57,120
Sometimes called webhooks.

473
00:18:57,120 --> 00:18:59,040
Solve the other half of the problem.

474
00:18:59,040 --> 00:19:02,320
Instead of you calling graph to ask what changed, graph calls you.

475
00:19:02,320 --> 00:19:03,560
You subscribe to a resource.

476
00:19:03,560 --> 00:19:06,640
When something changes, graph sends a notification to your endpoint.

477
00:19:06,640 --> 00:19:07,880
No polling required.

478
00:19:07,880 --> 00:19:10,000
The event reaches you the moment it's recorded.

479
00:19:10,000 --> 00:19:12,080
The subscription model covers almost everything.

480
00:19:12,080 --> 00:19:16,560
Group creation, team membership changes, user updates, security alerts, and calendar events.

481
00:19:16,560 --> 00:19:18,240
The notification itself is lightweight.

482
00:19:18,240 --> 00:19:21,520
It tells you something changed and gives you enough context to know what happened,

483
00:19:21,520 --> 00:19:23,600
but it doesn't always contain the full details.

484
00:19:23,600 --> 00:19:24,560
That's intentional.

485
00:19:24,560 --> 00:19:27,920
For the full picture, you combine the notification with a delta query.

486
00:19:27,920 --> 00:19:29,760
The notification tells you something happened.

487
00:19:29,760 --> 00:19:31,680
And the delta token tells you exactly what.

488
00:19:31,680 --> 00:19:34,640
This is the operational design principle worth internalizing.

489
00:19:34,640 --> 00:19:36,400
Subscriptions for immediacy.

490
00:19:36,400 --> 00:19:38,000
Delta tokens for precision.

491
00:19:38,000 --> 00:19:39,760
Neither alone gives you the full picture.

492
00:19:39,760 --> 00:19:44,400
Together, they give you a near real-time change stream over your organizational data

493
00:19:44,400 --> 00:19:46,240
that is both efficient and complete.

494
00:19:46,240 --> 00:19:49,840
Two patterns show up repeatedly in mature graph implementations.

495
00:19:49,840 --> 00:19:51,440
The first is governance automation.

496
00:19:51,440 --> 00:19:53,120
You subscribe to Group Creation Events.

497
00:19:53,120 --> 00:19:56,800
The moment a new team appears, you validate it against your governance rules.

498
00:19:56,800 --> 00:19:58,480
Does the name follow the policy?

499
00:19:58,480 --> 00:20:00,240
Is there a sensitivity label?

500
00:20:00,240 --> 00:20:01,600
Are there at least two owners?

501
00:20:01,600 --> 00:20:04,880
If not, and as your function fires, applies the fix and logs the action.

502
00:20:04,880 --> 00:20:08,240
The whole cycle completes in seconds, not hours, not days.

503
00:20:08,240 --> 00:20:13,120
There is no manual review queue and no weekly audit report that's already stale by the time anyone reads it.

504
00:20:13,120 --> 00:20:15,280
The second is the security operations pattern.

505
00:20:15,280 --> 00:20:19,040
You subscribe to security alert changes across your entire graph surface.

506
00:20:19,040 --> 00:20:23,040
When an alert fires or escalates, your SOAR workflow triggers immediately.

507
00:20:23,040 --> 00:20:27,360
There is no polling loop running every five minutes, hoping to catch a breach before it matters.

508
00:20:27,360 --> 00:20:30,960
The alert arrives, the workflow starts, and your security team is already responding

509
00:20:30,960 --> 00:20:33,760
before a polling-based system would even know the event existed.

510
00:20:33,760 --> 00:20:35,200
The shift here isn't technical.

511
00:20:35,200 --> 00:20:36,240
It's architectural.

512
00:20:36,240 --> 00:20:37,920
From batch to event-driven.

513
00:20:37,920 --> 00:20:40,800
From periodic awareness to continuous intelligence.

514
00:20:40,800 --> 00:20:42,400
Identity governance APIs.

515
00:20:42,400 --> 00:20:44,000
Where policy becomes reality.

516
00:20:44,000 --> 00:20:45,920
Most organizations have governance policies.

517
00:20:45,920 --> 00:20:48,160
They're usually sitting in a share-point site somewhere.

518
00:20:48,160 --> 00:20:51,760
It's a PDF titled Access Management Policy that someone wrote three years ago,

519
00:20:51,760 --> 00:20:54,960
got approved by a committee, and has been quietly ignored ever since.

520
00:20:54,960 --> 00:20:58,880
Not because people are malicious, but because there's no mechanism connecting that document

521
00:20:58,880 --> 00:21:01,680
to the actual behavior of the systems it's supposed to govern.

522
00:21:01,680 --> 00:21:04,080
That's the GAP Identity Governance APIs close.

523
00:21:04,080 --> 00:21:05,440
And it's a massive GAP.

524
00:21:05,440 --> 00:21:09,280
Because the distance between "we have a policy" and "we are actually doing it"

525
00:21:09,280 --> 00:21:11,040
is where organizational risk lives.

526
00:21:11,040 --> 00:21:13,360
Graph gives you the infrastructure to cross it.

527
00:21:13,360 --> 00:21:14,800
Start with Access Reviews.

528
00:21:14,800 --> 00:21:18,960
Through Graph, you can programmatically create, schedule, and report on access certifications.

529
00:21:18,960 --> 00:21:20,400
Who still needs access to what?

530
00:21:20,400 --> 00:21:23,120
When you ask that question manually, it takes weeks of spreadsheet work

531
00:21:23,120 --> 00:21:26,000
and produces results that are stale before you're even finished.

532
00:21:26,000 --> 00:21:29,120
When you ask it via Graph, it becomes a continuous process.

533
00:21:29,120 --> 00:21:33,280
You define the scope, you set the cadence, and you specify the reviewers.

534
00:21:33,280 --> 00:21:34,800
Graph handles the orchestration.

535
00:21:34,800 --> 00:21:37,360
Reviewers get prompted, decisions get recorded,

536
00:21:37,360 --> 00:21:40,640
non-responses trigger an automatic denial if that's your policy.

537
00:21:40,640 --> 00:21:44,720
The entire life cycle is auditable through the same log surfaces we covered earlier.

538
00:21:44,720 --> 00:21:46,720
Entitlement management takes this further.

539
00:21:46,720 --> 00:21:50,400
Managing access on a per user, per resource basis, does not scale.

540
00:21:50,400 --> 00:21:52,000
Instead, you define access packages.

541
00:21:52,000 --> 00:21:54,880
These are bundles of rights that represent a role or a project.

542
00:21:54,880 --> 00:21:57,600
A new marketing coordinator needs SharePoint sites,

543
00:21:57,600 --> 00:21:59,600
a Teams channel, a shared mailbox,

544
00:21:59,600 --> 00:22:00,720
and two security groups.

545
00:22:00,720 --> 00:22:02,160
That is one access package.

546
00:22:02,160 --> 00:22:02,960
They request it.

547
00:22:02,960 --> 00:22:06,160
An approver clicks a button, graph provisions everything, and critically.

548
00:22:06,160 --> 00:22:07,440
You define a time boundary.

549
00:22:07,440 --> 00:22:10,640
The access expires in six months unless it's explicitly renewed.

550
00:22:10,640 --> 00:22:14,320
Entitlement management is how you stop permission accumulation before it starts

551
00:22:14,320 --> 00:22:17,520
rather than trying to audit your way out of it after years of drift.

552
00:22:17,520 --> 00:22:20,560
Life cycle workflows are where Graph connects to HR events.

553
00:22:20,560 --> 00:22:23,120
When a new higher record appears in your HR system,

554
00:22:23,120 --> 00:22:25,120
Graph can trigger a workflow.

555
00:22:25,120 --> 00:22:29,840
Account provisioning, group memberships, license assignment, welcome emails.

556
00:22:29,840 --> 00:22:32,240
All of it is automated and timed to the start date,

557
00:22:32,240 --> 00:22:34,800
not to whenever IT happened to notice a ticket in the queue.

558
00:22:34,800 --> 00:22:36,240
The same applies to departures.

559
00:22:36,240 --> 00:22:39,840
Account disabling, license removal, and manager notifications happen instantly.

560
00:22:39,840 --> 00:22:42,880
The joiner mover lever process stops being a manual checklist

561
00:22:42,880 --> 00:22:44,640
and becomes an event-driven workflow

562
00:22:44,640 --> 00:22:46,720
that executes consistently every single time.

563
00:22:46,720 --> 00:22:49,600
The PIM integration extends this into privileged access.

564
00:22:49,600 --> 00:22:52,320
Privileged identity management, exposed through Graph,

565
00:22:52,320 --> 00:22:55,520
gives you just-in-time elevation for high-privileged roles.

566
00:22:55,520 --> 00:22:58,000
Nobody holds standing global administrator access.

567
00:22:58,000 --> 00:22:59,440
When they need it, they activate.

568
00:22:59,440 --> 00:23:01,360
The activation is time-bounded and logged.

569
00:23:01,360 --> 00:23:04,560
The approval workflow runs before the elevation takes effect.

570
00:23:04,560 --> 00:23:06,720
Because Graph exposes the full activation history,

571
00:23:06,720 --> 00:23:09,840
you can build reports that show exactly who elevated for how long

572
00:23:09,840 --> 00:23:11,520
and what they did during that window.

573
00:23:11,520 --> 00:23:14,640
There is one executive metric that ties all of this together.

574
00:23:14,640 --> 00:23:15,840
Net-privileged growth.

575
00:23:15,840 --> 00:23:19,920
Are role assignments growing faster than role removals?

576
00:23:19,920 --> 00:23:22,000
In most organizations, the answer is yes.

577
00:23:22,000 --> 00:23:25,040
Access accumulates while cleanup remains sporadic.

578
00:23:25,040 --> 00:23:26,720
This is a structural drift problem.

579
00:23:26,720 --> 00:23:28,720
Graph audit logs answer this directly.

580
00:23:28,720 --> 00:23:30,320
Assignments in assignments out

581
00:23:30,320 --> 00:23:31,840
and the net change over time.

582
00:23:31,840 --> 00:23:34,480
That's a board-level security metric built entirely from data

583
00:23:34,480 --> 00:23:35,840
that's already being generated.

584
00:23:35,840 --> 00:23:37,760
Here is what this looks like in the real world.

585
00:23:37,760 --> 00:23:39,840
One organization with no formal lever process

586
00:23:39,840 --> 00:23:42,080
ran a single graph query against their directory.

587
00:23:42,080 --> 00:23:43,680
They filtered for active licenses

588
00:23:43,680 --> 00:23:46,640
and cross-reference them against HR termination records.

589
00:23:46,640 --> 00:23:49,520
23% of departed employees still had active access.

590
00:23:49,520 --> 00:23:50,880
It wasn't because of negligence.

591
00:23:50,880 --> 00:23:53,520
It was because there was no automated mechanism

592
00:23:53,520 --> 00:23:56,800
enforcing the policy they already had on paper.

593
00:23:56,800 --> 00:23:58,880
Identity governance controls who has access.

594
00:23:58,880 --> 00:24:02,640
Guest access governance controls who shouldn't have it at all.

595
00:24:02,640 --> 00:24:06,000
Guest access and external collaboration governance.

596
00:24:06,000 --> 00:24:07,600
Every team's channel invite.

597
00:24:07,600 --> 00:24:09,840
Every SharePoint link shared with a vendor.

598
00:24:09,840 --> 00:24:11,760
Every external collaboration request clicked

599
00:24:11,760 --> 00:24:13,680
by someone just trying to hit a deadline.

600
00:24:13,680 --> 00:24:15,760
Each one of those actions creates a guest account

601
00:24:15,760 --> 00:24:18,480
in your EntraID tenant and in most organizations.

602
00:24:18,480 --> 00:24:19,440
Nobody is counting.

603
00:24:19,440 --> 00:24:20,720
That's not an exaggeration.

604
00:24:20,720 --> 00:24:22,560
If you go to your EntraID portal right now

605
00:24:22,560 --> 00:24:24,560
and filter users by guest account type,

606
00:24:24,560 --> 00:24:26,400
the number will be higher than you expect.

607
00:24:26,400 --> 00:24:28,800
It's usually double or triple what IT thinks it is.

608
00:24:28,800 --> 00:24:31,040
Because guest accounts accumulate quietly,

609
00:24:31,040 --> 00:24:32,960
they sit in the background of every project.

610
00:24:32,960 --> 00:24:34,800
They have no automatic expiry.

611
00:24:34,800 --> 00:24:36,160
They have no central inventory.

612
00:24:36,160 --> 00:24:37,040
Graph fixes that.

613
00:24:37,040 --> 00:24:38,480
One query.

614
00:24:38,480 --> 00:24:42,240
Users, filter, user type, EQ, guest.

615
00:24:42,240 --> 00:24:43,920
You get the full external population.

616
00:24:43,920 --> 00:24:45,360
You see when the account was created,

617
00:24:45,360 --> 00:24:46,720
the last sign-in timestamp

618
00:24:46,720 --> 00:24:49,120
and exactly what groups or applications they can access.

619
00:24:49,120 --> 00:24:50,560
When you schedule that query weekly

620
00:24:50,560 --> 00:24:51,520
and load it into a report,

621
00:24:51,520 --> 00:24:54,560
you finally have the inventory your organization is missing.

622
00:24:54,560 --> 00:24:56,240
And the inventory reveals the pattern.

623
00:24:56,240 --> 00:24:58,000
The biggest risk is the stale guest.

624
00:24:58,000 --> 00:25:01,040
This is an account that was active for project six months ago.

625
00:25:01,040 --> 00:25:02,480
They haven't signed in since,

626
00:25:02,480 --> 00:25:04,640
but they still hold group memberships and file access

627
00:25:04,640 --> 00:25:05,760
that were never cleaned up.

628
00:25:05,760 --> 00:25:07,520
That account isn't a theoretical risk.

629
00:25:07,520 --> 00:25:10,000
It's an active access grant sitting unmonitored.

630
00:25:10,000 --> 00:25:12,560
If that former contractors credentials are ever compromised,

631
00:25:12,560 --> 00:25:14,240
your data is exploitable.

632
00:25:14,240 --> 00:25:15,280
Concretely.

633
00:25:15,280 --> 00:25:17,600
You should build a specific alert for any guest account

634
00:25:17,600 --> 00:25:19,760
with no sign-in activity in 90 days

635
00:25:19,760 --> 00:25:21,360
that still holds group membership.

636
00:25:21,360 --> 00:25:23,280
That combination of a dormant identity

637
00:25:23,280 --> 00:25:26,720
and live access is the definition of an unnecessary attack surface.

638
00:25:26,720 --> 00:25:29,040
Graph gives you both data points in the same query,

639
00:25:29,040 --> 00:25:31,680
making the detection trivial once you've built the pipeline.

640
00:25:31,680 --> 00:25:32,800
Beyond individual accounts,

641
00:25:32,800 --> 00:25:35,840
Graph also exposes how people share at the SharePoint level.

642
00:25:35,840 --> 00:25:37,840
You can see how many sites have content shared

643
00:25:37,840 --> 00:25:40,320
with external users who have sensitive labels applied.

644
00:25:40,320 --> 00:25:42,800
You can track the trend of anonymous link creation

645
00:25:42,800 --> 00:25:44,160
across your entire tenant.

646
00:25:44,160 --> 00:25:45,680
These are governance risk indicators.

647
00:25:45,680 --> 00:25:47,760
They don't belong in an admin report, nobody reads.

648
00:25:47,760 --> 00:25:49,520
They belong on the executive scorecard.

649
00:25:49,520 --> 00:25:51,280
The automation pattern here is simple.

650
00:25:51,280 --> 00:25:54,000
A scheduled graph job runs and identifies guests

651
00:25:54,000 --> 00:25:55,600
matching your stale criteria.

652
00:25:55,600 --> 00:25:57,280
It triggers an approval workflow,

653
00:25:57,280 --> 00:25:59,280
the manager or team owner gets a notification

654
00:25:59,280 --> 00:26:01,440
to confirm if that user still needs access.

655
00:26:01,440 --> 00:26:03,200
If they confirm the account stays,

656
00:26:03,200 --> 00:26:06,000
if they don't respond, the account is cleaned up automatically.

657
00:26:06,000 --> 00:26:08,240
The workflow doesn't require a help desk ticket,

658
00:26:08,240 --> 00:26:10,080
it doesn't require IT to step in.

659
00:26:10,080 --> 00:26:11,600
It runs on its own on schedule

660
00:26:11,600 --> 00:26:13,360
and every single decision is logged.

661
00:26:13,360 --> 00:26:14,960
But here's the problem that's escalating

662
00:26:14,960 --> 00:26:15,840
because of co-pilot.

663
00:26:15,840 --> 00:26:17,920
Co-pilot surfaces content based on permissions.

664
00:26:17,920 --> 00:26:19,520
Any file a user has permission to see

665
00:26:19,520 --> 00:26:21,200
is fair game for co-pilot to find

666
00:26:21,200 --> 00:26:22,640
and include in a response.

667
00:26:22,640 --> 00:26:24,320
Legacy broad permissions.

668
00:26:24,320 --> 00:26:26,560
Like everyone except external users

669
00:26:26,560 --> 00:26:28,320
applied to sensitive libraries years ago.

670
00:26:28,320 --> 00:26:30,000
Those aren't just a data problem anymore.

671
00:26:30,000 --> 00:26:31,120
They're a co-pilot problem.

672
00:26:31,120 --> 00:26:32,720
When someone asks co-pilot a question

673
00:26:32,720 --> 00:26:34,080
that touches a sensitive document,

674
00:26:34,080 --> 00:26:35,440
they technically have permission to see

675
00:26:35,440 --> 00:26:37,200
because of a five-year-old blanket setting.

676
00:26:37,200 --> 00:26:38,640
Co-pilot answers accurately.

677
00:26:38,640 --> 00:26:40,960
That is exactly how unintended disclosures happen.

678
00:26:40,960 --> 00:26:42,720
External access is one risk vector,

679
00:26:42,720 --> 00:26:44,960
but the security API is give you the full picture.

680
00:26:44,960 --> 00:26:47,280
The security API,

681
00:26:47,280 --> 00:26:49,840
from alert aggregation to security fabric,

682
00:26:49,840 --> 00:26:51,680
the graph security API has gone

683
00:26:51,680 --> 00:26:53,760
through a fundamental identity change.

684
00:26:53,760 --> 00:26:55,360
When it launched, the value was simple.

685
00:26:55,360 --> 00:26:57,280
Instead of logging into five different portals

686
00:26:57,280 --> 00:26:59,680
to check alerts, you could query one endpoint.

687
00:26:59,680 --> 00:27:01,680
There was a alert aggregation, one pane of glass.

688
00:27:01,680 --> 00:27:03,040
It was a convenient story.

689
00:27:03,040 --> 00:27:04,320
But that's not what it is anymore.

690
00:27:04,320 --> 00:27:07,920
The graph security API is now a normalized security data plane.

691
00:27:07,920 --> 00:27:10,000
It's not just a window looking at your products.

692
00:27:10,000 --> 00:27:11,680
It's the fabric that connects them.

693
00:27:11,680 --> 00:27:14,400
It brings Microsoft 365 Defender,

694
00:27:14,400 --> 00:27:16,400
EntraID Protection, Intune,

695
00:27:16,400 --> 00:27:18,880
and PerView into one coherent data model.

696
00:27:18,880 --> 00:27:20,640
One query gives you cross-domain results.

697
00:27:20,640 --> 00:27:23,120
That's a different architectural proposition entirely.

698
00:27:23,120 --> 00:27:25,120
But there's a forcing function you need to know about.

699
00:27:25,120 --> 00:27:26,800
The Legacy Alerts API.

700
00:27:26,800 --> 00:27:30,000
The original security alerts endpoint is gone as of April 20, 20,

701
00:27:30,000 --> 00:27:32,000
it's not deprecated, it's gone.

702
00:27:32,000 --> 00:27:34,240
If your CM connector or your custom dashboard

703
00:27:34,240 --> 00:27:37,040
was built against that old endpoint, it stopped working.

704
00:27:37,040 --> 00:27:39,280
For many organizations, this isn't a future risk.

705
00:27:39,280 --> 00:27:40,240
It's a current incident.

706
00:27:40,240 --> 00:27:42,160
The strategic platform is alerts V2.

707
00:27:42,160 --> 00:27:45,040
The security alerts V2 endpoint has a richer schema

708
00:27:45,040 --> 00:27:46,480
and better provider coverage.

709
00:27:46,480 --> 00:27:49,280
When you query it, graph doesn't just return its own data.

710
00:27:49,280 --> 00:27:51,360
It fans out the request to every provider.

711
00:27:51,360 --> 00:27:53,920
From Defender for endpoint to EntraID Protection,

712
00:27:53,920 --> 00:27:56,480
it aggregates the responses, it normalizes them.

713
00:27:56,480 --> 00:27:58,240
It returns unified results.

714
00:27:58,240 --> 00:28:00,480
The query is simple, but the infrastructure behind it

715
00:28:00,480 --> 00:28:02,000
is doing the heavy lifting for you.

716
00:28:02,000 --> 00:28:05,680
This federated model matters because incidents rarely stay in one place.

717
00:28:05,680 --> 00:28:07,120
A fishing email lands an outlook.

718
00:28:07,120 --> 00:28:08,960
The user clicks, a credential is stolen,

719
00:28:08,960 --> 00:28:11,120
an attacker signs in from a new location.

720
00:28:11,120 --> 00:28:12,960
A high-privileged role gets activated.

721
00:28:12,960 --> 00:28:15,200
Each of those events lives in a different product.

722
00:28:15,200 --> 00:28:16,400
But through graph security,

723
00:28:16,400 --> 00:28:18,640
every one of those events is a node in the same graph.

724
00:28:18,640 --> 00:28:21,120
They are connectable and queryable from the same surface.

725
00:28:21,120 --> 00:28:24,240
Secure score is another capability worth building against.

726
00:28:24,240 --> 00:28:25,920
Most organizations see their secure score

727
00:28:25,920 --> 00:28:27,680
as just a number on a dashboard.

728
00:28:27,680 --> 00:28:30,560
But graph exposes secure score control profiles.

729
00:28:30,560 --> 00:28:32,240
This is the breakdown that tells you

730
00:28:32,240 --> 00:28:34,560
which specific controls would have the highest impact

731
00:28:34,560 --> 00:28:35,760
if you turn them on.

732
00:28:35,760 --> 00:28:37,200
It's a prioritization tool.

733
00:28:37,200 --> 00:28:40,480
Security teams use it to build their roadmap.

734
00:28:40,480 --> 00:28:42,880
Executive teams use it to show progress.

735
00:28:42,880 --> 00:28:44,560
Neither of them needs to look at the portal

736
00:28:44,560 --> 00:28:46,640
because the API serves the data directly.

737
00:28:46,640 --> 00:28:49,520
But here is the part most organizations completely miss.

738
00:28:49,520 --> 00:28:51,280
Graph is a dual-edged instrument.

739
00:28:51,280 --> 00:28:53,280
Everything that makes it powerful for defense.

740
00:28:53,280 --> 00:28:55,120
The speed, the depth, the access.

741
00:28:55,120 --> 00:28:56,880
Makes it just as powerful for an attacker

742
00:28:56,880 --> 00:28:58,080
who has a valid token.

743
00:28:58,080 --> 00:28:59,600
A compromised service principle

744
00:28:59,600 --> 00:29:01,600
can enumerate your entire directory.

745
00:29:01,600 --> 00:29:02,720
It can read mailboxes.

746
00:29:02,720 --> 00:29:04,080
It can map your org chart.

747
00:29:04,080 --> 00:29:06,800
All of this happens through legitimate API calls

748
00:29:06,800 --> 00:29:08,800
that look like normal application behavior.

749
00:29:08,800 --> 00:29:10,800
The attack surface isn't a vulnerability in graph.

750
00:29:10,800 --> 00:29:13,360
It's the permission surface you've granted to your own apps.

751
00:29:13,360 --> 00:29:14,880
This means monitoring your graph usage

752
00:29:14,880 --> 00:29:16,400
is a security requirement.

753
00:29:16,400 --> 00:29:17,920
High-volume mailbox reads

754
00:29:17,920 --> 00:29:20,160
from a strange application or directory enumeration

755
00:29:20,160 --> 00:29:22,720
from an unexpected service principle are signals.

756
00:29:22,720 --> 00:29:25,280
But they only become visible if you're actually watching.

757
00:29:25,280 --> 00:29:27,200
Secure score tells you your posture.

758
00:29:27,200 --> 00:29:29,760
Risky users tell you your active exposure.

759
00:29:29,760 --> 00:29:32,880
Risky users, risk detections, and identity protection.

760
00:29:32,880 --> 00:29:34,640
EntraID protection runs in the background

761
00:29:34,640 --> 00:29:36,160
of your tenant every single second.

762
00:29:36,160 --> 00:29:38,080
It evaluates every authentication event

763
00:29:38,080 --> 00:29:39,680
against a machine learning model.

764
00:29:39,680 --> 00:29:42,640
This model is trained on signals from billions of sign-ins

765
00:29:42,640 --> 00:29:44,960
across Microsoft's global infrastructure.

766
00:29:44,960 --> 00:29:46,560
Unusual travel patterns.

767
00:29:46,560 --> 00:29:48,320
Leaked credential databases.

768
00:29:48,320 --> 00:29:51,280
A typical device fingerprint's anonymous proxy usage

769
00:29:51,280 --> 00:29:52,800
password spray signatures.

770
00:29:52,800 --> 00:29:54,560
Each of these produces a detection

771
00:29:54,560 --> 00:29:56,800
and every one of those detections is available to you

772
00:29:56,800 --> 00:29:58,080
through graph.

773
00:29:58,080 --> 00:29:59,440
Three endpoints matter here.

774
00:29:59,440 --> 00:30:00,880
First, risky users.

775
00:30:00,880 --> 00:30:03,280
These are accounts that have gathered enough detection signals

776
00:30:03,280 --> 00:30:04,400
to warrant concern.

777
00:30:04,400 --> 00:30:07,520
They come with a risk level of low, medium, or high

778
00:30:07,520 --> 00:30:09,840
along with a timestamp and the specific detections

779
00:30:09,840 --> 00:30:10,880
that cause the rating.

780
00:30:10,880 --> 00:30:13,040
Second, risky sign-ins.

781
00:30:13,040 --> 00:30:14,800
These are individual authentication events

782
00:30:14,800 --> 00:30:16,080
that triggered risk logic

783
00:30:16,080 --> 00:30:18,480
regardless of whether the user's overall profile

784
00:30:18,480 --> 00:30:19,360
was elevated.

785
00:30:19,360 --> 00:30:21,600
Third, risk detections themselves.

786
00:30:21,600 --> 00:30:23,120
This is the granular signal layer.

787
00:30:23,120 --> 00:30:25,360
Each detection is typed by category

788
00:30:25,360 --> 00:30:28,400
and linked to the specific sign-in or user it affected.

789
00:30:28,400 --> 00:30:30,720
The operational value of having this through graph

790
00:30:30,720 --> 00:30:32,320
rather than the entraportal

791
00:30:32,320 --> 00:30:34,080
is that you can act on it programmatically.

792
00:30:34,080 --> 00:30:36,400
You can move at machine speed without a human in the loop

793
00:30:36,400 --> 00:30:37,280
for every event.

794
00:30:37,280 --> 00:30:39,280
But here's what an automated response workflow

795
00:30:39,280 --> 00:30:40,400
looks like in practice.

796
00:30:40,400 --> 00:30:41,600
A detection fires.

797
00:30:41,600 --> 00:30:43,600
A user's risk level jumps to high.

798
00:30:43,600 --> 00:30:45,600
Graph surfaces that event immediately.

799
00:30:45,600 --> 00:30:48,480
An Azure function picks it up either through a scheduled delta query

800
00:30:48,480 --> 00:30:50,320
or a change notification subscription.

801
00:30:50,320 --> 00:30:53,200
The function evaluates the risk level and the detection type.

802
00:30:53,200 --> 00:30:54,880
If the combination meets your threshold

803
00:30:54,880 --> 00:30:56,080
it fires a sequence.

804
00:30:56,080 --> 00:30:58,320
Password reset enforcement via graph.

805
00:30:58,320 --> 00:31:00,480
Session revocation where all existing tokens

806
00:31:00,480 --> 00:31:02,080
are invalidated immediately.

807
00:31:02,080 --> 00:31:04,880
Account is able if the risk profile meets your highest tier

808
00:31:04,880 --> 00:31:07,360
and a status right back to the security incident

809
00:31:07,360 --> 00:31:09,600
so your SOC team sees the automated response

810
00:31:09,600 --> 00:31:10,720
alongside the detection.

811
00:31:10,720 --> 00:31:12,480
That entire sequence runs in under a minute.

812
00:31:12,480 --> 00:31:14,000
It finishes before a human analyst

813
00:31:14,000 --> 00:31:15,920
has even finished reading the alert.

814
00:31:15,920 --> 00:31:18,560
Now layer in the broader API security context.

815
00:31:18,560 --> 00:31:21,120
According to a 2026 survey from Akamai,

816
00:31:21,120 --> 00:31:24,560
87% of organizations experience an API security incident

817
00:31:24,560 --> 00:31:25,760
in the past 12 months.

818
00:31:25,760 --> 00:31:29,200
The average cost per incident was above $700,000.

819
00:31:29,200 --> 00:31:31,360
Identity is the primary attack vector

820
00:31:31,360 --> 00:31:33,200
in the vast majority of those cases

821
00:31:33,200 --> 00:31:35,200
not because authentication systems are weak

822
00:31:35,200 --> 00:31:37,200
but because the permission surface surrounding

823
00:31:37,200 --> 00:31:39,760
authenticated identities is poorly governed

824
00:31:39,760 --> 00:31:41,200
which brings us to a hunting pattern

825
00:31:41,200 --> 00:31:43,440
that most organizations underutilize.

826
00:31:43,440 --> 00:31:46,480
Sign-in logs and audit logs are also thread hunting surfaces.

827
00:31:46,480 --> 00:31:49,120
Specifically for detecting abnormal graph API usage

828
00:31:49,120 --> 00:31:50,880
by applications and service principles

829
00:31:50,880 --> 00:31:52,000
rather than humans.

830
00:31:52,000 --> 00:31:54,080
High-volume mailbox reads from a service principle

831
00:31:54,080 --> 00:31:56,400
that doesn't normally touch mailbox data.

832
00:31:56,400 --> 00:31:59,280
Directory enumeration calls, like thousands of user lookups

833
00:31:59,280 --> 00:32:01,040
in a short window from an application

834
00:32:01,040 --> 00:32:03,280
that should only be reading a few attributes.

835
00:32:03,280 --> 00:32:06,000
Large file access sequences from a user account

836
00:32:06,000 --> 00:32:08,960
whose normal behavior is document editing not bulk download.

837
00:32:08,960 --> 00:32:11,520
These patterns don't show up in defender alerts by default.

838
00:32:11,520 --> 00:32:13,840
They show up when you're actively querying sign-in logs

839
00:32:13,840 --> 00:32:17,120
and graph API usage data with hunting logic applied.

840
00:32:17,120 --> 00:32:19,840
The service principle dimension is where most organizations

841
00:32:19,840 --> 00:32:21,120
are most exposed.

842
00:32:21,120 --> 00:32:22,640
Every app registration in your tenant

843
00:32:22,640 --> 00:32:24,240
that holds app-only graph permissions

844
00:32:24,240 --> 00:32:26,000
is a potential lateral movement channel.

845
00:32:26,000 --> 00:32:28,240
An attacker who gets a token for a service principle

846
00:32:28,240 --> 00:32:30,480
with mail.read tenant-wide access

847
00:32:30,480 --> 00:32:32,320
doesn't need to fish individual users.

848
00:32:32,320 --> 00:32:35,200
They already have access to every mailbox in your organization.

849
00:32:35,200 --> 00:32:37,120
You need to enumerate the applications

850
00:32:37,120 --> 00:32:40,160
and service principles in your tenant via graph.

851
00:32:40,160 --> 00:32:41,920
Cross-reference their permissions scopes

852
00:32:41,920 --> 00:32:43,920
against the principle of least privilege.

853
00:32:43,920 --> 00:32:45,520
Cross-reference their recent activity

854
00:32:45,520 --> 00:32:48,080
against security alerts for consent, grant, anomalies

855
00:32:48,080 --> 00:32:49,520
and token theft signals.

856
00:32:49,520 --> 00:32:51,520
The app with directory.readright.org

857
00:32:51,520 --> 00:32:53,200
all that hasn't been touched in 14 months

858
00:32:53,200 --> 00:32:56,400
but still has an active client secret is a risk register item.

859
00:32:56,400 --> 00:32:58,000
It is not a technical debt footnote.

860
00:32:58,000 --> 00:32:59,920
Every app only scope is a door.

861
00:32:59,920 --> 00:33:02,560
Your job is to know exactly how many doors exist,

862
00:33:02,560 --> 00:33:04,400
where they lead and who holds the keys.

863
00:33:04,400 --> 00:33:08,000
Identity risk is one dimension of security posture.

864
00:33:08,000 --> 00:33:10,720
The compliance APIs give you the regulatory dimension.

865
00:33:10,720 --> 00:33:12,240
Compliance APIs.

866
00:33:12,240 --> 00:33:14,320
Per view through the graph lens.

867
00:33:14,320 --> 00:33:16,480
Compliance used to live in a separate room.

868
00:33:16,480 --> 00:33:18,720
The legal team had their e-discovery platform.

869
00:33:18,720 --> 00:33:20,720
The compliance officer had their audit reports,

870
00:33:20,720 --> 00:33:22,560
IT had their security dashboards

871
00:33:22,560 --> 00:33:24,720
and those three rooms rarely talk to each other

872
00:33:24,720 --> 00:33:26,480
in a language anyone else understood.

873
00:33:26,480 --> 00:33:28,080
Graph doesn't just connect those rooms.

874
00:33:28,080 --> 00:33:29,840
It dissolves the walls between them.

875
00:33:29,840 --> 00:33:32,720
Five graph API services define the compliance picture

876
00:33:32,720 --> 00:33:34,240
through 2026.

877
00:33:34,240 --> 00:33:36,320
They're worth understanding as a connected system

878
00:33:36,320 --> 00:33:38,000
rather than individual endpoints.

879
00:33:38,000 --> 00:33:39,840
The first is security alerts V2.

880
00:33:39,840 --> 00:33:41,120
From a compliance angle,

881
00:33:41,120 --> 00:33:43,440
this surface becomes your incident evidence layer.

882
00:33:43,440 --> 00:33:46,880
When a regulatory framework requires end-to-end incident documentation,

883
00:33:46,880 --> 00:33:49,680
the alert schema in alerts V2 gives you everything you need.

884
00:33:49,680 --> 00:33:53,200
Category, severity, affected entities, detection source, and timeline.

885
00:33:53,200 --> 00:33:55,040
It's all in a machine readable format

886
00:33:55,040 --> 00:33:57,680
you can feed directly into a GRC system.

887
00:33:57,680 --> 00:33:59,840
No manual extraction from portal screenshots.

888
00:33:59,840 --> 00:34:02,000
No copy paste into a compliance spreadsheet.

889
00:34:02,000 --> 00:34:03,760
The evidence pipeline is automated.

890
00:34:03,760 --> 00:34:06,000
The second is audit and sign-in logs.

891
00:34:06,000 --> 00:34:07,200
For compliance purposes,

892
00:34:07,200 --> 00:34:09,680
these logs are the record of your control effectiveness.

893
00:34:09,680 --> 00:34:12,320
When an auditor asks you to prove that MFA was enforced

894
00:34:12,320 --> 00:34:14,560
for all administrative actions during Q3,

895
00:34:14,560 --> 00:34:16,000
the sign-in log is the answer.

896
00:34:16,000 --> 00:34:18,480
You filter by admin role, by application,

897
00:34:18,480 --> 00:34:20,880
by conditional access result, and by date range.

898
00:34:20,880 --> 00:34:22,240
The query is three lines.

899
00:34:22,240 --> 00:34:23,760
The evidence is definitive.

900
00:34:23,760 --> 00:34:25,840
That's a fundamentally different compliance posture

901
00:34:25,840 --> 00:34:28,480
than one built on manual reviews of sample events.

902
00:34:28,480 --> 00:34:30,720
The third is per-view e-discovery via graph.

903
00:34:30,720 --> 00:34:33,040
This one has a significant structural change

904
00:34:33,040 --> 00:34:35,920
that many organizations haven't fully absorbed yet.

905
00:34:35,920 --> 00:34:39,120
Classic e-discovery was retired in August 2025.

906
00:34:39,120 --> 00:34:41,520
Modern per-view e-discovery is API first,

907
00:34:41,520 --> 00:34:43,280
and here's the access shift that matters.

908
00:34:43,280 --> 00:34:45,440
E3 customers now have programmatic access

909
00:34:45,440 --> 00:34:47,680
to advanced e-discovery graph APIs

910
00:34:47,680 --> 00:34:49,440
that were previously reserved for e-5.

911
00:34:49,440 --> 00:34:51,920
That's a capability democratization.

912
00:34:51,920 --> 00:34:54,000
Organizations that assumed e-discovery automation

913
00:34:54,000 --> 00:34:56,640
was an e-5 luxury need to revisit that assumption.

914
00:34:56,640 --> 00:34:59,440
The pricing model that comes with modern e-discovery

915
00:34:59,440 --> 00:35:01,360
also changes how you think about managing it.

916
00:35:01,360 --> 00:35:03,920
There's a 50 gigabyte per month baseline allowance

917
00:35:03,920 --> 00:35:06,160
then $10 per gigabyte beyond that.

918
00:35:06,160 --> 00:35:09,600
Graph APIs let you forecast that cost before it arrives.

919
00:35:09,600 --> 00:35:10,960
You can query collection volumes

920
00:35:10,960 --> 00:35:13,280
and track case data sizes programmatically.

921
00:35:13,280 --> 00:35:16,400
You can set alerts when a case is approaching a cost threshold.

922
00:35:16,400 --> 00:35:18,960
Compliance cost management is now a graph use case.

923
00:35:18,960 --> 00:35:21,680
That is a sentence nobody would have written three years ago.

924
00:35:21,680 --> 00:35:24,080
The fourth surface is identity, MFA,

925
00:35:24,080 --> 00:35:26,560
and conditional access configuration APIs.

926
00:35:26,560 --> 00:35:28,720
The beta endpoint for authentication requirements

927
00:35:28,720 --> 00:35:31,920
lets you report on MFA state for any account in your tenant.

928
00:35:31,920 --> 00:35:33,120
You don't just sample it.

929
00:35:33,120 --> 00:35:34,480
You report on every single account

930
00:35:34,480 --> 00:35:36,720
which users have per user MFA enabled,

931
00:35:36,720 --> 00:35:39,520
which rely entirely on conditional access policies

932
00:35:39,520 --> 00:35:41,920
which have no MFA factor registered at all.

933
00:35:41,920 --> 00:35:44,640
That last group is the gap your auditors are looking for.

934
00:35:44,640 --> 00:35:46,560
Graph finds them automatically on a schedule

935
00:35:46,560 --> 00:35:48,080
before the auditor even asks.

936
00:35:48,080 --> 00:35:50,320
Conditional access policy export extends this.

937
00:35:50,320 --> 00:35:52,880
You can pull every CA policy definition through graph

938
00:35:52,880 --> 00:35:55,360
and map those definitions against CIS benchmarks.

939
00:35:55,360 --> 00:35:57,360
When a policy drifts from the approved baseline

940
00:35:57,360 --> 00:35:58,720
you detect it immediately.

941
00:35:58,720 --> 00:36:00,480
Not quarterly during a compliance review.

942
00:36:00,480 --> 00:36:01,920
The moment the policy changes

943
00:36:01,920 --> 00:36:04,560
because you're querying the configuration state on a schedule

944
00:36:04,560 --> 00:36:06,640
and comparing it to a documented baseline.

945
00:36:06,640 --> 00:36:09,040
The fifth surface covers the broader purview compliance

946
00:36:09,040 --> 00:36:10,720
and privacy API family.

947
00:36:10,720 --> 00:36:13,760
Retention labels, records management, data subject request handling

948
00:36:13,760 --> 00:36:15,200
and privacy operations.

949
00:36:15,200 --> 00:36:17,840
These APIs make lifecycle governance programmable.

950
00:36:17,840 --> 00:36:20,800
You can see which content locations are covered by retention policies.

951
00:36:20,800 --> 00:36:22,320
You can see which labels have been applied

952
00:36:22,320 --> 00:36:23,520
to which volumes of content.

953
00:36:23,520 --> 00:36:26,160
You can see how many data subject access requests are in flight

954
00:36:26,160 --> 00:36:27,600
and what stage they are at.

955
00:36:27,600 --> 00:36:29,520
Compliance posture stops being a narrative.

956
00:36:29,520 --> 00:36:31,520
Your compliance officer assembles manually.

957
00:36:31,520 --> 00:36:33,200
It becomes a structured data set.

958
00:36:33,200 --> 00:36:35,040
Your systems maintain continuously.

959
00:36:35,040 --> 00:36:38,320
The real power emerges when you stop treating these five surfaces

960
00:36:38,320 --> 00:36:40,080
as separate compliance tools.

961
00:36:40,080 --> 00:36:42,800
You have to start treating them as a unified risk signal.

962
00:36:42,800 --> 00:36:45,520
Security alerts combined with MFA coverage gaps.

963
00:36:45,520 --> 00:36:48,560
E-discovery activity combined with retention policy exceptions.

964
00:36:48,560 --> 00:36:50,480
That combination tells a compliance story

965
00:36:50,480 --> 00:36:52,720
no single surface can tell on its own.

966
00:36:52,720 --> 00:36:55,840
Graph is the integration layer that makes the combination possible.

967
00:36:55,840 --> 00:36:57,920
Compliance is about what you're required to do.

968
00:36:57,920 --> 00:36:59,920
Governance is about how you operationalize it.

969
00:36:59,920 --> 00:37:02,960
The governance playbook, policies, roles and taxonomy.

970
00:37:02,960 --> 00:37:04,560
Governance fails in a predictable way.

971
00:37:04,560 --> 00:37:06,480
It's not because organizations lack policies.

972
00:37:06,480 --> 00:37:07,680
They usually have plenty of those.

973
00:37:07,680 --> 00:37:09,840
It fails because the policies live in one place

974
00:37:09,840 --> 00:37:12,720
and the systems they're supposed to govern live somewhere else entirely.

975
00:37:12,720 --> 00:37:14,160
There's nothing connecting the two.

976
00:37:14,160 --> 00:37:17,760
Gardner research shows that roughly 80% of data governance projects fail.

977
00:37:17,760 --> 00:37:19,520
The frameworks weren't necessarily wrong.

978
00:37:19,520 --> 00:37:21,600
They just weren't aligned to business value.

979
00:37:21,600 --> 00:37:23,360
They lost executive sponsorship

980
00:37:23,360 --> 00:37:25,440
and they eventually became compliance theater.

981
00:37:25,440 --> 00:37:27,680
They were documents that satisfied an audit question

982
00:37:27,680 --> 00:37:29,600
without changing a single human behavior.

983
00:37:29,920 --> 00:37:31,760
That failure pattern isn't unique to data.

984
00:37:31,760 --> 00:37:35,040
It applies to teams M365 and identity governance too.

985
00:37:35,040 --> 00:37:36,640
The mechanism is always the same.

986
00:37:36,640 --> 00:37:37,920
Policy as an artifact.

987
00:37:37,920 --> 00:37:39,600
Enforcement as an aspiration.

988
00:37:39,600 --> 00:37:42,560
The shift that changes this is treating governance as engineering work,

989
00:37:42,560 --> 00:37:43,920
not documentation work.

990
00:37:43,920 --> 00:37:46,800
Success isn't measured by how thick your policy document is.

991
00:37:46,800 --> 00:37:50,400
It's measured by the coverage and reliability of your automated enforcement.

992
00:37:50,400 --> 00:37:54,080
Three pillars hold up a durable M365 governance architecture.

993
00:37:54,080 --> 00:37:57,040
Policies, the rules of engagement, roles, who owns what decision?

994
00:37:57,040 --> 00:38:01,040
Antaxonomy, the naming and classification structure that makes the whole system

995
00:38:01,040 --> 00:38:01,840
legible.

996
00:38:01,840 --> 00:38:03,680
Policies aren't just configuration settings.

997
00:38:03,680 --> 00:38:08,320
They're encoded decisions about what your organization allows, requires, and prohibits.

998
00:38:08,320 --> 00:38:10,880
Maybe external sharing is permitted for one class of content

999
00:38:10,880 --> 00:38:12,720
but strictly prohibited for another.

1000
00:38:12,720 --> 00:38:14,960
You might decide that anyone can create a team

1001
00:38:14,960 --> 00:38:19,280
but it must have two owners and a sensitivity label within 48 hours of creation.

1002
00:38:19,280 --> 00:38:22,800
These decisions need to live somewhere more durable than a SharePoint page.

1003
00:38:22,800 --> 00:38:23,840
Nobody reads.

1004
00:38:23,840 --> 00:38:28,160
They need to be more enforceable than an IT training session that only happens once a year.

1005
00:38:28,160 --> 00:38:29,840
Graph is how you make them durable.

1006
00:38:29,840 --> 00:38:32,400
You subscribe to group and team creation events.

1007
00:38:32,400 --> 00:38:37,280
The moment a new resource appears and as your function fires and reads the object properties,

1008
00:38:37,280 --> 00:38:40,080
it checks if the display name matches the naming convention.

1009
00:38:40,080 --> 00:38:42,320
It checks if a sensitivity label is assigned.

1010
00:38:42,320 --> 00:38:43,920
It checks for those two required owners.

1011
00:38:43,920 --> 00:38:46,720
If any check fails, the function acts immediately.

1012
00:38:46,720 --> 00:38:50,480
It patches the object, applies the missing label, or quarantines the resource

1013
00:38:50,480 --> 00:38:52,240
until an owner confirms the details.

1014
00:38:52,240 --> 00:38:53,920
The policy isn't a suggestion anymore.

1015
00:38:53,920 --> 00:38:55,600
It's executing in real time.

1016
00:38:55,600 --> 00:38:58,160
Every time a new workspace appears in your tenant.

1017
00:38:58,160 --> 00:39:00,320
Role's determined who makes the hard calls

1018
00:39:00,320 --> 00:39:03,040
and who has the authority to grant exceptions.

1019
00:39:03,040 --> 00:39:05,120
The failure mode here isn't usually at the top.

1020
00:39:05,120 --> 00:39:08,400
The C-so-owned security and the compliance officer owns the regulations.

1021
00:39:08,400 --> 00:39:10,480
The problem is role ambiguity in the middle.

1022
00:39:10,480 --> 00:39:13,360
Who owns a team's channel that crosses department lines?

1023
00:39:13,360 --> 00:39:17,200
Who approves a guest access extension for a vendor that started in one business unit

1024
00:39:17,200 --> 00:39:18,720
but expanded into three?

1025
00:39:18,720 --> 00:39:22,400
Graph-based governance requires clear ownership at the object level,

1026
00:39:22,400 --> 00:39:24,160
not just the organizational level.

1027
00:39:24,160 --> 00:39:26,640
The automation needs to know exactly who to notify

1028
00:39:26,640 --> 00:39:28,560
and who has the power to hit approve.

1029
00:39:28,560 --> 00:39:32,720
Taxonomy is the layer most teams underinvest in and most regret later.

1030
00:39:32,720 --> 00:39:35,680
Naming conventions break the moment in new business unit forms.

1031
00:39:35,680 --> 00:39:37,600
Sensitivity labels become so granular

1032
00:39:37,600 --> 00:39:40,320
that users just pick the wrong one or skip it entirely.

1033
00:39:40,320 --> 00:39:43,120
Fewer, clearer labels applied consistently are more valuable

1034
00:39:43,120 --> 00:39:45,600
than a massive hierarchy applied inconsistently.

1035
00:39:45,600 --> 00:39:50,400
Microsoft's own internal guidance caps parent sensitivity labels at around five.

1036
00:39:50,400 --> 00:39:51,920
They keep the sublabeles to a minimum

1037
00:39:51,920 --> 00:39:54,560
because they know that complexity kills adoption.

1038
00:39:54,560 --> 00:39:56,560
Two practical elements round out the picture.

1039
00:39:56,560 --> 00:40:00,560
The tenant governance resource in the Graph Beta API is an early signal worth watching.

1040
00:40:00,560 --> 00:40:03,760
It represents a consolidated programmatic view of tenant services.

1041
00:40:03,760 --> 00:40:07,200
It's the beginning of a genuine governance control plane exposed through Graph.

1042
00:40:07,200 --> 00:40:09,920
It's still in Beta, so you should design for resilience

1043
00:40:09,920 --> 00:40:11,280
but the direction is clear.

1044
00:40:11,280 --> 00:40:12,800
Then there's the hybrid reality.

1045
00:40:12,800 --> 00:40:15,600
Not everything you need to govern is exposed through Graph today.

1046
00:40:15,600 --> 00:40:18,320
SharePoint has a dedicated admin settings endpoint

1047
00:40:18,320 --> 00:40:21,200
and many tenant level options still require PowerShell.

1048
00:40:21,200 --> 00:40:23,840
A mature strategy uses Graph where it reaches,

1049
00:40:23,840 --> 00:40:25,200
PowerShell where it doesn't,

1050
00:40:25,200 --> 00:40:27,760
and Perview for the compliance layer underneath both.

1051
00:40:27,760 --> 00:40:29,200
That design isn't a compromise.

1052
00:40:29,200 --> 00:40:31,440
It's the architecture that actually works right now.

1053
00:40:31,440 --> 00:40:35,200
Graph data connect when scale changes the model.

1054
00:40:35,200 --> 00:40:38,400
There's a point where the interactive Graph API stops being the right tool.

1055
00:40:38,400 --> 00:40:40,080
It's not because Graph stops working.

1056
00:40:40,080 --> 00:40:42,720
It's because the question you're asking has changed.

1057
00:40:42,720 --> 00:40:45,840
The standard request response pattern wasn't designed for massive scale.

1058
00:40:45,840 --> 00:40:50,080
When you need to analyze collaboration patterns across 50,000 users over 18 months,

1059
00:40:50,080 --> 00:40:52,320
you don't use paginated API calls.

1060
00:40:52,320 --> 00:40:55,840
If you're trying to identify burn out risk by correlating meeting behavior

1061
00:40:55,840 --> 00:40:58,160
and after hours work across the whole company,

1062
00:40:58,160 --> 00:41:00,080
you aren't doing that in an Azure function.

1063
00:41:00,080 --> 00:41:03,440
That kind of dataset would take weeks to assemble through standard calls

1064
00:41:03,440 --> 00:41:06,560
and you'd hit throttling limits long before you finished.

1065
00:41:06,560 --> 00:41:08,400
You need a different architectural primitive.

1066
00:41:08,400 --> 00:41:10,080
That primitive is Graph Data Connect.

1067
00:41:10,080 --> 00:41:11,520
It isn't an API endpoint.

1068
00:41:11,520 --> 00:41:13,440
It's a govern bulk export mechanism.

1069
00:41:13,440 --> 00:41:16,320
Instead of your application calling Graph and waiting for data,

1070
00:41:16,320 --> 00:41:18,000
Graph Data Connect pipelines.

1071
00:41:18,000 --> 00:41:23,520
M365 datasets into an Azure destination like a storage account or Microsoft Fabric.

1072
00:41:23,520 --> 00:41:27,680
It comes with fine grained consent controls and encryption at every step.

1073
00:41:27,680 --> 00:41:30,880
An administrator has to approve the export before any data moves.

1074
00:41:30,880 --> 00:41:33,520
The scope is explicit, the destination is controlled,

1075
00:41:33,520 --> 00:41:35,440
and the entire lineage is documented.

1076
00:41:35,440 --> 00:41:38,480
This architecture matters because the data involved is sensitive.

1077
00:41:38,480 --> 00:41:41,360
Communication patterns and working hours are organizational signals

1078
00:41:41,360 --> 00:41:43,040
with real privacy implications.

1079
00:41:43,040 --> 00:41:46,000
Graph Data Connect addresses this with built-in privacy controls.

1080
00:41:46,000 --> 00:41:47,840
You can opt for Skate User Identities,

1081
00:41:47,840 --> 00:41:50,480
so the analytics layer sees organizational intelligence

1082
00:41:50,480 --> 00:41:52,560
without exposing individual behavior.

1083
00:41:52,560 --> 00:41:54,320
You get the pattern without the surveillance.

1084
00:41:54,320 --> 00:41:57,600
That's a massive distinction for organizations operating under GDPR

1085
00:41:57,600 --> 00:42:01,040
or dealing with workscounsels where employee monitoring would create legal friction.

1086
00:42:01,040 --> 00:42:04,720
The HCL NIPON implementation is the clearest example of this at scale.

1087
00:42:04,720 --> 00:42:08,240
They used Graph Data Connect to ingest exchange and teams data

1088
00:42:08,240 --> 00:42:13,360
into Azure Synapse to correlate meeting loads and collaboration density with burnout indicators.

1089
00:42:13,360 --> 00:42:15,040
This wasn't a theoretical model.

1090
00:42:15,040 --> 00:42:18,240
It was a running system producing actionable intelligence.

1091
00:42:18,240 --> 00:42:20,640
The insights showed which teams were isolated

1092
00:42:20,640 --> 00:42:22,640
and where collaboration networks were thin,

1093
00:42:22,640 --> 00:42:26,320
which led to concrete changes in how they managed meetings and team structures.

1094
00:42:26,320 --> 00:42:29,600
That class of insight doesn't come from a basic report in the admin center.

1095
00:42:29,600 --> 00:42:33,680
It comes from treating organizational behavior as a first class analytics asset.

1096
00:42:33,680 --> 00:42:37,280
Microsoft also offers a hybrid workplace analytics template

1097
00:42:37,280 --> 00:42:39,280
built specifically on this technology.

1098
00:42:39,280 --> 00:42:42,960
It asks how often employees are in the office versus remote.

1099
00:42:42,960 --> 00:42:46,960
It looks at whether meeting participation is equitable for distributed team members.

1100
00:42:46,960 --> 00:42:51,040
It even flags churn risk based on how often managers interact with their teams.

1101
00:42:51,040 --> 00:42:52,800
The template is just a starting point,

1102
00:42:52,800 --> 00:42:56,400
but it shows the kind of questions you can answer when you move to govern bulk analytics.

1103
00:42:56,400 --> 00:42:59,760
The AI readiness angle is what's accelerating investment here right now.

1104
00:42:59,760 --> 00:43:04,400
Microsoft Fabric Plus Graph Data Connect is the path to AI ready organizational data sets.

1105
00:43:04,400 --> 00:43:09,200
When organizations ask why their co-pilot deployment isn't delivering the ROI they expected,

1106
00:43:09,200 --> 00:43:10,880
the answer is often found here.

1107
00:43:10,880 --> 00:43:14,640
The underlying data isn't consolidated or structured enough to support the reasoning,

1108
00:43:14,640 --> 00:43:16,000
co-pilot depends on.

1109
00:43:16,000 --> 00:43:18,080
Graph Data Connect is how you fix that at scale.

1110
00:43:18,080 --> 00:43:21,920
The distinction between interactive graph and data connect isn't about which one is better.

1111
00:43:21,920 --> 00:43:23,440
It's about the question you're asking.

1112
00:43:23,440 --> 00:43:26,880
Use interactive graph for real-time control and operational automation.

1113
00:43:26,880 --> 00:43:29,680
Use Data Connect for organizational intelligence at a scale

1114
00:43:29,680 --> 00:43:32,400
where individual API calls simply can't keep up.

1115
00:43:32,400 --> 00:43:34,080
Data Connect gives you scale,

1116
00:43:34,080 --> 00:43:35,840
graph connectors give you breadth,

1117
00:43:35,840 --> 00:43:38,320
graph connectors bringing the outside in.

1118
00:43:38,320 --> 00:43:41,600
Your organization's knowledge doesn't live entirely in Microsoft 365.

1119
00:43:41,600 --> 00:43:42,400
It never did.

1120
00:43:42,400 --> 00:43:44,560
The service now instance your IT team runs.

1121
00:43:44,560 --> 00:43:47,040
The Salesforce environment where your sales or glives,

1122
00:43:47,040 --> 00:43:50,320
the confluence wiki your engineering team has maintained for six years.

1123
00:43:50,320 --> 00:43:52,400
The legacy file share that has been migrated,

1124
00:43:52,400 --> 00:43:54,080
approximately never.

1125
00:43:54,080 --> 00:43:57,600
All of that content exists outside the Microsoft Graph Index

1126
00:43:57,600 --> 00:44:00,160
and that's where it breaks because if it's not in the index,

1127
00:44:00,160 --> 00:44:01,360
co-pilot can't see it.

1128
00:44:01,360 --> 00:44:02,800
Microsoft Search can't surface it.

1129
00:44:02,800 --> 00:44:05,680
The organizational intelligence layer we've been building throughout this episode

1130
00:44:05,680 --> 00:44:07,120
has a massive blind spot.

1131
00:44:07,120 --> 00:44:09,520
Graph connectors are how you close those gaps.

1132
00:44:09,520 --> 00:44:12,160
The architecture relies on three structural components.

1133
00:44:12,160 --> 00:44:13,440
First you have a connection,

1134
00:44:13,440 --> 00:44:17,200
which is the authenticated link between Microsoft Graph and your source system.

1135
00:44:17,200 --> 00:44:20,320
Then you define a schema to tell the system what item types exist,

1136
00:44:20,320 --> 00:44:21,680
what properties they carry,

1137
00:44:21,680 --> 00:44:23,440
and how they should be indexed.

1138
00:44:23,440 --> 00:44:25,440
Finally, you have the items themselves.

1139
00:44:25,440 --> 00:44:30,080
The actual records, documents, or tickets synchronized from the external system

1140
00:44:30,080 --> 00:44:31,760
into the Microsoft Graph Index.

1141
00:44:31,760 --> 00:44:33,440
Once those three pieces are in place,

1142
00:44:33,440 --> 00:44:37,360
external content becomes a first-class citizen alongside native M365 data.

1143
00:44:37,360 --> 00:44:39,760
The retrieval infrastructure treats everything the same.

1144
00:44:39,760 --> 00:44:41,120
Microsoft Search finds it.

1145
00:44:41,120 --> 00:44:42,400
Co-pilot grounds against it.

1146
00:44:42,400 --> 00:44:44,320
The semantic index ranks a salesforce record

1147
00:44:44,320 --> 00:44:47,360
right alongside a SharePoint document or a team's message.

1148
00:44:47,360 --> 00:44:49,520
From the user's perspective, the boundary is gone.

1149
00:44:49,520 --> 00:44:50,720
The seam is invisible,

1150
00:44:50,720 --> 00:44:52,640
the governance controls are identical,

1151
00:44:52,640 --> 00:44:54,960
and the permissions model carries through perfectly.

1152
00:44:54,960 --> 00:44:58,800
Users only see connector content they are authorized to see in the original source system

1153
00:44:58,800 --> 00:45:02,240
because the access control list in the schema maps back to those source permissions.

1154
00:45:02,240 --> 00:45:04,480
Microsoft is expanding this catalog aggressively.

1155
00:45:04,480 --> 00:45:10,000
In 2026, they brought more than 35 new connectors to general availability in a single wave.

1156
00:45:10,000 --> 00:45:11,920
This included project management systems,

1157
00:45:11,920 --> 00:45:14,800
content platforms, and vertical line of business applications.

1158
00:45:14,800 --> 00:45:17,360
The pace tells you exactly where Microsoft is going.

1159
00:45:17,360 --> 00:45:20,160
External content indexing isn't a niche scenario anymore.

1160
00:45:20,160 --> 00:45:22,880
It is a core expectation of what Co-pilot can reach.

1161
00:45:22,880 --> 00:45:26,880
But to make this work, you have to understand how Co-pilot actually uses that content.

1162
00:45:26,880 --> 00:45:28,400
When a user submits a prompt,

1163
00:45:28,400 --> 00:45:30,400
Co-pilot pulls context from graph,

1164
00:45:30,400 --> 00:45:33,280
recent emails, calendars, and team's conversations.

1165
00:45:33,280 --> 00:45:35,200
It then queries the semantic index,

1166
00:45:35,200 --> 00:45:36,640
including all your connector data,

1167
00:45:36,640 --> 00:45:39,040
to find relevant items to pass to the LLM.

1168
00:45:39,040 --> 00:45:40,560
After the response is generated,

1169
00:45:40,560 --> 00:45:45,280
Graph applies security trimming to confirm the user has permission to see every item used in the grounding

1170
00:45:45,280 --> 00:45:47,040
before the answer is returned.

1171
00:45:47,040 --> 00:45:49,040
This makes your schema design critical.

1172
00:45:49,040 --> 00:45:51,200
Any field you want Co-pilot to reason over

1173
00:45:51,200 --> 00:45:53,680
must be explicitly marked as searchable in your schema.

1174
00:45:54,320 --> 00:45:59,200
Titles, body content, and key metadata fields need to be defined correctly at the moment of registration.

1175
00:45:59,200 --> 00:46:01,200
If you realize later that you missed a field,

1176
00:46:01,200 --> 00:46:02,560
you can't just flip a switch.

1177
00:46:02,560 --> 00:46:04,960
You have to re-index the entire data set.

1178
00:46:04,960 --> 00:46:07,040
The schema isn't just a technical spec.

1179
00:46:07,040 --> 00:46:09,920
It's an information architecture decision that determines

1180
00:46:09,920 --> 00:46:11,680
what knowledge is actually reachable.

1181
00:46:11,680 --> 00:46:12,720
But here's the problem.

1182
00:46:12,720 --> 00:46:15,680
A poorly configured connector is a major governance risk.

1183
00:46:15,680 --> 00:46:18,400
If you ingest content without accurate permission mapping,

1184
00:46:18,400 --> 00:46:22,800
uses my surface data through Co-pilot that they couldn't access in the source system.

1185
00:46:22,800 --> 00:46:24,240
That isn't a theoretical worry.

1186
00:46:24,240 --> 00:46:26,240
It's an unintended disclosure waiting to happen.

1187
00:46:26,240 --> 00:46:28,960
Connector governance, who can create them,

1188
00:46:28,960 --> 00:46:31,760
which sources are approved and how permissions are validated,

1189
00:46:31,760 --> 00:46:34,400
must sit inside your broader Co-pilot framework.

1190
00:46:34,400 --> 00:46:37,840
It cannot be an afterthought you tried to fix once the data is already in production.

1191
00:46:37,840 --> 00:46:39,120
The architecture we've discussed,

1192
00:46:39,120 --> 00:46:41,920
the reporting, the audit logs, and the identity security,

1193
00:46:41,920 --> 00:46:44,560
all assumes that Graph is working with the right data.

1194
00:46:44,560 --> 00:46:48,560
Connectors determine whether that assumption holds for everything outside Microsoft 365.

1195
00:46:48,560 --> 00:46:49,520
They bring the data in.

1196
00:46:49,520 --> 00:46:51,840
The Co-pilot APIs tell you what happens once it's there.

1197
00:46:52,400 --> 00:46:54,400
Graph is the Co-pilot control plane.

1198
00:46:54,400 --> 00:46:58,720
15 million paid Co-pilot seats were active globally by early 2026.

1199
00:46:58,720 --> 00:47:00,000
That sounds like a success story.

1200
00:47:00,000 --> 00:47:03,760
But in reality, the active usage rate was only about 35%,

1201
00:47:03,760 --> 00:47:06,640
two thirds of the people with a license weren't using it regularly.

1202
00:47:06,640 --> 00:47:09,200
The problem wasn't the model, it wasn't a lack of features.

1203
00:47:09,200 --> 00:47:10,720
It was the infrastructure.

1204
00:47:10,720 --> 00:47:14,800
The dependency chain here is worth stating plainly because it gets lost in the rollout hype.

1205
00:47:14,800 --> 00:47:17,760
Co-pilot is not just an AI model sitting on top of your data.

1206
00:47:17,760 --> 00:47:21,440
It is a system where the LLM is one part and Microsoft Graph is the other.

1207
00:47:21,440 --> 00:47:22,800
And they are equally important.

1208
00:47:22,800 --> 00:47:26,160
Every useful response requires Graph to find context,

1209
00:47:26,160 --> 00:47:28,640
enforce permissions, and apply security trimming.

1210
00:47:28,640 --> 00:47:31,840
If your Graph data is thin, disorganized, or poorly permissioned,

1211
00:47:31,840 --> 00:47:33,840
Co-pilot's outputs will be useless.

1212
00:47:33,840 --> 00:47:34,800
The model didn't fail.

1213
00:47:34,800 --> 00:47:37,440
The retrieval layer just had nothing meaningful to work with.

1214
00:47:37,440 --> 00:47:38,400
The reality is simple.

1215
00:47:38,400 --> 00:47:40,960
Co-pilot accelerates whatever state your data is in.

1216
00:47:40,960 --> 00:47:44,640
Organizations with clean SharePoint libraries and rational permission models

1217
00:47:44,640 --> 00:47:46,960
see responses that are specific and trustworthy.

1218
00:47:46,960 --> 00:47:51,120
But in organizations where content is scattered across legacy shares and teams sprawl

1219
00:47:51,120 --> 00:47:53,360
has created hundreds of dead channels.

1220
00:47:53,360 --> 00:47:55,440
The results are generic or incomplete.

1221
00:47:55,440 --> 00:47:56,640
The AI isn't the variable.

1222
00:47:56,640 --> 00:47:58,000
The graph maturity is.

1223
00:47:58,000 --> 00:48:00,560
There is also a timing detail that many admins miss.

1224
00:48:00,560 --> 00:48:02,400
When you activate a new Co-pilot license,

1225
00:48:02,400 --> 00:48:05,040
the semantic index takes one to two days to build.

1226
00:48:05,040 --> 00:48:06,640
During that window, Co-pilot works,

1227
00:48:06,640 --> 00:48:08,640
but it's looking at an incomplete picture.

1228
00:48:08,640 --> 00:48:11,440
Users who try Co-pilot in those first 48 hours

1229
00:48:11,440 --> 00:48:13,840
often walk away with a negative impression.

1230
00:48:13,840 --> 00:48:16,640
They are judging the tool against an unindexed dataset.

1231
00:48:16,640 --> 00:48:19,520
Admins, who explain this window upfront,

1232
00:48:19,520 --> 00:48:24,320
report much smoother adoption because they managed the expectation before the first prompt was even typed.

1233
00:48:24,320 --> 00:48:25,760
That isn't a technical detail.

1234
00:48:25,760 --> 00:48:26,800
It's change management.

1235
00:48:26,800 --> 00:48:32,960
To help manage this, two new graph API surfaces became available in early 2026.

1236
00:48:32,960 --> 00:48:35,600
The first is a programmatic inventory of every Co-pilot agent

1237
00:48:35,600 --> 00:48:37,120
and application running in your tenant.

1238
00:48:37,120 --> 00:48:39,280
It covers Microsoft agents, third-party apps,

1239
00:48:39,280 --> 00:48:41,920
and custom tools built in Co-pilot studio.

1240
00:48:41,920 --> 00:48:43,360
Before this API existed,

1241
00:48:43,360 --> 00:48:46,560
you had to hunt through the admin portal manually to see what was active.

1242
00:48:46,560 --> 00:48:50,240
Now the process is scriptable and fits right into your existing governance tooling.

1243
00:48:50,240 --> 00:48:52,560
The second is the Co-pilot usage report API.

1244
00:48:52,560 --> 00:48:56,000
This gives you per user and aggregate data directly through graph.

1245
00:48:56,000 --> 00:48:57,920
You can see which departments are active,

1246
00:48:57,920 --> 00:49:00,160
which users haven't submitted a single prompt,

1247
00:49:00,160 --> 00:49:03,840
and which specific apps like Word or Teams are seeing the most volume.

1248
00:49:03,840 --> 00:49:07,680
When you combine this with the collaboration signals from the reporting APIs,

1249
00:49:07,680 --> 00:49:10,560
you can build an ROI model based on actual behavior.

1250
00:49:10,560 --> 00:49:12,800
You don't have to rely on vendor case studies anymore.

1251
00:49:12,800 --> 00:49:15,680
The readiness checklist for Co-pilot isn't actually technical.

1252
00:49:15,680 --> 00:49:16,640
It's strategic.

1253
00:49:16,640 --> 00:49:19,280
You need content consolidated in SharePoint and OneDrive.

1254
00:49:19,280 --> 00:49:21,120
You need collaboration standardised in Teams.

1255
00:49:21,120 --> 00:49:23,280
You need permissions cleaned up through access reviews

1256
00:49:23,280 --> 00:49:25,680
and sensitivity labels applied consistently.

1257
00:49:25,680 --> 00:49:28,400
Every item on that list is a graph maturity decision

1258
00:49:28,400 --> 00:49:31,760
and every one of them has a direct consequence on your ROI.

1259
00:49:31,760 --> 00:49:33,360
Co-pilot is the most visible use case,

1260
00:49:33,360 --> 00:49:35,520
but some of the most powerful graph capabilities

1261
00:49:35,520 --> 00:49:37,840
are the ones nobody is talking about.

1262
00:49:37,840 --> 00:49:40,400
Hidden gems, the planner and tasks APIs.

1263
00:49:40,400 --> 00:49:41,600
Planner gets dismissed.

1264
00:49:41,600 --> 00:49:45,040
In most M365 conversations, it shows up as a visual task board.

1265
00:49:45,040 --> 00:49:46,960
The lightweight alternative to project for Teams

1266
00:49:46,960 --> 00:49:49,520
that don't need gantt charts, that framing isn't wrong.

1267
00:49:49,520 --> 00:49:51,280
It's just radically incomplete.

1268
00:49:51,280 --> 00:49:53,280
Through graph, planner isn't a task board.

1269
00:49:53,280 --> 00:49:54,880
It's a queryable work management layer

1270
00:49:54,880 --> 00:49:56,800
that spans your entire organization.

1271
00:49:56,800 --> 00:49:58,960
Every task, every bucket, every plan,

1272
00:49:58,960 --> 00:50:00,640
across every team and every department.

1273
00:50:00,640 --> 00:50:03,440
All of it is accessible through a single API surface.

1274
00:50:03,440 --> 00:50:06,720
The filters let you cut the data anyway the business question requires.

1275
00:50:06,720 --> 00:50:08,640
Think about what that actually means.

1276
00:50:08,640 --> 00:50:11,840
Right now your organization is running hundreds of active planner boards.

1277
00:50:11,840 --> 00:50:14,480
Project delivery teams, marketing campaign trackers,

1278
00:50:14,480 --> 00:50:17,760
IT change management logs, onboarding checklists.

1279
00:50:17,760 --> 00:50:20,720
Each one is an isolated island of work visibility.

1280
00:50:20,720 --> 00:50:22,800
A manager can see their Teams board,

1281
00:50:22,800 --> 00:50:24,720
and a department head can see the boards,

1282
00:50:24,720 --> 00:50:26,320
their Teams share with them.

1283
00:50:26,320 --> 00:50:27,840
But nobody has an organizational view.

1284
00:50:27,840 --> 00:50:30,080
Nobody can answer how many tasks are overdue

1285
00:50:30,080 --> 00:50:31,920
across all active projects,

1286
00:50:31,920 --> 00:50:33,920
or what percentage are unassigned,

1287
00:50:33,920 --> 00:50:36,160
or where the completion velocity is slowing down.

1288
00:50:36,160 --> 00:50:37,760
That question isn't unanswerable.

1289
00:50:37,760 --> 00:50:39,920
It's just that nobody built the query.

1290
00:50:39,920 --> 00:50:43,200
When you use the right filters on a get request for planner tasks,

1291
00:50:43,200 --> 00:50:44,800
you finally get that view.

1292
00:50:44,800 --> 00:50:47,520
You can see completion status across every plan

1293
00:50:47,520 --> 00:50:50,320
and due date distribution against the current date.

1294
00:50:50,320 --> 00:50:52,160
Assignment coverage is another big one.

1295
00:50:52,160 --> 00:50:54,720
Finding tasks in active plans with no assigned E

1296
00:50:54,720 --> 00:50:57,840
is one of the clearest early warning signals for a project breakdown.

1297
00:50:57,840 --> 00:50:59,920
If you aggregate those signals across departments,

1298
00:50:59,920 --> 00:51:01,760
you have a lightweight PMO dashboard.

1299
00:51:01,760 --> 00:51:03,360
It requires no additional tooling

1300
00:51:03,360 --> 00:51:05,200
and no manual report assembly.

1301
00:51:05,200 --> 00:51:06,960
The system is built entirely on data

1302
00:51:06,960 --> 00:51:09,920
that already exists from work your teams are already tracking.

1303
00:51:09,920 --> 00:51:12,880
The to-do integration extends this downward into individual work.

1304
00:51:13,280 --> 00:51:15,520
Personal tasks are the items people capture in.

1305
00:51:15,520 --> 00:51:18,320
To do that don't belong to a shared plan,

1306
00:51:18,320 --> 00:51:20,320
these are accessible through the same graph surface.

1307
00:51:20,320 --> 00:51:22,880
Bridging personal task management

1308
00:51:22,880 --> 00:51:24,560
with team-level planner visibility

1309
00:51:24,560 --> 00:51:27,440
is a capability most organizations haven't explored.

1310
00:51:27,440 --> 00:51:30,960
It matters because it shows if individual work aligns with team priorities.

1311
00:51:30,960 --> 00:51:32,720
Or if people are spending their days on tasks

1312
00:51:32,720 --> 00:51:35,440
that are completely disconnected from any shared plan.

1313
00:51:35,440 --> 00:51:38,560
The automation pattern here is one of the cleaner ones to build.

1314
00:51:38,560 --> 00:51:41,200
When a message in a team's channel gets flagged by a user

1315
00:51:41,200 --> 00:51:42,720
or a keyword detection workflow,

1316
00:51:42,720 --> 00:51:44,720
graph can automatically create a planner task.

1317
00:51:44,720 --> 00:51:46,160
It assigns it to the relevant owner

1318
00:51:46,160 --> 00:51:47,520
and attaches it to the right plan.

1319
00:51:47,520 --> 00:51:50,560
The message context is captured in the task description.

1320
00:51:50,560 --> 00:51:51,680
There is no manual handoff.

1321
00:51:51,680 --> 00:51:54,000
There is no can someone create a task for this,

1322
00:51:54,000 --> 00:51:56,160
follow-up that gets forgotten by the next thread.

1323
00:51:56,160 --> 00:51:58,640
The action item is captured at the moment it's identified

1324
00:51:58,640 --> 00:52:00,640
in the place where work actually gets tracked.

1325
00:52:00,640 --> 00:52:02,960
And it doesn't require power-automate license to build.

1326
00:52:02,960 --> 00:52:04,320
A straightforward graph call

1327
00:52:04,320 --> 00:52:06,480
from an Azure function handles it directly.

1328
00:52:06,480 --> 00:52:08,960
The executive signal worth surfacing from all of this

1329
00:52:08,960 --> 00:52:11,680
is that task velocity and completion rates are a proxy

1330
00:52:11,680 --> 00:52:13,680
for organizational execution capacity.

1331
00:52:13,680 --> 00:52:14,880
It's not a perfect proxy.

1332
00:52:14,880 --> 00:52:16,560
But when completion rates are declining

1333
00:52:16,560 --> 00:52:18,400
across multiple plans simultaneously,

1334
00:52:18,400 --> 00:52:20,080
the pattern is telling you something.

1335
00:52:20,080 --> 00:52:22,400
When unassigned task counts are growing faster

1336
00:52:22,400 --> 00:52:24,240
than new tasks are being completed,

1337
00:52:24,240 --> 00:52:26,400
you are seeing execution health issues.

1338
00:52:26,400 --> 00:52:28,000
No financial report will show you that

1339
00:52:28,000 --> 00:52:29,920
until the consequence has already arrived.

1340
00:52:29,920 --> 00:52:31,680
Tasks tell you what's being worked on.

1341
00:52:31,680 --> 00:52:33,680
The search APIs tell you what people can't find.

1342
00:52:33,680 --> 00:52:36,880
Hidden gems, the search and places APIs.

1343
00:52:36,880 --> 00:52:39,760
Most organizations think of Microsoft Search as a search box.

1344
00:52:39,760 --> 00:52:41,360
Type something, get results.

1345
00:52:41,360 --> 00:52:43,200
Maybe it surfaces SharePoint documents.

1346
00:52:43,200 --> 00:52:44,960
Maybe it finds a person in the directory.

1347
00:52:44,960 --> 00:52:47,280
It's useful enough, but it's unremarkable.

1348
00:52:47,280 --> 00:52:49,600
Through graph, Microsoft Search becomes something different.

1349
00:52:49,600 --> 00:52:51,520
It becomes a programmable query engine

1350
00:52:51,520 --> 00:52:54,560
across the entirety of your organizational knowledge.

1351
00:52:54,560 --> 00:52:58,480
SharePoint, OneDrive, Teams messages, people profiles.

1352
00:52:58,480 --> 00:53:00,960
Every item indexed through the connectors we just covered

1353
00:53:00,960 --> 00:53:02,880
is reachable through a single API call.

1354
00:53:02,880 --> 00:53:05,840
The filters, entity types, and result ranking are all built in.

1355
00:53:05,840 --> 00:53:08,960
The enterprise search governance use case is the one worth building first.

1356
00:53:08,960 --> 00:53:12,160
It reveals something most organizations genuinely don't know about themselves.

1357
00:53:12,160 --> 00:53:15,200
When you query the search API for what people are searching and not finding,

1358
00:53:15,200 --> 00:53:16,880
you're looking directly at knowledge gaps.

1359
00:53:16,880 --> 00:53:19,280
You can see zero result queries and repeated searches

1360
00:53:19,280 --> 00:53:21,280
for the same terms across a short window.

1361
00:53:21,280 --> 00:53:23,360
Someone searched for the vendor contract template

1362
00:53:23,360 --> 00:53:25,360
four times this week and found nothing.

1363
00:53:25,360 --> 00:53:27,200
Someone searched for the Q3 compliance policy

1364
00:53:27,200 --> 00:53:29,280
and got results from three years ago.

1365
00:53:29,280 --> 00:53:31,040
Someone searched for the onboarding checklist

1366
00:53:31,040 --> 00:53:34,320
for a specific country and got items from a completely different region.

1367
00:53:34,320 --> 00:53:35,760
Those aren't search failures.

1368
00:53:35,760 --> 00:53:37,360
Their content architecture signals.

1369
00:53:37,360 --> 00:53:40,320
The knowledge your people need exists somewhere.

1370
00:53:40,320 --> 00:53:42,240
It's probably in someone's personal drive

1371
00:53:42,240 --> 00:53:44,640
or a Teams channel nobody else has access to

1372
00:53:44,640 --> 00:53:47,360
or a legacy SharePoint site with permission so narrow

1373
00:53:47,360 --> 00:53:49,520
that the document is effectively invisible.

1374
00:53:49,520 --> 00:53:53,280
Search Gap Analysis via Graph tells you where to focus information management effort.

1375
00:53:53,280 --> 00:53:54,560
It's not based on intuition.

1376
00:53:54,560 --> 00:53:57,840
It's based on what people are actually trying to find and failing to.

1377
00:53:57,840 --> 00:53:59,840
The people search dimension adds a layer

1378
00:53:59,840 --> 00:54:03,280
that's underused even in mature Microsoft search deployments.

1379
00:54:03,280 --> 00:54:05,680
Using a search query with the person entity type

1380
00:54:05,680 --> 00:54:08,240
lets you find expertise across the organization.

1381
00:54:08,240 --> 00:54:10,720
This isn't just about the org chart hierarchy.

1382
00:54:10,720 --> 00:54:13,040
It's about people who have worked on specific projects

1383
00:54:13,040 --> 00:54:15,280
or published content on specific topics.

1384
00:54:15,280 --> 00:54:17,280
It includes signals and viva that associate them

1385
00:54:17,280 --> 00:54:18,800
with particular skill domains.

1386
00:54:18,800 --> 00:54:20,640
That's expertise location at scale.

1387
00:54:20,640 --> 00:54:22,480
Finding out who in the organization has worked

1388
00:54:22,480 --> 00:54:24,880
on data residency compliance for financial services

1389
00:54:24,880 --> 00:54:26,880
currently requires asking three people

1390
00:54:26,880 --> 00:54:28,080
and waiting two days.

1391
00:54:28,080 --> 00:54:29,520
Through Graph it's a query.

1392
00:54:29,520 --> 00:54:30,960
Now the places API.

1393
00:54:30,960 --> 00:54:33,920
This is the surface that generates the most genuine surprise

1394
00:54:33,920 --> 00:54:36,880
when I describe it to people who work in M365 every day.

1395
00:54:36,880 --> 00:54:38,320
Almost nobody knows it exists.

1396
00:54:38,320 --> 00:54:41,760
The places API exposes the physical infrastructure of your organization

1397
00:54:41,760 --> 00:54:43,120
as queryable data.

1398
00:54:43,120 --> 00:54:43,920
Rooms.

1399
00:54:43,920 --> 00:54:47,360
With capacity, equipment, location and building association,

1400
00:54:47,360 --> 00:54:50,080
work spaces, desk clusters, collaboration zones

1401
00:54:50,080 --> 00:54:52,160
and focus areas, floors, buildings.

1402
00:54:52,160 --> 00:54:56,400
The entire physical layer of where work happens

1403
00:54:56,400 --> 00:54:58,720
is represented as structured data.

1404
00:54:58,720 --> 00:55:00,960
It's accessible through the same authentication model

1405
00:55:00,960 --> 00:55:02,400
as everything else in Graph.

1406
00:55:02,400 --> 00:55:04,800
The hybrid workplace use case is where this becomes

1407
00:55:04,800 --> 00:55:06,320
strategically meaningful.

1408
00:55:06,320 --> 00:55:09,920
On its own, room booking data tells you which meeting rooms are being reserved.

1409
00:55:09,920 --> 00:55:13,360
On its own, collaboration data from the reporting APIs

1410
00:55:13,360 --> 00:55:15,360
tells you which teams are meeting frequently.

1411
00:55:15,360 --> 00:55:18,720
But when you cross reference them across the same time windows and departments,

1412
00:55:18,720 --> 00:55:21,840
you get a picture of how physical space is actually being used.

1413
00:55:21,840 --> 00:55:24,800
You can see how that compares to how it was designed to be used,

1414
00:55:24,800 --> 00:55:26,720
which buildings are being avoided on which days,

1415
00:55:26,720 --> 00:55:30,240
which floors have reservation rates that suggest the desk allocation model

1416
00:55:30,240 --> 00:55:32,560
doesn't match how teams actually organize themselves,

1417
00:55:32,560 --> 00:55:35,200
which collaboration spaces are consistently overbooked

1418
00:55:35,200 --> 00:55:37,040
while adjacent spaces sit empty.

1419
00:55:37,040 --> 00:55:38,800
Those are real estate strategy questions.

1420
00:55:38,800 --> 00:55:40,160
They're also graph questions.

1421
00:55:40,160 --> 00:55:42,480
They are answerable with data that's already been generated

1422
00:55:42,480 --> 00:55:44,720
and sitting in systems your organization owns.

1423
00:55:44,720 --> 00:55:48,080
Organizations are currently redesigning office footprints for hybrid work.

1424
00:55:48,080 --> 00:55:50,640
This process is consuming significant capital and leadership

1425
00:55:50,640 --> 00:55:52,320
attention across every sector right now.

1426
00:55:52,320 --> 00:55:55,360
The places API is the data layer that makes evidence-based decisions

1427
00:55:55,360 --> 00:55:57,360
possible instead of intuition-based ones.

1428
00:55:57,360 --> 00:55:59,120
Search tells you what people are looking for.

1429
00:55:59,120 --> 00:56:02,000
The Viva APIs tell you how they're actually experiencing work.

1430
00:56:02,000 --> 00:56:05,920
Hidden gems, Viva, bookings, and organizational insights.

1431
00:56:05,920 --> 00:56:10,160
The Viva Insights Graph Service is really mentioned in M365 architecture talks.

1432
00:56:10,160 --> 00:56:14,000
It sits right next to the big productivity data we discussed with Graph Data Connect.

1433
00:56:14,000 --> 00:56:15,920
But it works at a much higher resolution.

1434
00:56:15,920 --> 00:56:18,000
It isn't about massive organizational patterns.

1435
00:56:18,000 --> 00:56:20,720
It's about team-level signals that you can actually use.

1436
00:56:20,720 --> 00:56:22,880
Without needing a whole team of data engineers,

1437
00:56:22,880 --> 00:56:24,720
here is what Graph actually shows you.

1438
00:56:24,720 --> 00:56:26,240
Meeting hours per person.

1439
00:56:26,240 --> 00:56:27,120
Focus time.

1440
00:56:27,120 --> 00:56:29,360
Those blocks where people are actually doing deep work.

1441
00:56:29,360 --> 00:56:33,200
After hours work volume, which is a signal for both burnout and capacity,

1442
00:56:33,200 --> 00:56:35,200
manager one-on-one frequency.

1443
00:56:35,200 --> 00:56:36,160
These aren't guesses.

1444
00:56:36,160 --> 00:56:39,520
They are facts pulled from the behavioral data your company is already creating.

1445
00:56:39,520 --> 00:56:41,360
You can query this through a consistent API

1446
00:56:41,360 --> 00:56:43,040
and feed it into your own analytics.

1447
00:56:43,040 --> 00:56:46,160
The meeting hygiene data usually gets the fastest reaction from leadership.

1448
00:56:46,160 --> 00:56:49,600
You can identify every team where meetings take up more than 60% of the week.

1449
00:56:49,600 --> 00:56:51,760
That 60% mark is a burnout signal.

1450
00:56:51,760 --> 00:56:53,840
When people spend three out of five days in meetings,

1451
00:56:53,840 --> 00:56:57,360
they are doing their real work before 9am or after 5pm.

1452
00:56:57,360 --> 00:56:58,640
The data is concrete.

1453
00:56:58,640 --> 00:57:01,360
It moves the conversation away from "I feel busy"

1454
00:57:01,360 --> 00:57:03,040
to "Here is the structural problem."

1455
00:57:03,040 --> 00:57:05,760
This also changes how you look at manager effectiveness.

1456
00:57:05,760 --> 00:57:08,320
ClearPekes found that employees with the highest engagement

1457
00:57:08,320 --> 00:57:09,520
all had one thing in common.

1458
00:57:09,520 --> 00:57:11,920
They had regular one-on-one meetings with their managers.

1459
00:57:11,920 --> 00:57:13,440
When those meetings stopped happening,

1460
00:57:13,440 --> 00:57:14,640
a Trishen risk went up.

1461
00:57:14,640 --> 00:57:18,160
After one organization used these signals to fix their management habits.

1462
00:57:18,160 --> 00:57:20,320
Their Trishen dropped by 50%.

1463
00:57:20,320 --> 00:57:22,800
ClearPekes also found that inefficient recurring meetings

1464
00:57:22,800 --> 00:57:24,560
were draining massive amounts of time.

1465
00:57:24,560 --> 00:57:26,160
By restructuring those patterns,

1466
00:57:26,160 --> 00:57:29,440
they gave back an average of 23 days per employee per year,

1467
00:57:29,440 --> 00:57:31,840
23 days, not by adding a new tool.

1468
00:57:31,840 --> 00:57:34,240
But by using the intelligence already sitting in graph,

1469
00:57:34,240 --> 00:57:37,680
the bookings API is probably the most misunderstood part of this list.

1470
00:57:37,680 --> 00:57:41,200
Microsoft Bookings is a scheduling service for external appointments.

1471
00:57:41,200 --> 00:57:44,000
But through graph, the entire model becomes programmable.

1472
00:57:44,000 --> 00:57:47,840
You can manage services, staff, and availability windows through the API

1473
00:57:47,840 --> 00:57:49,200
for large companies.

1474
00:57:49,200 --> 00:57:50,800
This allows you to centrally control

1475
00:57:50,800 --> 00:57:53,200
how appointments are logged and followed up on.

1476
00:57:53,200 --> 00:57:56,000
Most organizations don't even know this API exists.

1477
00:57:56,000 --> 00:57:58,720
Then there are the organizational data endpoints.

1478
00:57:58,720 --> 00:58:01,840
Get organization returns the metadata for your entire tenant.

1479
00:58:01,840 --> 00:58:04,880
Verified domains, service plans, technical contacts.

1480
00:58:04,880 --> 00:58:08,640
It isn't flashy, but it is the foundation for governance and license auditing.

1481
00:58:08,640 --> 00:58:12,320
Pulling this through graph instead of the admin portal is a small change.

1482
00:58:12,320 --> 00:58:15,440
But it's an operational improvement that adds up over time.

1483
00:58:15,440 --> 00:58:17,520
These endpoints share a common thread.

1484
00:58:17,520 --> 00:58:18,880
They aren't just data.

1485
00:58:18,880 --> 00:58:20,480
They are organizational intelligence.

1486
00:58:20,800 --> 00:58:23,680
The meeting, AI Insights API.

1487
00:58:23,680 --> 00:58:25,760
Turning conversations into structure.

1488
00:58:25,760 --> 00:58:27,600
Every meeting produces something.

1489
00:58:27,600 --> 00:58:30,880
A decision, an action item, a commitment made in front of a group.

1490
00:58:30,880 --> 00:58:33,760
But by Thursday, everyone remembers those things differently.

1491
00:58:33,760 --> 00:58:35,600
The problem isn't that meetings are useless.

1492
00:58:35,600 --> 00:58:38,720
The problem is that the outcomes become invisible the moment the call ends.

1493
00:58:38,720 --> 00:58:40,880
They live in messy notes or in someone's memory.

1494
00:58:40,880 --> 00:58:41,920
Or nowhere at all.

1495
00:58:41,920 --> 00:58:44,480
The meeting AI Insights API is the fix for that.

1496
00:58:44,480 --> 00:58:46,320
When you turn on Teams transcription,

1497
00:58:46,320 --> 00:58:48,400
the AI layer creates structured outputs.

1498
00:58:48,400 --> 00:58:51,280
Notes organized by topic. Action items assigned to names.

1499
00:58:51,280 --> 00:58:53,120
These aren't just stuck in the Teams interface.

1500
00:58:53,120 --> 00:58:55,040
They are queryable through graph at scale.

1501
00:58:55,040 --> 00:58:56,640
Across every meeting in your company.

1502
00:58:56,640 --> 00:58:58,320
This changes the workflow entirely.

1503
00:58:58,320 --> 00:59:01,040
You can pull action items into planner automatically.

1504
00:59:01,040 --> 00:59:02,000
No manual typing.

1505
00:59:02,000 --> 00:59:03,760
No, can you send me a summary?

1506
00:59:03,760 --> 00:59:04,720
GeoSale.

1507
00:59:04,720 --> 00:59:07,840
Eason is so emails.

1508
00:59:07,840 --> 00:59:10,240
The task exists the moment the transcript is done.

1509
00:59:10,240 --> 00:59:12,240
It's linked to the right person in the right meeting.

1510
00:59:12,240 --> 00:59:14,400
The accountability is built into the system,

1511
00:59:14,400 --> 00:59:16,160
not left up to individual discipline.

1512
00:59:16,160 --> 00:59:18,720
The C2C case shows how this works in the real world.

1513
00:59:18,720 --> 00:59:21,440
Trenatalia C2C, the UK Rail operator,

1514
00:59:21,440 --> 00:59:24,480
used graph and power automate to structure their team's environment.

1515
00:59:24,480 --> 00:59:26,640
They designed their channels and information flows

1516
00:59:26,640 --> 00:59:28,640
to make meeting outcomes easy to find.

1517
00:59:28,640 --> 00:59:30,640
It wasn't about using AI because it's cool.

1518
00:59:30,640 --> 00:59:34,000
It was about making follow through a natural part of the work day.

1519
00:59:34,000 --> 00:59:36,080
There is also the issue of institutional memory.

1520
00:59:36,080 --> 00:59:39,440
When meeting Insights are searchable, knowledge stops disappearing.

1521
00:59:39,440 --> 00:59:42,880
You don't have to ask three people what was decided about a contract six months ago.

1522
00:59:42,880 --> 00:59:44,240
You just search the record.

1523
00:59:44,240 --> 00:59:47,520
Decisions become part of the information layer that graph can surface.

1524
00:59:47,520 --> 00:59:50,240
But there are two big dependencies you need to know about.

1525
00:59:50,240 --> 00:59:52,080
First, this requires transcription.

1526
00:59:52,080 --> 00:59:54,080
If your policy has transcription turned off,

1527
00:59:54,080 --> 00:59:55,360
the API has nothing to do.

1528
00:59:55,360 --> 00:59:58,560
This is a conversation for legal and HR before it ever reaches IT.

1529
00:59:58,560 --> 01:00:01,120
Second, the schema is still moving.

1530
01:00:01,120 --> 01:00:03,040
This API is an active development.

1531
01:00:03,040 --> 01:00:05,760
The way action items are typed or how notes are organized

1532
01:00:05,760 --> 01:00:07,360
will change as it matures.

1533
01:00:07,360 --> 01:00:08,400
If you build on this,

1534
01:00:08,400 --> 01:00:10,880
build for change, use resilient logic,

1535
01:00:10,880 --> 01:00:13,680
don't build a rigid pipeline against a beta surface.

1536
01:00:13,680 --> 01:00:16,480
Individual meeting signals are just one part of the story.

1537
01:00:16,480 --> 01:00:19,440
The real picture comes from putting all these layers together.

1538
01:00:19,440 --> 01:00:20,880
Combining the layers,

1539
01:00:20,880 --> 01:00:23,920
what graph-driven organizations actually look like.

1540
01:00:23,920 --> 01:00:26,720
Most organizations aren't starting from zero on this.

1541
01:00:26,720 --> 01:00:30,080
You probably have some graph usage already, maybe a few reporting pulls.

1542
01:00:30,080 --> 01:00:32,880
A PowerShell script that queries audit logs on a schedule.

1543
01:00:32,880 --> 01:00:36,400
A Power Automate flow that calls graph to provision a Teams channel.

1544
01:00:36,400 --> 01:00:38,960
But in reality, these are isolated capabilities.

1545
01:00:38,960 --> 01:00:40,960
They were built to solve one specific problem.

1546
01:00:40,960 --> 01:00:42,400
They aren't connected to each other.

1547
01:00:42,400 --> 01:00:45,280
They don't produce something larger than the sum of their parts.

1548
01:00:45,280 --> 01:00:48,960
What separates the organizations that extract massive value from Microsoft 365

1549
01:00:48,960 --> 01:00:51,360
from the ones that don't isn't the size of the IT team?

1550
01:00:51,360 --> 01:00:53,360
It isn't how sophisticated the developers are.

1551
01:00:53,360 --> 01:00:56,400
It's whether their graph usage is coordinated or accidental.

1552
01:00:56,400 --> 01:00:59,360
It's whether the reporting layer talks to the governance layer

1553
01:00:59,360 --> 01:01:03,360
and whether your security signals actually inform your identity decisions.

1554
01:01:03,360 --> 01:01:04,400
The flow isn't the tools.

1555
01:01:04,400 --> 01:01:07,600
It's the assumption that you can assemble a collection of independent solutions

1556
01:01:07,600 --> 01:01:09,440
and expect them to work as a system.

1557
01:01:09,440 --> 01:01:11,760
Matur organizations run three parallel tracks.

1558
01:01:11,760 --> 01:01:14,000
The architecture becomes clear once you see it.

1559
01:01:14,000 --> 01:01:16,720
The first track is graph for real-time control and telemetry.

1560
01:01:16,720 --> 01:01:17,920
This is the nervous system.

1561
01:01:17,920 --> 01:01:20,080
It uses change notifications, delta queries,

1562
01:01:20,080 --> 01:01:22,000
and automated enforcement workflows

1563
01:01:22,000 --> 01:01:24,400
to detect and respond to events as they happen.

1564
01:01:24,400 --> 01:01:25,680
It runs continuously.

1565
01:01:25,680 --> 01:01:27,920
It validates and reacts across the tenant

1566
01:01:27,920 --> 01:01:30,400
faster than any human-driven process ever could.

1567
01:01:30,400 --> 01:01:33,280
The second track is graph data connect for scale analytics.

1568
01:01:33,280 --> 01:01:35,040
This is the governed bulk export layer

1569
01:01:35,040 --> 01:01:38,000
that feeds organizational intelligence into Azure and Fabric.

1570
01:01:38,000 --> 01:01:40,400
It runs on a cadence daily, weekly or monthly.

1571
01:01:40,400 --> 01:01:42,800
It answers the questions that require depth and time.

1572
01:01:42,800 --> 01:01:46,320
Interactive API calls can't tell you about workforce productivity patterns

1573
01:01:46,320 --> 01:01:49,680
or how your collaboration network has evolved over a 12-month window.

1574
01:01:49,680 --> 01:01:52,800
This is the executive view of how the organization is actually functioning,

1575
01:01:52,800 --> 01:01:54,240
not just how it's configured.

1576
01:01:54,240 --> 01:01:57,120
The third track is per view and entrap for compliance and identity.

1577
01:01:57,120 --> 01:01:58,560
This is the policy layer.

1578
01:01:58,560 --> 01:02:01,040
It gives the other two tracks their meaning.

1579
01:02:01,040 --> 01:02:03,280
Retention policies determine what data stays.

1580
01:02:03,280 --> 01:02:05,440
Access reviews validate whether permissions

1581
01:02:05,440 --> 01:02:07,040
still reflect a business need.

1582
01:02:07,040 --> 01:02:10,160
Life cycle workflows ensure that when someone joins or leaves,

1583
01:02:10,160 --> 01:02:13,200
the process executes with structural reliability.

1584
01:02:13,200 --> 01:02:15,840
Instead of depending on someone remembering to submit a ticket,

1585
01:02:15,840 --> 01:02:18,160
these three tracks are designed to be interdependent.

1586
01:02:18,160 --> 01:02:21,360
The telemetry from track one feeds the analytics in track two

1587
01:02:21,360 --> 01:02:24,400
while the compliance posture from track three defines exactly

1588
01:02:24,400 --> 01:02:26,400
what that telemetry should be looking for.

1589
01:02:26,400 --> 01:02:28,400
What typically happens is that scale analytics

1590
01:02:28,400 --> 01:02:30,000
from track two surface patterns

1591
01:02:30,000 --> 01:02:32,800
that tell you where to tighten or relax controls in track three.

1592
01:02:32,800 --> 01:02:33,840
It's not three systems.

1593
01:02:33,840 --> 01:02:36,160
It's one system with three operational tempos.

1594
01:02:36,160 --> 01:02:37,600
The convergence happening right now,

1595
01:02:37,600 --> 01:02:39,520
the one worth naming explicitly,

1596
01:02:39,520 --> 01:02:42,400
is between M365 governance and API governance.

1597
01:02:42,400 --> 01:02:44,080
APIs are the objects being governed

1598
01:02:44,080 --> 01:02:46,960
and they are the mechanisms used to enforce that governance.

1599
01:02:46,960 --> 01:02:49,920
The app registrations and consent grants that allow graph access

1600
01:02:49,920 --> 01:02:52,800
are themselves objects that require a life cycle.

1601
01:02:52,800 --> 01:02:55,440
The same graph calls you used to enforce naming policies

1602
01:02:55,440 --> 01:02:58,240
or the calls your security team needs to monitor for abuse.

1603
01:02:58,240 --> 01:03:00,400
The permission surface that enables your automation

1604
01:03:00,400 --> 01:03:02,800
is also the attack surface your adversaries are mapping.

1605
01:03:02,800 --> 01:03:04,320
These aren't separate concerns.

1606
01:03:04,320 --> 01:03:06,720
They are the same concern viewed from different angles.

1607
01:03:06,720 --> 01:03:10,240
Microsoft's own internal model describes risk aligned oversight

1608
01:03:10,240 --> 01:03:13,440
of AI agents and central policy with federated execution.

1609
01:03:13,440 --> 01:03:14,880
That's not a theoretical framework.

1610
01:03:14,880 --> 01:03:17,680
It's what the organization that builds this software uses internally

1611
01:03:17,680 --> 01:03:18,560
to govern it.

1612
01:03:18,560 --> 01:03:20,480
The reference architecture is available.

1613
01:03:20,480 --> 01:03:23,440
The organizations that study it and adapt it to their own context

1614
01:03:23,440 --> 01:03:25,280
are the ones whose governance doesn't fall apart

1615
01:03:25,280 --> 01:03:27,280
the moment in new capability ships.

1616
01:03:27,280 --> 01:03:29,680
The failure mode to avoid is treating any of this

1617
01:03:29,680 --> 01:03:31,520
as a project with a completion date.

1618
01:03:31,520 --> 01:03:34,400
Governance frameworks that hold through platform evolution

1619
01:03:34,400 --> 01:03:36,400
and AI rollouts are built as a running service.

1620
01:03:36,400 --> 01:03:39,280
They have continuous measurement and scheduled review cycles.

1621
01:03:39,280 --> 01:03:42,400
They have the mandate to adjust when signals indicate drift.

1622
01:03:42,400 --> 01:03:45,680
It isn't a policy document delivered to a SharePoint library in Q2

1623
01:03:45,680 --> 01:03:47,680
and revisited at the next audit.

1624
01:03:47,680 --> 01:03:50,640
Graph-driven governance isn't an IT initiative.

1625
01:03:50,640 --> 01:03:54,320
It's the infrastructure that determines whether your AI investments compound

1626
01:03:54,320 --> 01:03:58,320
or collapse, permissions, consent, and the graph risk register.

1627
01:03:58,320 --> 01:04:00,720
Everything we've built, the reporting, the automation,

1628
01:04:00,720 --> 01:04:03,600
the co-pilot control plane, runs on a permission model.

1629
01:04:03,600 --> 01:04:06,960
And in most organizations, that model is the least governed part

1630
01:04:06,960 --> 01:04:08,400
of the entire graph architecture.

1631
01:04:08,400 --> 01:04:10,400
It's not because people don't know it matters.

1632
01:04:10,400 --> 01:04:12,000
It's because the conversation happens once

1633
01:04:12,000 --> 01:04:13,440
when the integration is built.

1634
01:04:13,440 --> 01:04:16,080
And then nobody looks at it again until something goes wrong.

1635
01:04:16,080 --> 01:04:19,120
Two permission types govern how applications interact with graph.

1636
01:04:19,120 --> 01:04:21,280
The distinction between them is a security decision

1637
01:04:21,280 --> 01:04:23,120
masquerading as a technical one.

1638
01:04:23,120 --> 01:04:25,520
Delegated permissions operate in a user context.

1639
01:04:25,520 --> 01:04:28,480
The application acts on behalf of a signed in user.

1640
01:04:28,480 --> 01:04:30,560
It's constrained by what that user can already see.

1641
01:04:30,560 --> 01:04:31,280
No more.

1642
01:04:32,240 --> 01:04:35,280
Application permissions or app-only permissions.

1643
01:04:35,280 --> 01:04:37,440
Remove the user context entirely.

1644
01:04:37,440 --> 01:04:39,200
The application authenticates as itself.

1645
01:04:39,200 --> 01:04:40,640
It uses a service principle.

1646
01:04:40,640 --> 01:04:43,440
It operates with whatever scopes were granted at consent time.

1647
01:04:43,440 --> 01:04:45,040
Orgwide, without a user present,

1648
01:04:45,040 --> 01:04:47,920
it lacks the natural guardrail of a human's access boundary.

1649
01:04:47,920 --> 01:04:50,000
That distinction matters because app-only permissions

1650
01:04:50,000 --> 01:04:52,640
power every meaningful graph automation we've discussed.

1651
01:04:52,640 --> 01:04:55,520
Scheduled reporting jobs and governance enforcement workflows

1652
01:04:55,520 --> 01:04:58,240
require app-only access to operate across the tenant

1653
01:04:58,240 --> 01:04:59,600
without a human logged in.

1654
01:04:59,600 --> 01:05:00,640
But here's the problem.

1655
01:05:00,640 --> 01:05:03,840
Every one of those app-only grants is a potential lateral movement channel

1656
01:05:03,840 --> 01:05:05,440
if the credentials are compromised.

1657
01:05:05,440 --> 01:05:06,640
This isn't theoretical.

1658
01:05:06,640 --> 01:05:09,440
An attacker who gets a token for an application with mail,

1659
01:05:09,440 --> 01:05:11,840
read can read every mailbox in your organization.

1660
01:05:11,840 --> 01:05:15,440
If they get directory, read all they can enumerate every user,

1661
01:05:15,440 --> 01:05:17,280
group, and roll assignment you have.

1662
01:05:17,280 --> 01:05:19,280
The permission service your automation relies on

1663
01:05:19,280 --> 01:05:21,280
is exactly the surface and attacker maps

1664
01:05:21,280 --> 01:05:23,280
when they're looking for high value access.

1665
01:05:23,280 --> 01:05:26,400
Treating it as a developer convenience rather than a risk register item

1666
01:05:26,400 --> 01:05:28,000
is an architectural mistake.

1667
01:05:28,000 --> 01:05:31,360
The consent governance pattern that actually works starts with documentation.

1668
01:05:31,360 --> 01:05:34,480
For every application with graph access, you need to document four things.

1669
01:05:34,480 --> 01:05:36,000
You need the exact scopes requested

1670
01:05:36,000 --> 01:05:38,080
and the business justification for each one.

1671
01:05:38,080 --> 01:05:41,200
You need to know the data flows, the application participates in

1672
01:05:41,200 --> 01:05:43,760
and what happens to the business if consent is revoked.

1673
01:05:43,760 --> 01:05:45,840
This consent ledger gives your security team

1674
01:05:45,840 --> 01:05:48,480
the visibility to assess what's actually exposed.

1675
01:05:48,480 --> 01:05:51,440
It also gives your developers the discipline of justifying permissions

1676
01:05:51,440 --> 01:05:52,720
before they request them,

1677
01:05:52,720 --> 01:05:55,200
which predictably reduces scope creep.

1678
01:05:55,200 --> 01:05:57,520
The app registration hygiene problem in most tenants

1679
01:05:57,520 --> 01:05:58,560
is severe.

1680
01:05:58,560 --> 01:06:01,680
Organizations that audit their registrations for the first time consistently

1681
01:06:01,680 --> 01:06:05,280
find dozens of applications with excessive scopes and no-named owners.

1682
01:06:05,280 --> 01:06:08,240
They find client secrets that haven't been rotated in years

1683
01:06:08,240 --> 01:06:10,320
and apps with no documented purpose.

1684
01:06:10,320 --> 01:06:12,320
Some were built by people who no longer work there.

1685
01:06:12,320 --> 01:06:14,080
Others were created for a proof of concept

1686
01:06:14,080 --> 01:06:16,480
that never went to production but was never deleted.

1687
01:06:16,480 --> 01:06:18,720
Each one is an undocumented attack surface.

1688
01:06:18,720 --> 01:06:20,720
The operational safeguards that close this gap

1689
01:06:20,720 --> 01:06:23,440
aren't complicated, but they require execution.

1690
01:06:23,440 --> 01:06:25,840
You need separate app registrations for development,

1691
01:06:25,840 --> 01:06:27,520
test and production environments.

1692
01:06:27,520 --> 01:06:29,520
That means different credentials, different scopes

1693
01:06:29,520 --> 01:06:30,960
and different audit trails.

1694
01:06:30,960 --> 01:06:33,200
You need scheduled secret and certificate rotation

1695
01:06:33,200 --> 01:06:35,120
enforced through an automation pipeline.

1696
01:06:35,120 --> 01:06:38,080
You also need to centralize graph audit logs and correlation IDs

1697
01:06:38,080 --> 01:06:39,120
into your CM.

1698
01:06:39,120 --> 01:06:42,000
Every API call made by every application in your tenant

1699
01:06:42,000 --> 01:06:45,280
must be visible and queryable when an investigation requires it.

1700
01:06:45,280 --> 01:06:49,360
The metered API reality adds a cost dimension to this in 2026.

1701
01:06:49,360 --> 01:06:51,680
Microsoft is expanding consumption-based pricing

1702
01:06:51,680 --> 01:06:53,440
for high-value graph operations

1703
01:06:53,440 --> 01:06:56,320
like certain export functions and analytics workloads.

1704
01:06:56,320 --> 01:06:58,400
Applications with poorly scoped permissions

1705
01:06:58,400 --> 01:07:00,320
don't just create security exposure.

1706
01:07:00,320 --> 01:07:02,160
They create unpredictable cost exposure

1707
01:07:02,160 --> 01:07:04,160
when those permissions are exercised at scale.

1708
01:07:04,160 --> 01:07:06,960
Graph permission governance is not a compliance checkbox.

1709
01:07:06,960 --> 01:07:08,960
It's the foundation everything else depends on.

1710
01:07:08,960 --> 01:07:11,280
If this changed how you think about your tenant,

1711
01:07:11,280 --> 01:07:13,120
follow me, Mokopetus, on LinkedIn.

1712
01:07:13,120 --> 01:07:15,280
And if you want more of this, leave a review.

1713
01:07:15,280 --> 01:07:16,960
It helps more people find it.

1714
01:07:16,960 --> 01:07:18,080
The road map.

1715
01:07:18,080 --> 01:07:20,640
Where graph is going in 2026 and beyond.

1716
01:07:20,640 --> 01:07:22,800
The clearest signal about where graph is going

1717
01:07:22,800 --> 01:07:24,080
isn't in a product announcement.

1718
01:07:24,080 --> 01:07:25,440
It's in a pattern.

1719
01:07:25,440 --> 01:07:27,760
Every major Microsoft 365 capability

1720
01:07:27,760 --> 01:07:29,440
that shipped in the last two years arrived

1721
01:07:29,440 --> 01:07:30,880
with graph support on day one.

1722
01:07:30,880 --> 01:07:33,760
The legacy API is EWS, Azure AD graph,

1723
01:07:33,760 --> 01:07:35,760
the original SharePoint rest endpoints.

1724
01:07:35,760 --> 01:07:38,800
They aren't being retired because Microsoft wanted to clean house.

1725
01:07:38,800 --> 01:07:42,000
They're being retired because everything new is being built somewhere else.

1726
01:07:42,000 --> 01:07:43,520
Graph is where the platform is moving.

1727
01:07:43,520 --> 01:07:45,200
The legacy surfaces are where it came from.

1728
01:07:45,200 --> 01:07:47,840
That pattern has a direct implication for how you plan.

1729
01:07:47,840 --> 01:07:49,840
If your automation, your reporting, your governance

1730
01:07:49,840 --> 01:07:51,920
or your security integrations are built on anything

1731
01:07:51,920 --> 01:07:54,160
that predates the unified graph surface.

1732
01:07:54,160 --> 01:07:57,040
You're running on infrastructure that is shrinking towards zero.

1733
01:07:57,040 --> 01:07:58,960
Not suddenly, not all at once,

1734
01:07:58,960 --> 01:08:01,680
but consistently and directionally.

1735
01:08:01,680 --> 01:08:03,840
The forcing function is already in motion.

1736
01:08:03,840 --> 01:08:05,280
The co-pilot agent mode rollout,

1737
01:08:05,280 --> 01:08:07,280
which started in early 2026,

1738
01:08:07,280 --> 01:08:09,120
makes this dependency concrete.

1739
01:08:09,120 --> 01:08:11,360
Agent mode in Microsoft 365 co-pilot

1740
01:08:11,360 --> 01:08:12,800
doesn't just find information.

1741
01:08:12,800 --> 01:08:14,480
It orchestrates multi-step workflows,

1742
01:08:14,480 --> 01:08:16,320
pulling data from multiple sources,

1743
01:08:16,320 --> 01:08:18,400
drafting content, updating records,

1744
01:08:18,400 --> 01:08:19,920
and scheduling follow-ups.

1745
01:08:19,920 --> 01:08:21,920
It uses graph as the operational layer

1746
01:08:21,920 --> 01:08:23,200
underneath every single action.

1747
01:08:23,200 --> 01:08:24,640
The more mature your graph deployment,

1748
01:08:24,640 --> 01:08:26,400
the more capable those agents become.

1749
01:08:26,400 --> 01:08:28,800
An organization that has cleaned up its permissions,

1750
01:08:28,800 --> 01:08:30,400
consolidated its content,

1751
01:08:30,400 --> 01:08:32,640
and built consistent governance across teams

1752
01:08:32,640 --> 01:08:34,960
and SharePoint isn't just ready for today's co-pilot.

1753
01:08:34,960 --> 01:08:36,560
It's ready for every agent workflow

1754
01:08:36,560 --> 01:08:38,000
that ships on top of it from now on.

1755
01:08:38,000 --> 01:08:39,360
Graph maturity compounds.

1756
01:08:39,360 --> 01:08:43,920
The federation signal from the broader API ecosystem is worth naming

1757
01:08:43,920 --> 01:08:46,720
because it describes where enterprise architecture is heading,

1758
01:08:46,720 --> 01:08:48,400
not just where Microsoft is going.

1759
01:08:48,400 --> 01:08:50,960
The state of federation 2026 survey was conducted

1760
01:08:50,960 --> 01:08:52,960
across enterprises building on GraphQL

1761
01:08:52,960 --> 01:08:54,480
and Graph-based infrastructure.

1762
01:08:54,480 --> 01:08:58,400
It shows a clear shift from organizations running individual graph services

1763
01:08:58,400 --> 01:09:00,800
toward enterprises building unified graph layers

1764
01:09:00,800 --> 01:09:02,960
that span many domains at once.

1765
01:09:02,960 --> 01:09:04,720
One coherent surface over identity,

1766
01:09:04,720 --> 01:09:07,040
collaboration, security, and analytics,

1767
01:09:07,040 --> 01:09:08,240
rather than separate endpoints

1768
01:09:08,240 --> 01:09:10,320
that require separate integration patterns.

1769
01:09:10,320 --> 01:09:14,160
Microsoft Graph is already that surface for Microsoft 365.

1770
01:09:14,160 --> 01:09:17,280
The question is whether your organization has recognized it yet

1771
01:09:17,280 --> 01:09:19,200
and started governing it accordingly.

1772
01:09:19,200 --> 01:09:21,840
The AI agent consumption pattern from Web3

1773
01:09:21,840 --> 01:09:24,560
provides a forward-looking signal we should take seriously.

1774
01:09:24,560 --> 01:09:27,200
In early 2026 more than one in three new accounts

1775
01:09:27,200 --> 01:09:30,160
using the GraphStoken API, a blockchain data service

1776
01:09:30,160 --> 01:09:33,040
belonged to AI agents rather than human developers.

1777
01:09:33,040 --> 01:09:34,800
That ratio didn't exist two years ago.

1778
01:09:34,800 --> 01:09:36,720
It will look conservative two years from now.

1779
01:09:36,720 --> 01:09:38,640
The same shift is coming to the enterprise.

1780
01:09:38,640 --> 01:09:41,680
Your automations are already non-human consumers of the API.

1781
01:09:41,680 --> 01:09:44,480
Your co-pilot deployments are already generating graph calls

1782
01:09:44,480 --> 01:09:46,480
that no human explicitly started.

1783
01:09:46,480 --> 01:09:49,600
The proportion of graph traffic that comes from agents, workflows,

1784
01:09:49,600 --> 01:09:52,400
and automated systems rather than human sessions

1785
01:09:52,400 --> 01:09:54,400
will increase significantly.

1786
01:09:54,400 --> 01:09:57,600
The governance model you build now needs to account for that trajectory.

1787
01:09:57,600 --> 01:10:00,720
The friction is real and it deserves an honest look.

1788
01:10:00,720 --> 01:10:05,280
A March 2026 article from Office 365 IT Pros describes the reality

1789
01:10:05,280 --> 01:10:07,360
of working at the edge of graph right now,

1790
01:10:07,360 --> 01:10:08,960
frequent changes without notice,

1791
01:10:08,960 --> 01:10:11,040
documentation that lags behind the code,

1792
01:10:11,040 --> 01:10:14,000
throttling behaviors that differ between environments,

1793
01:10:14,000 --> 01:10:17,520
and breaking changes that hit production before they hit the change logs.

1794
01:10:17,520 --> 01:10:19,360
But that's not a reason to stay shallow.

1795
01:10:19,360 --> 01:10:21,840
Every mature platform has operational friction.

1796
01:10:21,840 --> 01:10:24,240
The organizations that navigated build for resilience,

1797
01:10:24,240 --> 01:10:27,040
they use defensive passing, version-aware integrations,

1798
01:10:27,040 --> 01:10:30,000
and monitoring that catches drift before it becomes an outage.

1799
01:10:30,000 --> 01:10:32,640
They have an organizational expectation that graph maintenance

1800
01:10:32,640 --> 01:10:35,040
is ongoing work, not a one-time project.

1801
01:10:35,040 --> 01:10:36,400
Regidity is what breaks.

1802
01:10:36,400 --> 01:10:39,600
Resilience is what scales.

1803
01:10:39,600 --> 01:10:42,400
Graph is no longer optional infrastructure.

1804
01:10:42,400 --> 01:10:45,840
It's the operating system your Microsoft 365 estate is already running on.

1805
01:10:45,840 --> 01:10:48,080
The organizations that understand its hidden logic,

1806
01:10:48,080 --> 01:10:51,280
that treat it as the control plane rather than just a query tool,

1807
01:10:51,280 --> 01:10:54,720
are the ones that get the most value from every Microsoft investment they make.

1808
01:10:54,720 --> 01:10:56,080
From every license they renew,

1809
01:10:56,080 --> 01:10:58,720
from every AI capability that ships on top of it.

1810
01:10:58,720 --> 01:11:01,440
Microsoft Graph isn't a developer API,

1811
01:11:01,440 --> 01:11:04,400
it's the control plane your organization is already running on,

1812
01:11:04,400 --> 01:11:06,560
and most of you are only using 10% of it.

1813
01:11:06,560 --> 01:11:08,320
Pick one surface from today's episode,

1814
01:11:08,320 --> 01:11:11,440
reporting, audit logs, identity governance, security,

1815
01:11:11,440 --> 01:11:13,040
or one of the hidden gems,

1816
01:11:13,040 --> 01:11:15,040
build one thing with it in the next 30 days,

1817
01:11:15,040 --> 01:11:17,040
not a proof of concept, something real.

1818
01:11:17,040 --> 01:11:19,120
If this episode changed how you think about Graph,

1819
01:11:19,120 --> 01:11:22,320
I'd genuinely appreciate a review on your podcast platform.

1820
01:11:22,320 --> 01:11:24,000
It helps more people find the show,

1821
01:11:24,000 --> 01:11:26,720
and it helps me understand what topics matter most to you.

1822
01:11:26,720 --> 01:11:27,600
Connect with me,

1823
01:11:27,600 --> 01:11:29,520
Mirko Peters, on LinkedIn.

1824
01:11:29,520 --> 01:11:33,360
The best episode topics come from conversations with people actually doing this work,

1825
01:11:33,360 --> 01:11:35,120
and I'm always looking for the next one.

1826
01:11:35,120 --> 01:11:38,320
Next time, we go deeper on one of these layers, stay tuned.