How to Architect Scalable SharePoint Automation: The Modern Blueprint for Enterprise Workflows

1
00:00:00,000 --> 00:00:02,400
Most organizations assume SharePoint automation scales

2
00:00:02,400 --> 00:00:04,040
because it's in the platform.

3
00:00:04,040 --> 00:00:06,240
They are wrong, the UI makes it feel small,

4
00:00:06,240 --> 00:00:08,160
one library, one button, one approval,

5
00:00:08,160 --> 00:00:09,440
but the moment you automate,

6
00:00:09,440 --> 00:00:11,360
you've built an enterprise control plane

7
00:00:11,360 --> 00:00:14,240
that executes decisions, changes permissions,

8
00:00:14,240 --> 00:00:16,880
and moves data across compliance boundaries.

9
00:00:16,880 --> 00:00:20,080
In the next hour, this becomes obvious.

10
00:00:20,080 --> 00:00:22,120
How quick steps, workflows, and agents

11
00:00:22,120 --> 00:00:23,600
actually behave at scale,

12
00:00:23,600 --> 00:00:27,240
and how identity, labels, DLP and observability,

13
00:00:27,240 --> 00:00:30,080
either enforced intent, or let entropy win.

14
00:00:30,080 --> 00:00:32,880
Stop thinking features, start thinking systems.

15
00:00:32,880 --> 00:00:34,520
The foundational misunderstanding,

16
00:00:34,520 --> 00:00:37,360
SharePoint is a workflow surface, not a repository.

17
00:00:37,360 --> 00:00:39,520
The foundational mistake is treating SharePoint

18
00:00:39,520 --> 00:00:41,520
like a place where files live.

19
00:00:41,520 --> 00:00:44,560
Architecturally, SharePoint is a workflow surface.

20
00:00:44,560 --> 00:00:47,840
Content plus metadata plus permissions plus policy,

21
00:00:47,840 --> 00:00:50,520
all sitting in front of a distributed execution engine.

22
00:00:50,520 --> 00:00:53,160
That sounds abstract, but it explains almost every,

23
00:00:53,160 --> 00:00:54,720
we didn't expect that incident

24
00:00:54,720 --> 00:00:56,400
an enterprise has with automation.

25
00:00:56,400 --> 00:00:59,240
Document library is not a folder tree with version history.

26
00:00:59,240 --> 00:01:00,320
It's an event source.

27
00:01:00,320 --> 00:01:03,880
Every upload, edit, metadata update, approval change,

28
00:01:03,880 --> 00:01:06,120
sharing link and access request is a signal

29
00:01:06,120 --> 00:01:08,080
you can wire into power automate,

30
00:01:08,080 --> 00:01:10,840
graph subscriptions, logic apps, functions,

31
00:01:10,840 --> 00:01:12,480
or an agent experience.

32
00:01:12,480 --> 00:01:15,240
The second you do that, the blast radius changes.

33
00:01:15,240 --> 00:01:17,360
A simple flow isn't just sending an email,

34
00:01:17,360 --> 00:01:19,640
it's now an integration between identity policy

35
00:01:19,640 --> 00:01:21,480
and data movement running at machine speed

36
00:01:21,480 --> 00:01:24,640
without the human friction that used to slow mistakes down.

37
00:01:24,640 --> 00:01:26,800
This is why automation sprawl is inevitable

38
00:01:26,800 --> 00:01:28,280
if you don't design for it.

39
00:01:28,280 --> 00:01:30,440
SharePoint makes it easy to add triggers.

40
00:01:30,440 --> 00:01:32,520
Teams makes it easy to add notifications.

41
00:01:32,520 --> 00:01:34,720
Power automate makes it easy to glue it together.

42
00:01:34,720 --> 00:01:37,120
And then the organization wakes up six months later

43
00:01:37,120 --> 00:01:39,080
with three versions of the same approval,

44
00:01:39,080 --> 00:01:41,320
seven different notify the channel workflows

45
00:01:41,320 --> 00:01:44,200
and an unspoken rule that nobody touches the flows

46
00:01:44,200 --> 00:01:46,400
because nobody knows which business process will break.

47
00:01:46,400 --> 00:01:47,520
That's not a tooling failure.

48
00:01:47,520 --> 00:01:49,960
That's what happens when execution grows faster than intent.

49
00:01:49,960 --> 00:01:51,400
Now layer in the new reality,

50
00:01:51,400 --> 00:01:54,480
deterministic automation versus probabilistic automation.

51
00:01:54,480 --> 00:01:56,320
Deterministic automation is the old model.

52
00:01:56,320 --> 00:01:58,400
The system follows explicit rules.

53
00:01:58,400 --> 00:02:01,280
If a file enters this library, set metadata,

54
00:02:01,280 --> 00:02:03,720
if status becomes approved, move it.

55
00:02:03,720 --> 00:02:07,160
If label equals confidential, block external sharing,

56
00:02:07,160 --> 00:02:10,280
boring, predictable, auditable.

57
00:02:10,280 --> 00:02:12,840
The kind of automation you can defend in an incident review

58
00:02:12,840 --> 00:02:15,880
because you can point to inputs, outputs, and logs.

59
00:02:15,880 --> 00:02:18,360
Probabilistic automation is the agent model.

60
00:02:18,360 --> 00:02:21,760
An agent reads context in first meaning chooses a next action

61
00:02:21,760 --> 00:02:23,560
and may do different things for two files

62
00:02:23,560 --> 00:02:25,120
that look similar to a human.

63
00:02:25,120 --> 00:02:26,240
The system becomes helpful,

64
00:02:26,240 --> 00:02:28,880
but you've traded a rules engine for a reasoning engine.

65
00:02:28,880 --> 00:02:31,200
That distinction matters because governance mechanisms

66
00:02:31,200 --> 00:02:32,880
designed for deterministic flows

67
00:02:32,880 --> 00:02:35,640
don't automatically constrain probabilistic decisioning.

68
00:02:35,640 --> 00:02:37,320
They just make you feel like they do.

69
00:02:37,320 --> 00:02:39,920
So SharePoint isn't becoming smarter automation.

70
00:02:39,920 --> 00:02:43,120
It's becoming a place where decisions happen closer to the data.

71
00:02:43,120 --> 00:02:44,040
That's powerful.

72
00:02:44,040 --> 00:02:46,440
It's also how organizations accidentally build

73
00:02:46,440 --> 00:02:48,320
a parallel IT estate.

74
00:02:48,320 --> 00:02:50,600
Thousands of micro workflows embedded in sites,

75
00:02:50,600 --> 00:02:53,360
lists, libraries, chats, and personal environments,

76
00:02:53,360 --> 00:02:54,560
each one seems harmless.

77
00:02:54,560 --> 00:02:57,160
Collectively, they form an authorization graph

78
00:02:57,160 --> 00:02:59,680
and an execution graph you didn't model, didn't test,

79
00:02:59,680 --> 00:03:01,120
and can't explain to an auditor.

80
00:03:01,120 --> 00:03:03,520
This is where the workflow surface idea clicks.

81
00:03:03,520 --> 00:03:05,320
SharePoint is the user-facing layer

82
00:03:05,320 --> 00:03:08,280
where business intent gets translated into machine action.

83
00:03:08,280 --> 00:03:10,040
Quick steps turn a column into a button,

84
00:03:10,040 --> 00:03:12,600
approvals turn a pill-shaped status into a gate.

85
00:03:12,600 --> 00:03:14,440
Integrated workflow UX turns,

86
00:03:14,440 --> 00:03:17,280
I'm in this library, into pre-wired connectors and templates.

87
00:03:17,280 --> 00:03:19,360
And because it's in context, people use it more.

88
00:03:19,360 --> 00:03:22,480
Usage goes up, volume goes up, variance goes up,

89
00:03:22,480 --> 00:03:24,480
and variance is where scale dies.

90
00:03:24,480 --> 00:03:26,200
Because what scales isn't a flow?

91
00:03:26,200 --> 00:03:27,360
What scales is a pattern?

92
00:03:27,360 --> 00:03:29,920
Consistent eventing, consistent identity boundaries,

93
00:03:29,920 --> 00:03:31,560
consistent data classification,

94
00:03:31,560 --> 00:03:34,120
consistent enforcement, and consistent observability.

95
00:03:34,120 --> 00:03:35,720
Without that, you don't have automation,

96
00:03:35,720 --> 00:03:37,040
you have conditional chaos.

97
00:03:37,040 --> 00:03:38,680
Here's the uncomfortable truth.

98
00:03:38,680 --> 00:03:41,720
If you let SharePoint automation evolve organically,

99
00:03:41,720 --> 00:03:43,360
you will eventually lose the ability

100
00:03:43,360 --> 00:03:44,920
to answer basic questions.

101
00:03:44,920 --> 00:03:46,280
Who can trigger this action?

102
00:03:46,280 --> 00:03:47,960
Which identity performs the right?

103
00:03:47,960 --> 00:03:49,480
Where does the data go next?

104
00:03:49,480 --> 00:03:50,800
What policy was evaluated?

105
00:03:50,800 --> 00:03:52,800
What evidence exists that it happened correctly?

106
00:03:52,800 --> 00:03:54,920
If you can't answer those, you are not operating

107
00:03:54,920 --> 00:03:56,120
a workflow platform.

108
00:03:56,120 --> 00:03:57,400
You are operating a rumor.

109
00:03:57,400 --> 00:03:59,520
So the goal of this blueprint is not to teach buttons

110
00:03:59,520 --> 00:04:00,520
or templates.

111
00:04:00,520 --> 00:04:03,360
It's to define the building blocks before you choose tools.

112
00:04:03,360 --> 00:04:06,840
What SharePoint emits as events, how decisions should be made,

113
00:04:06,840 --> 00:04:08,120
where orchestration should live,

114
00:04:08,120 --> 00:04:11,120
and how enforcement survives human creativity.

115
00:04:11,120 --> 00:04:12,520
Once that model is clear,

116
00:04:12,520 --> 00:04:15,360
Quick steps and agents stop being cool features.

117
00:04:15,360 --> 00:04:17,320
They become controlled interfaces to a system

118
00:04:17,320 --> 00:04:18,600
you can actually run.

119
00:04:18,600 --> 00:04:22,080
The modern automation stack Quick steps approvals flows agents.

120
00:04:22,080 --> 00:04:24,680
SharePoint's modern automation stack looks simple

121
00:04:24,680 --> 00:04:27,160
because Microsoft intentionally hit the wiring.

122
00:04:27,160 --> 00:04:28,200
That's the selling point.

123
00:04:28,200 --> 00:04:29,080
It's also the risk.

124
00:04:29,080 --> 00:04:31,480
So the only sane way to talk about Quick steps,

125
00:04:31,480 --> 00:04:35,040
approvals workflows and agents is this layers of the same system.

126
00:04:35,040 --> 00:04:37,640
An action surface, a gate, an orchestration engine,

127
00:04:37,640 --> 00:04:40,520
and an interface that pretends it isn't an interface.

128
00:04:40,520 --> 00:04:43,080
Start with Quick steps.

129
00:04:43,080 --> 00:04:45,000
Quick steps are the Ingrid action layer.

130
00:04:45,000 --> 00:04:47,800
Repeatable actions exposed where the work happens.

131
00:04:47,800 --> 00:04:50,000
Directly on list items and files.

132
00:04:50,000 --> 00:04:52,520
People used to do this with custom column formatting

133
00:04:52,520 --> 00:04:53,520
and JSON buttons.

134
00:04:53,520 --> 00:04:55,560
Now it's a first class column type.

135
00:04:55,560 --> 00:04:57,840
And it matters because the grid is where users live.

136
00:04:57,840 --> 00:05:00,240
If an action sits in the ribbon, it's optional.

137
00:05:00,240 --> 00:05:03,560
If it sits next to the file, it becomes the way we do things.

138
00:05:03,560 --> 00:05:06,280
The simple version is Quick steps remove friction.

139
00:05:06,280 --> 00:05:07,880
They also remove deliberation.

140
00:05:07,880 --> 00:05:10,040
A Quick step can set a value, move a file,

141
00:05:10,040 --> 00:05:11,880
draft an email, start a team's chat,

142
00:05:11,880 --> 00:05:14,960
and this is the one that changes the game, execute a flow.

143
00:05:14,960 --> 00:05:17,840
And Microsoft explicitly called out that execute flow quick steps

144
00:05:17,840 --> 00:05:20,160
don't have to be constrained to the default environment.

145
00:05:20,160 --> 00:05:22,920
That means the button in the library can trigger automation.

146
00:05:22,920 --> 00:05:25,200
You're not even mentally associating with that site.

147
00:05:25,200 --> 00:05:28,480
That distinction matters because you're no longer governing flows.

148
00:05:28,480 --> 00:05:30,160
You're governing invocation points.

149
00:05:30,160 --> 00:05:32,360
Next layer, lightweight approvals.

150
00:05:32,360 --> 00:05:34,600
These approvals live in the list or library

151
00:05:34,600 --> 00:05:36,800
presented as a pill-shaped status column.

152
00:05:36,800 --> 00:05:39,080
Admin's or owners can enable them with a toggle

153
00:05:39,080 --> 00:05:40,800
and then define default approvals.

154
00:05:40,800 --> 00:05:42,760
They can even stage and sequence those approvals.

155
00:05:42,760 --> 00:05:45,200
So the approval happens in an assigned order.

156
00:05:45,200 --> 00:05:46,600
The UX feels harmless.

157
00:05:46,600 --> 00:05:47,440
Click Submit.

158
00:05:47,440 --> 00:05:50,240
A team's notification goes out and the status updates.

159
00:05:50,240 --> 00:05:52,560
But architecturally, you've just created a state machine

160
00:05:52,560 --> 00:05:53,760
embedded in metadata.

161
00:05:53,760 --> 00:05:54,600
And that's the value.

162
00:05:54,600 --> 00:05:56,760
It keeps the workflow state with the item,

163
00:05:56,760 --> 00:05:58,960
instead of scattering it across email threads,

164
00:05:58,960 --> 00:06:01,080
teams chats, and personal spreadsheets.

165
00:06:01,080 --> 00:06:03,840
It also creates a consistent governance surface.

166
00:06:03,840 --> 00:06:06,680
Approval requested, pending, approved, rejected.

167
00:06:06,680 --> 00:06:09,280
That's something you can audit, something you can query,

168
00:06:09,280 --> 00:06:10,920
something you can enforce downstream.

169
00:06:10,920 --> 00:06:14,240
But don't confuse, built in with enterprise grade by default.

170
00:06:14,240 --> 00:06:17,320
Approval routing still depends on identity and permissions.

171
00:06:17,320 --> 00:06:20,080
Approval selection still creates an implicit authorization

172
00:06:20,080 --> 00:06:20,680
model.

173
00:06:20,680 --> 00:06:22,760
And the moment someone asks for exceptions,

174
00:06:22,760 --> 00:06:25,560
this library needs a different approver for this client,

175
00:06:25,560 --> 00:06:28,680
or skip step two if it's under $5,000.

176
00:06:28,680 --> 00:06:31,320
You're back to the same question, where does branching logic

177
00:06:31,320 --> 00:06:32,800
live and who owns it?

178
00:06:32,800 --> 00:06:35,040
Now the workflows, UX-spont Microsoft

179
00:06:35,040 --> 00:06:37,040
is bringing the workflows app-style experience

180
00:06:37,040 --> 00:06:40,040
into SharePoint, templates, and a build from scratch path,

181
00:06:40,040 --> 00:06:42,680
directly in the context of a list or library.

182
00:06:42,680 --> 00:06:45,120
The selling point is that connections are pre-configured.

183
00:06:45,120 --> 00:06:47,760
It already knows where you are, what the list is,

184
00:06:47,760 --> 00:06:48,920
what the trigger should be.

185
00:06:48,920 --> 00:06:51,640
So makers don't have to do the sign-in, pick-side,

186
00:06:51,640 --> 00:06:54,320
pick-library dance that convenience is not cosmetic.

187
00:06:54,320 --> 00:06:55,840
It's an acceleration mechanism.

188
00:06:55,840 --> 00:06:57,440
More people can build automations.

189
00:06:57,440 --> 00:06:58,800
More automations will exist.

190
00:06:58,800 --> 00:07:01,000
And more of them will be created by the people

191
00:07:01,000 --> 00:07:03,880
least equipped to think about blast radius, error handling,

192
00:07:03,880 --> 00:07:04,880
and long-term ownership.

193
00:07:04,880 --> 00:07:06,400
That's not a criticism of makers.

194
00:07:06,400 --> 00:07:09,080
That's the predictable outcome of lowering the barrier.

195
00:07:09,080 --> 00:07:11,000
Also, the templates are Microsoft provided,

196
00:07:11,000 --> 00:07:13,280
and you can't necessarily modify the internal structure

197
00:07:13,280 --> 00:07:13,880
of a template.

198
00:07:13,880 --> 00:07:14,520
So what happens?

199
00:07:14,520 --> 00:07:16,920
People start from scratch when the template doesn't fit.

200
00:07:16,920 --> 00:07:19,560
And start from scratch is where abstraction ends

201
00:07:19,560 --> 00:07:21,720
and flow complexity begins.

202
00:07:21,720 --> 00:07:25,600
Loops, parallel branches, throttling, connector limits,

203
00:07:25,600 --> 00:07:27,920
and those quiet failures nobody notices

204
00:07:27,920 --> 00:07:31,320
until finance asks why invoices didn't move for three days.

205
00:07:31,320 --> 00:07:32,720
Now, the agent layer.

206
00:07:32,720 --> 00:07:35,840
Every SharePoint site effectively gains

207
00:07:35,840 --> 00:07:37,640
an agent-shaped interface,

208
00:07:37,640 --> 00:07:39,360
a site-specific knowledge surface

209
00:07:39,360 --> 00:07:43,040
that can answer questions grounded in what the user can access.

210
00:07:43,040 --> 00:07:44,440
Then you get higher-order patterns,

211
00:07:44,440 --> 00:07:47,000
a knowledge agent that helps curate, tag, and structure

212
00:07:47,000 --> 00:07:49,760
content, and an admin agent that watches for oversharing

213
00:07:49,760 --> 00:07:51,720
inactive sites and permissions brawl.

214
00:07:51,720 --> 00:07:53,600
Agents are not the automation engine.

215
00:07:53,600 --> 00:07:55,560
They are the front door to the automation engine.

216
00:07:55,560 --> 00:07:58,200
They turn, "I need to do a thing into a guided action

217
00:07:58,200 --> 00:08:00,560
or a triggered workflow or a routed approval,"

218
00:08:00,560 --> 00:08:03,000
which is great until you treat them as the back end.

219
00:08:03,000 --> 00:08:03,520
Don't.

220
00:08:03,520 --> 00:08:04,880
The agent is where humans ask.

221
00:08:04,880 --> 00:08:07,720
Deterministic orchestration is where the enterprise executes.

222
00:08:07,720 --> 00:08:11,040
So the modern stack is coherent if you see it as one pipeline.

223
00:08:11,040 --> 00:08:13,680
Quick steps and workflows provide the user's handholds,

224
00:08:13,680 --> 00:08:16,480
approvals provide lightweight state, power automate,

225
00:08:16,480 --> 00:08:18,400
and as you provide execution,

226
00:08:18,400 --> 00:08:20,800
and agents provide the conversational wrapper.

227
00:08:20,800 --> 00:08:22,160
And when you standardize that model,

228
00:08:22,160 --> 00:08:24,000
the feature list stops being exciting.

229
00:08:24,000 --> 00:08:25,200
It becomes governable.

230
00:08:25,200 --> 00:08:27,520
Conceptual flow for scale, event, reasoning,

231
00:08:27,520 --> 00:08:28,880
orchestration, enforcement.

232
00:08:28,880 --> 00:08:30,840
Scale starts with a boring question.

233
00:08:30,840 --> 00:08:32,280
What exactly happened?

234
00:08:32,280 --> 00:08:33,960
Not what did the user want?

235
00:08:33,960 --> 00:08:36,320
Not what does the business process say?

236
00:08:36,320 --> 00:08:37,880
What happened in the system that you can point

237
00:08:37,880 --> 00:08:39,400
to, subscribe to, and replay?

238
00:08:39,400 --> 00:08:41,560
That's the event.

239
00:08:41,560 --> 00:08:45,200
In SharePoint land, events come from a few predictable places.

240
00:08:45,200 --> 00:08:49,000
A file was created, updated, moved, or deleted.

241
00:08:49,000 --> 00:08:52,080
Metadata changed, an approval state changed,

242
00:08:52,080 --> 00:08:55,040
a sharing link was created, permissions changed,

243
00:08:55,040 --> 00:08:58,080
a page was published, a list item changed.

244
00:08:58,080 --> 00:09:00,360
The UI hides that these are all distinct signals

245
00:09:00,360 --> 00:09:02,520
with different reliability characteristics.

246
00:09:02,520 --> 00:09:05,360
Some are clean and transactional, some are noisy.

247
00:09:05,360 --> 00:09:07,080
Some fire more often than you think

248
00:09:07,080 --> 00:09:09,320
because auto-save and metadata normalization

249
00:09:09,320 --> 00:09:10,320
count as updates.

250
00:09:10,320 --> 00:09:12,800
But if you treat every update as the business event,

251
00:09:12,800 --> 00:09:15,680
you build a denial of service attack against your own automation.

252
00:09:15,680 --> 00:09:19,280
So the first scaling law is decide what event you actually care about,

253
00:09:19,280 --> 00:09:21,040
then make it stable, for example.

254
00:09:21,040 --> 00:09:23,120
File created is usually stable.

255
00:09:23,120 --> 00:09:25,960
File modified is chaos, unless you constrain it

256
00:09:25,960 --> 00:09:28,880
with conditions like status change from draft to submitted

257
00:09:28,880 --> 00:09:30,840
or approval status changed.

258
00:09:30,840 --> 00:09:32,680
Metadata transitions are your friend

259
00:09:32,680 --> 00:09:35,360
because they represent intent, not activity.

260
00:09:35,360 --> 00:09:36,880
The event is the edge of your system.

261
00:09:36,880 --> 00:09:40,320
If the edge is fuzzy, everything behind it becomes expensive.

262
00:09:40,320 --> 00:09:41,920
Next comes reasoning.

263
00:09:41,920 --> 00:09:44,120
Re reasoning is where most flows quietly rot

264
00:09:44,120 --> 00:09:46,920
because makers mix decisions and actions into one blob.

265
00:09:46,920 --> 00:09:48,880
They check metadata, look up a user,

266
00:09:48,880 --> 00:09:52,080
branch three times, send two approvals, and then move content.

267
00:09:52,080 --> 00:09:53,480
It works until it doesn't.

268
00:09:53,480 --> 00:09:56,280
And then nobody can tell whether the failure came from bad input,

269
00:09:56,280 --> 00:09:58,680
bad policy, or a transient connector issue.

270
00:09:58,680 --> 00:10:01,560
Re reasoning should be treated like a policy evaluation step.

271
00:10:01,560 --> 00:10:04,600
Interpret metadata, validate required fields,

272
00:10:04,600 --> 00:10:07,720
map the item to a classification, decide routing,

273
00:10:07,720 --> 00:10:09,960
and decide whether the action is allowed.

274
00:10:09,960 --> 00:10:12,920
This can be simple rules like if department equals finance,

275
00:10:12,920 --> 00:10:15,800
root to finance approvals, or more advanced checks

276
00:10:15,800 --> 00:10:19,800
like if label is confidential block external share requests.

277
00:10:19,800 --> 00:10:22,400
If you're using agents, this is also where you cage them.

278
00:10:22,400 --> 00:10:25,160
The agent can suggest but the reasoning layer decides.

279
00:10:25,160 --> 00:10:26,080
Here's the weird part.

280
00:10:26,080 --> 00:10:28,360
Re reasoning doesn't have to run where execution runs.

281
00:10:28,360 --> 00:10:30,320
Re reasoning can run in a controlled service

282
00:10:30,320 --> 00:10:31,880
with a version rule set.

283
00:10:31,880 --> 00:10:33,040
It can run in a function.

284
00:10:33,040 --> 00:10:34,520
It can even run in a flow.

285
00:10:34,520 --> 00:10:35,640
But it has to be separable.

286
00:10:35,640 --> 00:10:37,480
You want to be able to test it, change it,

287
00:10:37,480 --> 00:10:39,520
and audit it without rewriting the whole workflow.

288
00:10:39,520 --> 00:10:42,200
In other words, separate decision from execution.

289
00:10:42,200 --> 00:10:43,200
Then comes orchestration.

290
00:10:43,200 --> 00:10:45,440
Orchestration is not run these steps.

291
00:10:45,440 --> 00:10:48,040
Orchestration is coordinate work that might fail,

292
00:10:48,040 --> 00:10:50,760
might take time, and might run more than once.

293
00:10:50,760 --> 00:10:52,640
At enterprise volume, every workflow

294
00:10:52,640 --> 00:10:56,120
becomes distributed systems work, whether you admit it or not.

295
00:10:56,120 --> 00:10:58,320
You need fan-out because one event can trigger

296
00:10:58,320 --> 00:10:59,760
multiple downstream actions.

297
00:10:59,760 --> 00:11:03,480
Notify teams, update a list, set a label, create a task,

298
00:11:03,480 --> 00:11:04,480
call an API.

299
00:11:04,480 --> 00:11:06,520
You need async because long-running approvals

300
00:11:06,520 --> 00:11:08,600
and content conversions don't fit neatly

301
00:11:08,600 --> 00:11:10,440
into a single synchronous run.

302
00:11:10,440 --> 00:11:13,200
You need queues because SharePoint and Graph will throttle you,

303
00:11:13,200 --> 00:11:15,680
and Power Automate will hit concurrency reality.

304
00:11:15,680 --> 00:11:17,520
You need retreatries because transient failures

305
00:11:17,520 --> 00:11:18,920
are not bugs, they're physics.

306
00:11:18,920 --> 00:11:21,520
And you need identity because duplicates will happen.

307
00:11:21,520 --> 00:11:25,080
Users re-upload, events refire, flows get retried,

308
00:11:25,080 --> 00:11:26,760
subscriptions get revalidated.

309
00:11:26,760 --> 00:11:29,320
Ident potency is the difference between we retried

310
00:11:29,320 --> 00:11:31,040
and we duplicated the project site

311
00:11:31,040 --> 00:11:32,720
and nobody noticed until billing.

312
00:11:32,720 --> 00:11:35,520
So orchestration at scale looks like this.

313
00:11:35,520 --> 00:11:38,440
Receive the event, stamp it with an identity key,

314
00:11:38,440 --> 00:11:40,440
in queue work, process it with workers

315
00:11:40,440 --> 00:11:43,200
that can retry safely, and record state transitions

316
00:11:43,200 --> 00:11:45,240
somewhere that isn't someone's memory.

317
00:11:45,240 --> 00:11:46,680
Power Automate can do some of that.

318
00:11:46,680 --> 00:11:48,680
Logic apps and functions do it more predictably.

319
00:11:48,680 --> 00:11:50,520
Either way, the architecture has to acknowledge

320
00:11:50,520 --> 00:11:52,480
that the happy path is not the common path.

321
00:11:52,480 --> 00:11:54,600
Finally, enforcement.

322
00:11:54,600 --> 00:11:57,320
Enforcement is where governance stops being a PDF

323
00:11:57,320 --> 00:11:58,920
and becomes runtime behavior.

324
00:11:58,920 --> 00:12:02,120
Set or validate permissions, apply sensitivity labels,

325
00:12:02,120 --> 00:12:05,280
enforce retention, evaluate DLP, log actions,

326
00:12:05,280 --> 00:12:06,640
and emit audit evidence.

327
00:12:06,640 --> 00:12:07,960
This is where you close the loop

328
00:12:07,960 --> 00:12:10,360
between we decided and the system did.

329
00:12:10,360 --> 00:12:12,560
Enforcement also means writing back to SharePoint

330
00:12:12,560 --> 00:12:15,000
in a way that keeps the item as the source of truth.

331
00:12:15,000 --> 00:12:17,240
Update metadata to reflect the outcome.

332
00:12:17,240 --> 00:12:19,240
Store the approval state with the document,

333
00:12:19,240 --> 00:12:21,320
record who approved, and ensure the label

334
00:12:21,320 --> 00:12:23,480
and sharing posture match the policy.

335
00:12:23,480 --> 00:12:25,480
If your enforcement happens only in email

336
00:12:25,480 --> 00:12:27,880
or team's notifications, you've built theater.

337
00:12:27,880 --> 00:12:29,320
Auditors don't accept theater,

338
00:12:29,320 --> 00:12:32,720
so the scalable model is deterministic, event triggers.

339
00:12:32,720 --> 00:12:34,840
Reasoning decides orchestration coordinates

340
00:12:34,840 --> 00:12:36,040
enforcement makes it real,

341
00:12:36,040 --> 00:12:37,280
and if any one of those is missing,

342
00:12:37,280 --> 00:12:39,640
you don't get a slightly weaker automation.

343
00:12:39,640 --> 00:12:40,960
You get drift.

344
00:12:40,960 --> 00:12:43,240
And drift always wins until you design the system,

345
00:12:43,240 --> 00:12:44,640
so it can't.

346
00:12:44,640 --> 00:12:47,320
Tooling decision matrix, what to standardize,

347
00:12:47,320 --> 00:12:48,440
what to forbid.

348
00:12:48,440 --> 00:12:50,760
Now you pick tools, and this is where most enterprises

349
00:12:50,760 --> 00:12:52,880
sabotage themselves, because they turn a platform

350
00:12:52,880 --> 00:12:55,160
into a personal preference contest.

351
00:12:55,160 --> 00:12:56,200
What do you like more?

352
00:12:56,200 --> 00:12:58,000
Power Automate or Logic Apps?

353
00:12:58,000 --> 00:12:58,960
Is the wrong question?

354
00:12:58,960 --> 00:13:01,360
The right question is, what class of work is this

355
00:13:01,360 --> 00:13:03,400
and what failure modes are acceptable?

356
00:13:03,400 --> 00:13:06,080
Because every automation tool is a bundle of trade-offs.

357
00:13:06,080 --> 00:13:10,040
Throughput, latency, auditability, deployment control,

358
00:13:10,040 --> 00:13:11,360
and who's allowed to touch it.

359
00:13:11,360 --> 00:13:13,680
Start with Power Automate Cloud Flows.

360
00:13:13,680 --> 00:13:16,440
Power Automate is the default for business automation

361
00:13:16,440 --> 00:13:19,760
because it's close to the user and rich in connectors.

362
00:13:19,760 --> 00:13:22,000
It's also where simple becomes fragile.

363
00:13:22,000 --> 00:13:23,760
The moment you cross from a team's workload

364
00:13:23,760 --> 00:13:26,480
into an enterprise workload, concurrency limits,

365
00:13:26,480 --> 00:13:29,400
connector throttling, long-running approval behavior,

366
00:13:29,400 --> 00:13:31,000
and run history retention realities

367
00:13:31,000 --> 00:13:32,040
don't show up in the demo.

368
00:13:32,040 --> 00:13:33,800
They show up when you have 10,000 items

369
00:13:33,800 --> 00:13:35,320
in a Monday morning spike.

370
00:13:35,320 --> 00:13:37,240
So the standardization rule is strict.

371
00:13:37,240 --> 00:13:39,680
Use Power Automate for human-centric workflows

372
00:13:39,680 --> 00:13:41,720
with bounded volume and clear ownership.

373
00:13:41,720 --> 00:13:45,120
Notifications, approvals, basic metadata updates,

374
00:13:45,120 --> 00:13:48,160
small fan-out, anything that benefits from being maintained

375
00:13:48,160 --> 00:13:50,320
by a maker community under governance.

376
00:13:50,320 --> 00:13:52,120
And the forbid list is equally strict.

377
00:13:52,120 --> 00:13:54,080
Don't use Power Automate as the backbone

378
00:13:54,080 --> 00:13:57,720
for high-volume event processing, bulk content transformations,

379
00:13:57,720 --> 00:14:01,440
or anything that must run like a service with predictable throughput.

380
00:14:01,440 --> 00:14:04,640
Also, forbid personal flows as production dependencies.

381
00:14:04,640 --> 00:14:08,000
A workflow that matters can't be owned by whoever built it first.

382
00:14:08,000 --> 00:14:10,280
Next, Webhooks Plus Microsoft Graph.

383
00:14:10,280 --> 00:14:11,680
This is the event-driven backbone

384
00:14:11,680 --> 00:14:13,680
when you care about scale and latency.

385
00:14:13,680 --> 00:14:15,960
Graph subscriptions and change notifications

386
00:14:15,960 --> 00:14:18,760
give you a clean, something change signal without polling,

387
00:14:18,760 --> 00:14:21,280
and you can root those signals into real compute.

388
00:14:21,280 --> 00:14:23,960
The upside is obvious, low latency, high volume,

389
00:14:23,960 --> 00:14:26,280
and architecture that looks like an actual system

390
00:14:26,280 --> 00:14:28,160
instead of a collection of runs.

391
00:14:28,160 --> 00:14:29,320
The downside is also obvious.

392
00:14:29,320 --> 00:14:32,560
You now own code, hosting, authentication, and life cycle,

393
00:14:32,560 --> 00:14:33,360
which is fine.

394
00:14:33,360 --> 00:14:34,600
Enterprises already own code.

395
00:14:34,600 --> 00:14:37,160
They just pretend they don't when they call it low code.

396
00:14:37,160 --> 00:14:40,320
So the standard here is use Webhooks and Graph

397
00:14:40,320 --> 00:14:42,840
when the event rate is high, when seconds matter,

398
00:14:42,840 --> 00:14:46,000
or when you need central control over triggering behavior.

399
00:14:46,000 --> 00:14:47,880
And forbid the anti-pattern where each department

400
00:14:47,880 --> 00:14:51,080
builds their own Graph listener, one listener per class of event,

401
00:14:51,080 --> 00:14:53,240
one pipeline, central ownership.

402
00:14:53,240 --> 00:14:54,880
Otherwise, you're back to sprawl,

403
00:14:54,880 --> 00:14:56,520
just with prettier engineering.

404
00:14:56,520 --> 00:14:58,600
Then, as your functions versus logic apps,

405
00:14:58,600 --> 00:15:01,480
this is the compute first versus workflow first divide.

406
00:15:01,480 --> 00:15:04,200
Functions are for code that needs to execute fast,

407
00:15:04,200 --> 00:15:06,920
scale out aggressively, and be tested like software.

408
00:15:06,920 --> 00:15:08,480
Logic apps are for orchestration

409
00:15:08,480 --> 00:15:11,040
that needs connectors, durable state, built in retries,

410
00:15:11,040 --> 00:15:13,560
and operational visibility with less custom plumbing.

411
00:15:13,560 --> 00:15:16,120
In enterprise terms, functions are the sharp tool.

412
00:15:16,120 --> 00:15:17,800
Logic apps are the safer tool.

413
00:15:17,800 --> 00:15:20,120
Use functions for custom provisioning logic,

414
00:15:20,120 --> 00:15:22,360
transformations, complex validation,

415
00:15:22,360 --> 00:15:24,440
and anything where you want versioned code,

416
00:15:24,440 --> 00:15:26,720
unit tests, and predictable performance.

417
00:15:26,720 --> 00:15:29,160
Use logic apps when you need durable orchestration

418
00:15:29,160 --> 00:15:30,240
across systems.

419
00:15:30,240 --> 00:15:33,320
Cues, retries, exception handling, long running processes,

420
00:15:33,320 --> 00:15:36,880
and integrations that benefit from a designed workflow graph.

421
00:15:36,880 --> 00:15:38,200
And here's what you forbid.

422
00:15:38,200 --> 00:15:41,600
Don't let functions versus logic apps become a religion.

423
00:15:41,600 --> 00:15:43,440
Standardize by workload.

424
00:15:43,440 --> 00:15:46,280
If you need a durable workflow with multiple systems,

425
00:15:46,280 --> 00:15:47,680
logic apps is the default.

426
00:15:47,680 --> 00:15:49,960
If you need custom compute that's not a workflow,

427
00:15:49,960 --> 00:15:51,160
functions is the default.

428
00:15:51,160 --> 00:15:54,240
Mixing them is allowed only when the architecture forces it,

429
00:15:54,240 --> 00:15:56,120
not because someone likes writing JSON

430
00:15:56,120 --> 00:15:57,480
less than writing cperts.

431
00:15:57,480 --> 00:15:59,440
Now, co-pilot studio and agents, agents

432
00:15:59,440 --> 00:16:01,040
are the conversational entry points.

433
00:16:01,040 --> 00:16:02,760
They are not the execution substrate.

434
00:16:02,760 --> 00:16:05,000
They're great at intake, triage, summarization,

435
00:16:05,000 --> 00:16:06,240
and guided actions.

436
00:16:06,240 --> 00:16:07,560
They can trigger workflows.

437
00:16:07,560 --> 00:16:09,360
They can help users find the right process.

438
00:16:09,360 --> 00:16:10,800
They can even generate drafts,

439
00:16:10,800 --> 00:16:12,760
but they cannot be your compliance pipeline

440
00:16:12,760 --> 00:16:14,040
because probabilistic reasoning

441
00:16:14,040 --> 00:16:15,560
can't be your last line of defense.

442
00:16:15,560 --> 00:16:18,560
So the standard is agents for interface and assistance,

443
00:16:18,560 --> 00:16:20,320
deterministic services for enforcement

444
00:16:20,320 --> 00:16:21,960
and high throughput execution.

445
00:16:21,960 --> 00:16:23,400
And the forbid list is simple.

446
00:16:23,400 --> 00:16:25,480
Don't let agents write to authoritative systems

447
00:16:25,480 --> 00:16:27,120
without a governed orchestration layer

448
00:16:27,120 --> 00:16:28,480
and a hard permission model.

449
00:16:28,480 --> 00:16:30,120
Agents should request actions.

450
00:16:30,120 --> 00:16:31,640
Orchestration should perform actions.

451
00:16:31,640 --> 00:16:33,400
Enforcement should validate outcomes.

452
00:16:33,400 --> 00:16:36,240
Now put it all into one rule that leaders can actually enforce,

453
00:16:36,240 --> 00:16:37,960
one path for each class of work.

454
00:16:37,960 --> 00:16:40,480
Simple team automation goes through power automate,

455
00:16:40,480 --> 00:16:42,720
governed by environments and ownership rules.

456
00:16:42,720 --> 00:16:44,600
High volume eventing goes through graph

457
00:16:44,600 --> 00:16:46,400
and a centralized event pipeline.

458
00:16:46,400 --> 00:16:49,760
Cross system and long running orchestration goes through logic apps,

459
00:16:49,760 --> 00:16:51,680
custom compute goes through functions.

460
00:16:51,680 --> 00:16:54,600
Agents sit on top as the intake and guidance layer.

461
00:16:54,600 --> 00:16:57,040
No choose your own stack because at scale,

462
00:16:57,040 --> 00:17:00,120
choice is just a polite word for architectural erosion.

463
00:17:00,120 --> 00:17:01,440
And once that matrix is clear,

464
00:17:01,440 --> 00:17:03,480
you can finally talk about governance.

465
00:17:03,480 --> 00:17:04,760
Not as documentation,

466
00:17:04,760 --> 00:17:07,160
but as mechanisms that make the matrix real.

467
00:17:07,160 --> 00:17:08,840
Governance isn't policy docs.

468
00:17:08,840 --> 00:17:10,560
It's enforcement mechanisms.

469
00:17:10,560 --> 00:17:13,120
Most organizations think governance is a document,

470
00:17:13,120 --> 00:17:15,760
a site creation policy, a naming standard,

471
00:17:15,760 --> 00:17:17,720
a don't share PII slide deck,

472
00:17:17,720 --> 00:17:19,560
and a monthly meeting where everyone agrees

473
00:17:19,560 --> 00:17:20,920
the situation is bad.

474
00:17:20,920 --> 00:17:22,440
That is not governance.

475
00:17:22,440 --> 00:17:24,920
Governance is what remains true after a smart,

476
00:17:24,920 --> 00:17:26,640
busy person finds a shortcut.

477
00:17:26,640 --> 00:17:27,880
So the definition has to change.

478
00:17:27,880 --> 00:17:30,000
Governance is the set of enforcement mechanisms

479
00:17:30,000 --> 00:17:32,200
that survive human creativity at scale.

480
00:17:32,200 --> 00:17:34,320
If a control can be bypassed by convenience,

481
00:17:34,320 --> 00:17:35,320
it's not a control.

482
00:17:35,320 --> 00:17:36,440
It's a suggestion.

483
00:17:36,440 --> 00:17:38,840
And suggestions don't withstand share point automation

484
00:17:38,840 --> 00:17:41,640
because automation amplifies whatever behavior already exists.

485
00:17:41,640 --> 00:17:43,400
It takes the informal workaround

486
00:17:43,400 --> 00:17:45,440
and turns it into a repeatable button.

487
00:17:45,440 --> 00:17:46,960
This is the uncomfortable truth.

488
00:17:46,960 --> 00:17:48,640
Makers don't break governance.

489
00:17:48,640 --> 00:17:50,880
Systems without enforcement never had governance.

490
00:17:50,880 --> 00:17:52,520
So what does enforcement look like

491
00:17:52,520 --> 00:17:54,240
in modern share point automation?

492
00:17:54,240 --> 00:17:57,360
It starts with control surfaces, not best practices.

493
00:17:57,360 --> 00:18:00,200
Actual levers that change what the platform allows.

494
00:18:00,200 --> 00:18:02,960
Microsoft purview for labels, retention and DLP,

495
00:18:02,960 --> 00:18:04,360
entrafore identity boundaries,

496
00:18:04,360 --> 00:18:07,240
guest policy, conditional access and role separation.

497
00:18:07,240 --> 00:18:09,480
Share point admin controls for sharing defaults,

498
00:18:09,480 --> 00:18:12,160
site creation constraints and lifecycle settings,

499
00:18:12,160 --> 00:18:14,960
power platform admin controls for environments,

500
00:18:14,960 --> 00:18:18,840
DLP across connectors and who can create what?

501
00:18:18,840 --> 00:18:21,040
Each of those is a different plane of control.

502
00:18:21,040 --> 00:18:22,480
And if you don't connect them,

503
00:18:22,480 --> 00:18:25,360
you create gaps that automation happily drives through.

504
00:18:25,360 --> 00:18:27,880
For example, you can have a beautiful DLP policy,

505
00:18:27,880 --> 00:18:29,920
but if anyone can build a flow

506
00:18:29,920 --> 00:18:32,080
in an unmanaged environment that moves content

507
00:18:32,080 --> 00:18:35,000
from a labeled library to an ungoverned connector,

508
00:18:35,000 --> 00:18:37,320
you've built a compliance bypass with a UI.

509
00:18:37,320 --> 00:18:39,920
Or you can lock down external sharing at the tenant level,

510
00:18:39,920 --> 00:18:41,840
but if you don't control guest lifecycle

511
00:18:41,840 --> 00:18:43,320
and sponsorship in entra,

512
00:18:43,320 --> 00:18:45,440
you just turned external collaboration

513
00:18:45,440 --> 00:18:47,640
into permanent external presence.

514
00:18:47,640 --> 00:18:48,880
Or you can define retention,

515
00:18:48,880 --> 00:18:51,920
but if nobody enforces labels at creation time,

516
00:18:51,920 --> 00:18:54,800
you've outsourced compliance to user attention span,

517
00:18:54,800 --> 00:18:57,800
then comes the drift model because drift is not a risk,

518
00:18:57,800 --> 00:18:59,760
drift is the default operating mode.

519
00:18:59,760 --> 00:19:02,880
Every exception you approve becomes an entropy generator.

520
00:19:02,880 --> 00:19:05,000
This site needs external sharing.

521
00:19:05,000 --> 00:19:07,160
That flow needs a premium connector.

522
00:19:07,160 --> 00:19:09,440
This library needs unique permissions.

523
00:19:09,440 --> 00:19:12,120
This department needs a custom approval path.

524
00:19:12,120 --> 00:19:13,280
Each one sounds reasonable.

525
00:19:13,280 --> 00:19:15,120
Over time, they accumulate into a system

526
00:19:15,120 --> 00:19:16,520
nobody can reason about.

527
00:19:16,520 --> 00:19:18,400
Missing policies create obvious gaps.

528
00:19:18,400 --> 00:19:20,280
Drifting policies create ambiguity.

529
00:19:20,280 --> 00:19:22,000
Ambiguity creates incident time.

530
00:19:22,000 --> 00:19:25,000
So the governance job is not to eliminate exceptions.

531
00:19:25,000 --> 00:19:27,840
It's to make exceptions expensive, visible, time-bound,

532
00:19:27,840 --> 00:19:28,880
and reviewable.

533
00:19:28,880 --> 00:19:30,680
That means time-limited access,

534
00:19:30,680 --> 00:19:33,120
expiring sharing links, scheduled access reviews,

535
00:19:33,120 --> 00:19:35,720
environment-based restrictions, mandatory ownership

536
00:19:35,720 --> 00:19:38,280
metadata, automated lifecycle policies.

537
00:19:38,280 --> 00:19:40,200
Telemetry that proves what changed,

538
00:19:40,200 --> 00:19:42,000
when and under which identity.

539
00:19:42,000 --> 00:19:42,960
That last part matters.

540
00:19:42,960 --> 00:19:45,040
Identity is the enforcement perimeter,

541
00:19:45,040 --> 00:19:47,200
but telemetry is the governance perimeter.

542
00:19:47,200 --> 00:19:49,400
Because if you can't see sprawl, you can't manage it.

543
00:19:49,400 --> 00:19:52,760
So governance needs KPIs that measure entropy, not vanity.

544
00:19:52,760 --> 00:19:54,920
The KPI view is brutal and simple.

545
00:19:54,920 --> 00:19:58,040
sprawl rate, how fast sites, teams, and flows appear

546
00:19:58,040 --> 00:20:00,680
compared to the organization's ability to govern them.

547
00:20:00,680 --> 00:20:03,800
Permission drift, how often inheritance breaks,

548
00:20:03,800 --> 00:20:07,760
direct assignments appear, or guests accumulate without a sponsor.

549
00:20:07,760 --> 00:20:10,800
DLP incidents, not just counts, but where they concentrate

550
00:20:10,800 --> 00:20:13,280
and which labels or locations correlate.

551
00:20:13,280 --> 00:20:16,760
Automation failure rate, retries, time-outs, runs that fail

552
00:20:16,760 --> 00:20:20,840
silently, and workflows with no owner who receives failure alerts.

553
00:20:20,840 --> 00:20:22,920
Those are the signals that tell you whether the control

554
00:20:22,920 --> 00:20:26,040
plane is working or whether you're running a distributed accident.

555
00:20:26,040 --> 00:20:27,160
Now notice what's missing.

556
00:20:27,160 --> 00:20:28,320
Number of policies.

557
00:20:28,320 --> 00:20:30,480
Number of pages in the governance guide.

558
00:20:30,480 --> 00:20:31,760
Number of training sessions.

559
00:20:31,760 --> 00:20:34,080
Those measure activity, not enforcement.

560
00:20:34,080 --> 00:20:37,120
So the practical architecture principle here is governance

561
00:20:37,120 --> 00:20:40,160
must be deployable and testable, like any other system.

562
00:20:40,160 --> 00:20:42,960
Controls need versioning, exceptions need life cycle,

563
00:20:42,960 --> 00:20:45,040
environments need boundaries, and workflows

564
00:20:45,040 --> 00:20:46,440
need operational ownership.

565
00:20:46,440 --> 00:20:48,040
This is also why governance committees

566
00:20:48,040 --> 00:20:50,080
fail when they try to approve everything.

567
00:20:50,080 --> 00:20:53,000
They become a human bottleneck for machine speed change.

568
00:20:53,000 --> 00:20:54,760
The system learns to route around them

569
00:20:54,760 --> 00:20:56,560
because business pressure doesn't stop.

570
00:20:56,560 --> 00:20:59,080
So governance has to move from approval of everything

571
00:20:59,080 --> 00:21:00,600
to standardization of the paths.

572
00:21:00,600 --> 00:21:03,400
And the only way that works is start with identity,

573
00:21:03,400 --> 00:21:05,960
because identity is where automation gets its permissions,

574
00:21:05,960 --> 00:21:09,640
where agents inherit access, where service principles do the writing,

575
00:21:09,640 --> 00:21:12,600
and where guests become either controlled collaborators

576
00:21:12,600 --> 00:21:14,720
or an ongoing liability.

577
00:21:14,720 --> 00:21:17,960
If you get identity wrong, every other governance layer becomes cleanup.

578
00:21:17,960 --> 00:21:21,520
So the next section goes where most organizations avoid going

579
00:21:21,520 --> 00:21:23,760
until after their first major incident.

580
00:21:23,760 --> 00:21:27,920
EntraFirst Design, the group model that prevents permission fanfiction.

581
00:21:27,920 --> 00:21:29,880
EntraFirst Design, the group model that

582
00:21:29,880 --> 00:21:31,560
prevents permission fanfiction.

583
00:21:31,560 --> 00:21:34,560
EntraFirst Design is not identity hygiene.

584
00:21:34,560 --> 00:21:36,440
It's the only way SharePoint automation stays

585
00:21:36,440 --> 00:21:38,840
governable once it spreads beyond one team.

586
00:21:38,840 --> 00:21:40,120
The core law is simple.

587
00:21:40,120 --> 00:21:42,000
Every permission that isn't expressed as a group

588
00:21:42,000 --> 00:21:44,440
becomes a story someone tells themselves later.

589
00:21:44,440 --> 00:21:44,960
It's fine.

590
00:21:44,960 --> 00:21:46,440
I just added Sarah directly.

591
00:21:46,440 --> 00:21:47,000
It's fine.

592
00:21:47,000 --> 00:21:49,160
I just broke inheritance on this folder.

593
00:21:49,160 --> 00:21:49,640
It's fine.

594
00:21:49,640 --> 00:21:50,720
It's only a guest.

595
00:21:50,720 --> 00:21:52,360
Those decisions don't stay small.

596
00:21:52,360 --> 00:21:54,600
Automation reads them as truth and amplifies them.

597
00:21:54,600 --> 00:21:56,880
So the scaling model is group first access.

598
00:21:56,880 --> 00:22:00,080
No direct user assignment as a rule, not a preference.

599
00:22:00,080 --> 00:22:02,160
Owners and members map to Entra groups.

600
00:22:02,160 --> 00:22:04,120
Special roles map to separate groups.

601
00:22:04,120 --> 00:22:05,760
Exceptions map to time bound groups.

602
00:22:05,760 --> 00:22:09,480
That's it because a SharePoint permission set is not a security model.

603
00:22:09,480 --> 00:22:12,520
It's an implementation detail of an authorization graph.

604
00:22:12,520 --> 00:22:14,280
Entra is where you define the graph.

605
00:22:14,280 --> 00:22:16,480
SharePoint is where you attach it to content.

606
00:22:16,480 --> 00:22:17,800
Here's what most people miss.

607
00:22:17,800 --> 00:22:21,400
Automation identities need the same discipline as human identities.

608
00:22:21,400 --> 00:22:24,040
If a flow runs as the owner because it was built

609
00:22:24,040 --> 00:22:26,560
by an enthusiastic site owner six months ago,

610
00:22:26,560 --> 00:22:28,800
then the organization has created a ghost admin

611
00:22:28,800 --> 00:22:30,840
that never rotates, never goes on leave,

612
00:22:30,840 --> 00:22:32,320
and never gets reviewed.

613
00:22:32,320 --> 00:22:36,440
The workflow becomes a permanent privilege escalation path disguised as productivity.

614
00:22:36,440 --> 00:22:38,720
So you formalize automation identities.

615
00:22:38,720 --> 00:22:42,280
Service principles and managed identities are first class citizens.

616
00:22:42,280 --> 00:22:43,400
They get explicit scopes.

617
00:22:43,400 --> 00:22:44,520
They get named ownership.

618
00:22:44,520 --> 00:22:45,440
They get life cycle.

619
00:22:45,440 --> 00:22:46,960
They don't inherit random permissions

620
00:22:46,960 --> 00:22:49,360
because someone clicked use my connection.

621
00:22:49,360 --> 00:22:52,040
And they do not sit in the same groups as humans.

622
00:22:52,040 --> 00:22:56,040
Mixing human access and automation access is how incident reports get written.

623
00:22:56,040 --> 00:22:59,880
Now add role separation SharePoint admins, power platform admins

624
00:22:59,880 --> 00:23:01,840
and automation builders are not interchangeable

625
00:23:01,840 --> 00:23:04,480
just because one person can technically do all three.

626
00:23:04,480 --> 00:23:06,680
In Entra terms, you use role separation

627
00:23:06,680 --> 00:23:08,360
and privilege identity management.

628
00:23:08,360 --> 00:23:10,760
So that privileged access is just in time,

629
00:23:10,760 --> 00:23:12,320
time limited and auditable.

630
00:23:12,320 --> 00:23:15,000
Permanent privilege is not an operational convenience.

631
00:23:15,000 --> 00:23:16,640
It is security debt.

632
00:23:16,640 --> 00:23:20,480
PIM is how you keep admin rights from becoming the default state

633
00:23:20,480 --> 00:23:22,440
and it matters more with automation

634
00:23:22,440 --> 00:23:25,000
because the people who can create automations

635
00:23:25,000 --> 00:23:28,040
often become the people who can bypass controls.

636
00:23:28,040 --> 00:23:30,240
If the builder can also grant themselves access,

637
00:23:30,240 --> 00:23:32,640
you don't have governance, you have self-service escalation.

638
00:23:32,640 --> 00:23:34,680
Now the group model itself, a practical pattern

639
00:23:34,680 --> 00:23:37,000
that doesn't collapse under pressure looks like this.

640
00:23:37,000 --> 00:23:38,880
One group for owners, one group for members,

641
00:23:38,880 --> 00:23:41,000
one group for visitors and then additional groups

642
00:23:41,000 --> 00:23:45,040
for specific entitlements that are independent of site membership.

643
00:23:45,040 --> 00:23:46,520
Approvers should be a group.

644
00:23:46,520 --> 00:23:48,640
External collaborators should be a group.

645
00:23:48,640 --> 00:23:50,440
Workflow runners should be a group.

646
00:23:50,440 --> 00:23:53,080
And if a library has a unique permission boundary,

647
00:23:53,080 --> 00:23:55,760
that boundary is expressed as separate groups,

648
00:23:55,760 --> 00:23:57,200
not a list of named people.

649
00:23:57,200 --> 00:23:59,600
This is how you prevent permission fan fiction.

650
00:23:59,600 --> 00:24:01,360
Permissions stop being bespoke narratives

651
00:24:01,360 --> 00:24:02,840
and become reusable components.

652
00:24:02,840 --> 00:24:04,360
It also makes life cycle possible.

653
00:24:04,360 --> 00:24:06,440
You can run access reviews on groups,

654
00:24:06,440 --> 00:24:07,920
you can expire group membership,

655
00:24:07,920 --> 00:24:09,480
you can enforce naming conventions

656
00:24:09,480 --> 00:24:10,880
and ownership requirements,

657
00:24:10,880 --> 00:24:12,720
you can detect orphaned groups.

658
00:24:12,720 --> 00:24:14,520
None of that works when the permission model

659
00:24:14,520 --> 00:24:17,720
lives as direct assignments scattered across 10,000 sites.

660
00:24:17,720 --> 00:24:18,960
Then comes guests.

661
00:24:18,960 --> 00:24:21,440
External collaboration is not a toggle in SharePoint.

662
00:24:21,440 --> 00:24:23,560
It's an identity life cycle problem in Entra.

663
00:24:23,560 --> 00:24:24,840
Guests must have sponsorship,

664
00:24:24,840 --> 00:24:27,000
guests must have expiration or review.

665
00:24:27,000 --> 00:24:29,160
Guests must be subject to conditional access

666
00:24:29,160 --> 00:24:30,840
and MFA expectations.

667
00:24:30,840 --> 00:24:32,920
And the invitation flow must be consistent

668
00:24:32,920 --> 00:24:35,720
because anyone can invite anyone is how you end up

669
00:24:35,720 --> 00:24:37,960
with external identities nobody can explain.

670
00:24:37,960 --> 00:24:40,560
This is also where cross tenant collaboration gets dangerous

671
00:24:40,560 --> 00:24:42,200
if the org treats it casually.

672
00:24:42,200 --> 00:24:44,880
If the enterprise allows multiple invitation patterns,

673
00:24:44,880 --> 00:24:46,680
multiple tenant relationships

674
00:24:46,680 --> 00:24:48,320
and inconsistent guest policies,

675
00:24:48,320 --> 00:24:49,840
the system doesn't become flexible,

676
00:24:49,840 --> 00:24:52,200
it becomes untraceable.

677
00:24:52,200 --> 00:24:54,480
So the Entra first blueprint is strict.

678
00:24:54,480 --> 00:24:57,200
Define collaboration zones and map them to guest policies.

679
00:24:57,200 --> 00:24:59,240
If a site is external by design,

680
00:24:59,240 --> 00:25:01,640
its access model is external by design.

681
00:25:01,640 --> 00:25:03,640
If it isn't, guests don't appear there

682
00:25:03,640 --> 00:25:05,280
because it was urgent.

683
00:25:05,280 --> 00:25:07,560
Now connect identity back to automation.

684
00:25:07,560 --> 00:25:09,120
When quick steps can execute a flow,

685
00:25:09,120 --> 00:25:11,960
the question becomes which identity does that flow run as

686
00:25:11,960 --> 00:25:13,240
and what can it touch?

687
00:25:13,240 --> 00:25:15,360
When approvals change state inside a library

688
00:25:15,360 --> 00:25:17,640
who is allowed to submit, who is allowed to approve

689
00:25:17,640 --> 00:25:19,800
and what downstream rights occur on approval,

690
00:25:19,800 --> 00:25:22,760
when agents retrieve content, what do they inherit

691
00:25:22,760 --> 00:25:24,240
and what do they trigger?

692
00:25:24,240 --> 00:25:26,960
Entra answers those questions with one mechanism.

693
00:25:26,960 --> 00:25:29,240
Explicit assignment by our groups and roles,

694
00:25:29,240 --> 00:25:30,440
not ambient privilege.

695
00:25:30,440 --> 00:25:33,600
And once identity is stable, the next layer finally works.

696
00:25:33,600 --> 00:25:35,720
Labels and DLP stop being aspirational

697
00:25:35,720 --> 00:25:38,400
because the system can reliably tell who is acting

698
00:25:38,400 --> 00:25:40,560
what they're allowed to do and what should be blocked.

699
00:25:40,560 --> 00:25:43,080
That's where PerView stops being compliance tooling

700
00:25:43,080 --> 00:25:46,760
and becomes runtime enforcement for automation and AI readiness.

701
00:25:46,760 --> 00:25:49,200
PerView Foundation, label first governance

702
00:25:49,200 --> 00:25:51,080
for automation and AI readiness.

703
00:25:51,080 --> 00:25:54,080
PerView is where most organizations learn a painful lesson.

704
00:25:54,080 --> 00:25:56,200
Classification isn't a compliance project.

705
00:25:56,200 --> 00:25:59,560
It's an architecture dependency because once automation exists,

706
00:25:59,560 --> 00:26:02,120
the system needs a reliable way to answer one question

707
00:26:02,120 --> 00:26:03,200
on every action.

708
00:26:03,200 --> 00:26:05,800
What kind of data is this and what rules apply to it?

709
00:26:05,800 --> 00:26:07,360
If you can't answer that deterministically,

710
00:26:07,360 --> 00:26:09,360
you're back to humans making policy decisions

711
00:26:09,360 --> 00:26:11,040
in the middle of machine speed workflows

712
00:26:11,040 --> 00:26:12,560
that doesn't scale, it never did.

713
00:26:12,560 --> 00:26:14,360
So label first governance is the foundation.

714
00:26:14,360 --> 00:26:15,840
Not because labels are trendy

715
00:26:15,840 --> 00:26:17,760
because labels are the only control primitive

716
00:26:17,760 --> 00:26:20,640
that can follow content across SharePoint teams one drive

717
00:26:20,640 --> 00:26:23,400
and the downstream systems your flows and agents touch.

718
00:26:23,400 --> 00:26:25,360
Start with sensitivity labels.

719
00:26:25,360 --> 00:26:29,040
Most people treat them like classification stickers,

720
00:26:29,040 --> 00:26:31,640
public, internal, confidential.

721
00:26:31,640 --> 00:26:32,840
That's the marketing version.

722
00:26:32,840 --> 00:26:36,040
Architecturally, a sensitivity label is an enforcement package.

723
00:26:36,040 --> 00:26:38,840
It can carry encryption behaviors, access expectations

724
00:26:38,840 --> 00:26:41,560
and downstream restrictions that stay attached to the file.

725
00:26:41,560 --> 00:26:44,800
It's a way to turn, we don't want this shared externally

726
00:26:44,800 --> 00:26:47,720
into a setting, the platform can actually enforce.

727
00:26:47,840 --> 00:26:51,000
When someone tries to share it, download it, sink it

728
00:26:51,000 --> 00:26:52,880
or route it through automation.

729
00:26:52,880 --> 00:26:55,040
And the key point for automation is simple.

730
00:26:55,040 --> 00:26:57,760
If labels exist only as optional user selections,

731
00:26:57,760 --> 00:26:59,280
they won't exist where you need them.

732
00:26:59,280 --> 00:27:00,920
Users won't label consistently,

733
00:27:00,920 --> 00:27:03,200
makers won't label at all unless forced.

734
00:27:03,200 --> 00:27:05,840
And agents will happily reason over whatever you gave them

735
00:27:05,840 --> 00:27:07,240
which often means the mess.

736
00:27:07,240 --> 00:27:10,120
So the blueprint is, labels must be part of the content

737
00:27:10,120 --> 00:27:12,040
life cycle, not an afterthought.

738
00:27:12,040 --> 00:27:13,600
Then retention labels.

739
00:27:13,600 --> 00:27:15,600
Retention gets misunderstood even faster

740
00:27:15,600 --> 00:27:18,280
because people wanted to be deletion scheduling.

741
00:27:18,280 --> 00:27:19,760
That's not the architectural function.

742
00:27:19,760 --> 00:27:23,080
Retention is about immutable outcomes and audit defensibility.

743
00:27:23,080 --> 00:27:25,160
This content must be kept for X years,

744
00:27:25,160 --> 00:27:27,960
disposed after Y, preserved under legal hold

745
00:27:27,960 --> 00:27:29,720
and proven to have followed policy.

746
00:27:29,720 --> 00:27:31,360
The important thing is that retention

747
00:27:31,360 --> 00:27:33,840
doesn't care whether your workflow was smart.

748
00:27:33,840 --> 00:27:36,440
It cares whether the organization can produce evidence,

749
00:27:36,440 --> 00:27:39,080
which means your automation must not circumvent retention

750
00:27:39,080 --> 00:27:42,400
by moving content into locations outside the policy scope,

751
00:27:42,400 --> 00:27:44,600
exporting it into ungoverned storage

752
00:27:44,600 --> 00:27:47,880
or generating duplicates that create legal ambiguity.

753
00:27:47,880 --> 00:27:50,040
Retention is where your workflow architecture

754
00:27:50,040 --> 00:27:51,320
meets legal reality.

755
00:27:51,320 --> 00:27:53,680
Now, auto labeling.

756
00:27:53,680 --> 00:27:56,520
Auto labeling sounds like salvation.

757
00:27:56,520 --> 00:27:58,760
Let the models find sensitive content,

758
00:27:58,760 --> 00:28:00,480
apply the right label and move on.

759
00:28:00,480 --> 00:28:02,000
And yes, Perv, you can do a lot here

760
00:28:02,000 --> 00:28:05,200
through sensitive information types and trainable classifiers.

761
00:28:05,200 --> 00:28:08,080
But this is where enterprises confuse automation capability

762
00:28:08,080 --> 00:28:10,160
with automation authority.

763
00:28:10,160 --> 00:28:12,880
Auto labeling works when the document patterns are consistent

764
00:28:12,880 --> 00:28:15,040
and the information architecture isn't chaos.

765
00:28:15,040 --> 00:28:17,520
If the organization stores contracts, invoices,

766
00:28:17,520 --> 00:28:19,720
and HR documents with predictable structure

767
00:28:19,720 --> 00:28:22,080
and consistent metadata, models can help.

768
00:28:22,080 --> 00:28:23,640
If the organization stores everything

769
00:28:23,640 --> 00:28:27,080
as final final V7 docs in a library called shared,

770
00:28:27,080 --> 00:28:29,600
auto labeling becomes probabilistic theater.

771
00:28:29,600 --> 00:28:33,560
The rule stays strict, models assist, humans own exceptions.

772
00:28:33,560 --> 00:28:34,960
Auto labeling reduces toil.

773
00:28:34,960 --> 00:28:36,720
It does not eliminate accountability.

774
00:28:36,720 --> 00:28:38,320
Now connect this to AI readiness

775
00:28:38,320 --> 00:28:40,200
because that's why this section exists.

776
00:28:40,200 --> 00:28:42,280
Copilot and agents don't invent permissions.

777
00:28:42,280 --> 00:28:43,120
They inherit them.

778
00:28:43,120 --> 00:28:45,640
But what they do amplify is discoverability.

779
00:28:45,640 --> 00:28:47,400
If sensitive content is overshared,

780
00:28:47,400 --> 00:28:48,880
agents will surface it faster.

781
00:28:48,880 --> 00:28:51,080
If metadata is sloppy, agents will answer

782
00:28:51,080 --> 00:28:53,200
with the wrong latest document.

783
00:28:53,200 --> 00:28:55,640
If labels are missing, DLP and sharing controls

784
00:28:55,640 --> 00:28:57,360
can't reliably gate action.

785
00:28:57,360 --> 00:29:00,160
So AI readiness is not turn on copilot.

786
00:29:00,160 --> 00:29:03,640
AI readiness is can the system reliably distinguish

787
00:29:03,640 --> 00:29:07,320
what is safe to summarize, safe to share, safe to root,

788
00:29:07,320 --> 00:29:08,680
and safe to ground answers on?

789
00:29:08,680 --> 00:29:10,480
Labels are how you teach the platform

790
00:29:10,480 --> 00:29:12,920
that distinction without hoping users remember.

791
00:29:12,920 --> 00:29:16,040
This is also why information architecture suddenly matters again.

792
00:29:16,040 --> 00:29:18,720
SharePoint has always needed content types, metadata,

793
00:29:18,720 --> 00:29:20,280
and clear library design.

794
00:29:20,280 --> 00:29:23,160
The difference now is that AI fails loudly on chaos.

795
00:29:23,160 --> 00:29:24,920
Search could limp along with poor metadata.

796
00:29:24,920 --> 00:29:25,840
Agents can't.

797
00:29:25,840 --> 00:29:27,800
They will confidently synthesize nonsense

798
00:29:27,800 --> 00:29:29,160
from a messy corpus.

799
00:29:29,160 --> 00:29:31,520
And your users will treat it as authoritative

800
00:29:31,520 --> 00:29:32,880
because it speaks fluently.

801
00:29:32,880 --> 00:29:36,280
So you standardize the minimum viable information architecture,

802
00:29:36,280 --> 00:29:38,560
required metadata for high value libraries,

803
00:29:38,560 --> 00:29:40,880
consistent naming for sites and libraries,

804
00:29:40,880 --> 00:29:43,440
and a label taxonomy that maps to real enforcement.

805
00:29:43,440 --> 00:29:45,080
Not 20 labels nobody understands.

806
00:29:45,080 --> 00:29:47,600
A small number that represent real policy boundaries.

807
00:29:47,600 --> 00:29:50,280
And you wire those labels into automation pathways.

808
00:29:50,280 --> 00:29:52,960
Workflows should set labels when business context is known,

809
00:29:52,960 --> 00:29:54,600
not wait for users.

810
00:29:54,600 --> 00:29:56,280
Provisioning should apply default labels

811
00:29:56,280 --> 00:29:58,240
to sites and libraries based on purpose.

812
00:29:58,240 --> 00:30:01,600
Approval completion should trigger label validation

813
00:30:01,600 --> 00:30:04,680
before content moves to an externally shareable zone.

814
00:30:04,680 --> 00:30:07,120
Agents should operate in spaces where labeling discipline

815
00:30:07,120 --> 00:30:09,640
exists because otherwise they become a high speed interface

816
00:30:09,640 --> 00:30:11,440
to your ungoverned past.

817
00:30:11,440 --> 00:30:12,640
Here's what most people miss.

818
00:30:12,640 --> 00:30:15,400
Label first is not about making compliance happy.

819
00:30:15,400 --> 00:30:16,880
It's about giving your automation

820
00:30:16,880 --> 00:30:18,400
a deterministic control surface.

821
00:30:18,400 --> 00:30:20,800
When a flow runs, it should be able to check a label

822
00:30:20,800 --> 00:30:21,880
and know what to do.

823
00:30:21,880 --> 00:30:24,040
When a quick step executes, it should run

824
00:30:24,040 --> 00:30:26,840
into the same label-based boundary every time.

825
00:30:26,840 --> 00:30:28,280
When an agent suggests an action,

826
00:30:28,280 --> 00:30:31,040
the enforcement layer should be able to say yes or no

827
00:30:31,040 --> 00:30:33,280
based on label-driven policy, not on vibes.

828
00:30:33,280 --> 00:30:34,600
That's the foundation.

829
00:30:34,600 --> 00:30:35,880
And once labels are real,

830
00:30:35,880 --> 00:30:39,400
DLP becomes something else entirely, not a compliance report.

831
00:30:39,400 --> 00:30:42,280
A runtime gate, DLP as a runtime gate,

832
00:30:42,280 --> 00:30:44,840
stop leakage, log intent, allow business.

833
00:30:44,840 --> 00:30:46,800
DLP is where the enterprise stops pretending

834
00:30:46,800 --> 00:30:49,280
it can train its way out of data leakage.

835
00:30:49,280 --> 00:30:52,240
Most organizations deploy DLP like a museum alarm.

836
00:30:52,240 --> 00:30:55,480
It exists, it's loud, and everyone learns how to walk around it.

837
00:30:55,480 --> 00:30:58,520
The modern blueprint treats DLP as a runtime gate,

838
00:30:58,520 --> 00:31:00,880
a control that evaluates the moment of action,

839
00:31:00,880 --> 00:31:02,920
blocks the bad parts and records the intent

840
00:31:02,920 --> 00:31:04,280
when you allow an exception.

841
00:31:04,280 --> 00:31:06,480
That distinction matters because automation changes

842
00:31:06,480 --> 00:31:07,520
the leakage shape.

843
00:31:07,520 --> 00:31:10,520
Without automation, leakage usually happens through a person,

844
00:31:10,520 --> 00:31:13,600
copied to USB, forward an email, share a link.

845
00:31:13,600 --> 00:31:17,000
With automation, leakage happens through a workflow identity.

846
00:31:17,000 --> 00:31:19,040
Move this file, email this PDF,

847
00:31:19,040 --> 00:31:21,280
sync this data that posted to that connector,

848
00:31:21,280 --> 00:31:22,680
and because it's machine speed,

849
00:31:22,680 --> 00:31:24,800
the volume can spike before anyone notices.

850
00:31:24,800 --> 00:31:26,400
So the DLP job isn't to be perfect.

851
00:31:26,400 --> 00:31:28,080
It's to be present at the exact moment

852
00:31:28,080 --> 00:31:30,480
your workflows move data across a boundary.

853
00:31:30,480 --> 00:31:32,760
The enterprise requirement is unified DLP,

854
00:31:32,760 --> 00:31:35,480
one policy language, many surfaces.

855
00:31:35,480 --> 00:31:38,280
SharePoint libraries, teams files, one drive endpoints,

856
00:31:38,280 --> 00:31:39,720
and the connectors your flows use

857
00:31:39,720 --> 00:31:41,960
all represent different X filtration parts.

858
00:31:41,960 --> 00:31:44,520
If DLP only exists in one of those layers,

859
00:31:44,520 --> 00:31:46,760
you've built a control that blocks the honest user

860
00:31:46,760 --> 00:31:47,920
and misses the real root.

861
00:31:47,920 --> 00:31:51,400
Pervuse value is that the same classification concepts,

862
00:31:51,400 --> 00:31:54,080
sensitive info types, labels, locations,

863
00:31:54,080 --> 00:31:56,400
can be expressed as a single enforcement strategy

864
00:31:56,400 --> 00:31:58,360
instead of five separate rulebooks maintained

865
00:31:58,360 --> 00:31:59,640
by five different teams.

866
00:31:59,640 --> 00:32:02,560
And then you stratify, this is where most DLP programs fail.

867
00:32:02,560 --> 00:32:05,400
They create one policy that tries to protect everything

868
00:32:05,400 --> 00:32:07,160
and it ends up either blocking the business

869
00:32:07,160 --> 00:32:08,280
or blocking nothing.

870
00:32:08,280 --> 00:32:10,760
The blueprint is explicit policy stratification,

871
00:32:10,760 --> 00:32:13,400
separate blast radii for separate data classes.

872
00:32:13,400 --> 00:32:14,680
PII is one blast radius.

873
00:32:14,680 --> 00:32:17,000
Financial data is another, source code is another,

874
00:32:17,000 --> 00:32:19,960
M&A documents are another, HR investigations are another.

875
00:32:19,960 --> 00:32:22,600
Why? Because what counts as acceptable friction

876
00:32:22,600 --> 00:32:24,520
is different for each class.

877
00:32:24,520 --> 00:32:27,040
An engineer moving code to a repo is not the same

878
00:32:27,040 --> 00:32:29,240
as a recruiter sharing candidate data.

879
00:32:29,240 --> 00:32:30,560
If you treat them the same,

880
00:32:30,560 --> 00:32:33,600
you either destroy productivity or normalize bypasses.

881
00:32:33,600 --> 00:32:35,360
Now, the runtime part.

882
00:32:35,360 --> 00:32:38,600
A good DLP gate doesn't just block.

883
00:32:38,600 --> 00:32:40,720
It offers controlled outcomes, allow, block,

884
00:32:40,720 --> 00:32:42,280
or allow with justification.

885
00:32:42,280 --> 00:32:44,720
And allow with justification is not a feel good compromise.

886
00:32:44,720 --> 00:32:46,000
It's a telemetry generator.

887
00:32:46,000 --> 00:32:47,920
If someone needs to share something sensitive

888
00:32:47,920 --> 00:32:50,640
for a legitimate reason, the system can allow it.

889
00:32:50,640 --> 00:32:52,760
But only if the user supplies a reason

890
00:32:52,760 --> 00:32:56,240
and only if that event is logged as a high signal audit trail.

891
00:32:56,240 --> 00:32:58,600
That creates two things you never get from blanket blocking,

892
00:32:58,600 --> 00:33:00,560
accountability and attuning loop.

893
00:33:00,560 --> 00:33:02,560
Because false positives are not a bug.

894
00:33:02,560 --> 00:33:04,160
They're a feature of pattern-based detection

895
00:33:04,160 --> 00:33:05,800
meeting messy enterprise data.

896
00:33:05,800 --> 00:33:09,080
So you design an escalation path and attuning loop on purpose.

897
00:33:09,080 --> 00:33:11,400
When the system blocks a legitimate business action,

898
00:33:11,400 --> 00:33:13,280
there must be a known place to go.

899
00:33:13,280 --> 00:33:15,720
A request path, a review queue,

900
00:33:15,720 --> 00:33:18,600
a policy exception process that is time bound

901
00:33:18,600 --> 00:33:20,080
and tied to an owner.

902
00:33:20,080 --> 00:33:22,640
And when the system allows something with justification,

903
00:33:22,640 --> 00:33:26,760
that justification data becomes input into policy refinement.

904
00:33:26,760 --> 00:33:29,240
Over time, the policy stops being theoretical

905
00:33:29,240 --> 00:33:32,280
and starts reflecting how the business actually moves data.

906
00:33:32,280 --> 00:33:34,120
Here's the part automation teams miss.

907
00:33:34,120 --> 00:33:37,000
DLP has to understand your automation identities.

908
00:33:37,000 --> 00:33:39,120
If a flow runs under a service principle

909
00:33:39,120 --> 00:33:42,280
or managed identity, the DLP posture needs to account for it.

910
00:33:42,280 --> 00:33:44,480
Otherwise, you end up with the worst outcome.

911
00:33:44,480 --> 00:33:45,760
Humans blocked.

912
00:33:45,760 --> 00:33:47,520
Automations free.

913
00:33:47,520 --> 00:33:50,560
That is how we lockdown sharing turns into the workflow

914
00:33:50,560 --> 00:33:52,600
emailed the file externally anyway.

915
00:33:52,600 --> 00:33:54,600
So the blueprint requires this.

916
00:33:54,600 --> 00:33:57,960
Every automation pathway that exports, shares, or transforms

917
00:33:57,960 --> 00:34:00,960
content gets treated as a data egress point.

918
00:34:00,960 --> 00:34:02,720
It's evaluated, it's locked, and it

919
00:34:02,720 --> 00:34:04,880
has an owner who can explain why it exists.

920
00:34:04,880 --> 00:34:07,480
Now connect DLP back to quick steps and approvals.

921
00:34:07,480 --> 00:34:10,600
Quick steps reduce friction, which means they increase usage,

922
00:34:10,600 --> 00:34:12,720
which means they increase risk surface.

923
00:34:12,720 --> 00:34:15,080
If execute flow is available on sensitive libraries,

924
00:34:15,080 --> 00:34:17,320
then DLP and labeling must sit behind it

925
00:34:17,320 --> 00:34:18,880
as a non-negotiable gate.

926
00:34:18,880 --> 00:34:22,000
Approvals create state, but they don't enforce classification.

927
00:34:22,000 --> 00:34:23,720
So the enforcement must happen at the moment

928
00:34:23,720 --> 00:34:26,960
of sharing, moving, exporting, or posting to other systems.

929
00:34:26,960 --> 00:34:28,600
Especially when the action is triggered

930
00:34:28,600 --> 00:34:32,760
by approved status and nobody is watching the downstream step.

931
00:34:32,760 --> 00:34:34,680
So the DLP design goal is brutally simple.

932
00:34:34,680 --> 00:34:36,760
Stop leakage, log intent, allow business.

933
00:34:36,760 --> 00:34:39,160
And if you do it right, DLP becomes less

934
00:34:39,160 --> 00:34:42,040
about security theater and more about engineering reality,

935
00:34:42,040 --> 00:34:43,880
a runtime decision engine that reduces

936
00:34:43,880 --> 00:34:46,240
blast radius while producing evidence.

937
00:34:46,240 --> 00:34:47,520
Now none of this matters if you can't

938
00:34:47,520 --> 00:34:48,640
see what the system is doing.

939
00:34:48,640 --> 00:34:51,440
A runtime gate without observability is just silent failure

940
00:34:51,440 --> 00:34:52,520
with better branding.

941
00:34:52,520 --> 00:34:55,600
Observability architecture, audit logs, diagnostics,

942
00:34:55,600 --> 00:34:57,520
Sentinel and real signals.

943
00:34:57,520 --> 00:35:00,600
If governance is enforcement, observability is proof.

944
00:35:00,600 --> 00:35:03,640
And enterprises don't fail because they lacked policies.

945
00:35:03,640 --> 00:35:05,560
They fail because they couldn't prove what happened

946
00:35:05,560 --> 00:35:08,360
when automation did something weird at 2.13 a.m.

947
00:35:08,360 --> 00:35:11,480
Observability is how a workflow platform stays a platform

948
00:35:11,480 --> 00:35:14,560
instead of becoming a haunted house of it usually works.

949
00:35:14,560 --> 00:35:16,040
Start with the unified audit log

950
00:35:16,040 --> 00:35:18,440
because it's the thing everyone vaguely knows exists

951
00:35:18,440 --> 00:35:20,560
and almost nobody designs around.

952
00:35:20,560 --> 00:35:21,880
The audit log is good at answering

953
00:35:21,880 --> 00:35:24,160
who did what to which object and when.

954
00:35:24,160 --> 00:35:27,400
File access, file shared, permission changed,

955
00:35:27,400 --> 00:35:30,000
sensitivity label applied, guest invited,

956
00:35:30,000 --> 00:35:31,560
that's the compliance great trail.

957
00:35:31,560 --> 00:35:33,320
It's the ledger you pull when legal asks

958
00:35:33,320 --> 00:35:35,880
or when an incident responder needs attribution.

959
00:35:35,880 --> 00:35:37,440
But it's not operational telemetry.

960
00:35:37,440 --> 00:35:39,520
It won't tell you why you're flow-run five times.

961
00:35:39,520 --> 00:35:41,320
It won't show you latency distributions.

962
00:35:41,320 --> 00:35:43,160
It won't give you an execution graph.

963
00:35:43,160 --> 00:35:45,240
And it definitely won't explain failure modes

964
00:35:45,240 --> 00:35:48,160
inside power automate, Azure functions or logic apps.

965
00:35:48,160 --> 00:35:51,240
So treat the audit log as the what happened source.

966
00:35:51,240 --> 00:35:53,720
Not the how is it behaving source.

967
00:35:53,720 --> 00:35:55,240
That distinction matters.

968
00:35:55,240 --> 00:35:58,280
Next, diagnostic logs, SharePoint, Entra,

969
00:35:58,280 --> 00:36:01,040
and the automation runtime all generate diagnostics

970
00:36:01,040 --> 00:36:03,200
that are closer to engineering reality.

971
00:36:03,200 --> 00:36:05,560
Requests, throttles, API responses,

972
00:36:05,560 --> 00:36:08,640
connector errors, job durations, queue depth,

973
00:36:08,640 --> 00:36:09,960
retry counts.

974
00:36:09,960 --> 00:36:11,280
These belong in log analytics

975
00:36:11,280 --> 00:36:14,560
because you want one place where you can correlate identity signals,

976
00:36:14,560 --> 00:36:17,440
SharePoint activity and workflow execution.

977
00:36:17,440 --> 00:36:19,520
This is where most orgs quietly lose.

978
00:36:19,520 --> 00:36:20,960
They log in each silo.

979
00:36:20,960 --> 00:36:23,080
Power automate run history sits in one place,

980
00:36:23,080 --> 00:36:26,160
function logs sit in another SharePoint activity sits somewhere else.

981
00:36:26,160 --> 00:36:28,000
Sentinel has alerts but not context.

982
00:36:28,000 --> 00:36:31,120
And then during an incident, someone screenshots five portals

983
00:36:31,120 --> 00:36:33,080
and calls it root cause analysis.

984
00:36:33,080 --> 00:36:34,000
But that's not analysis.

985
00:36:34,000 --> 00:36:34,960
That's archaeology.

986
00:36:34,960 --> 00:36:37,280
So the observability architecture is explicit,

987
00:36:37,280 --> 00:36:39,680
centralized telemetry, normalized correlation,

988
00:36:39,680 --> 00:36:41,400
and make queries repeatable.

989
00:36:41,400 --> 00:36:43,440
A practical pattern is to stamp everything

990
00:36:43,440 --> 00:36:46,640
with correlation identifiers you can carry across the system.

991
00:36:46,640 --> 00:36:49,160
Event ID, site ID, item ID, flow run ID,

992
00:36:49,160 --> 00:36:51,920
function invocation ID, user ID, service principle ID.

993
00:36:51,920 --> 00:36:54,800
If you can't join the data, you can't reason about the system.

994
00:36:54,800 --> 00:36:57,120
And if you can't reason about it, you can't scale it.

995
00:36:57,120 --> 00:36:58,240
Now Sentinel.

996
00:36:58,240 --> 00:37:00,400
Sentinel is not the place you dump logs

997
00:37:00,400 --> 00:37:02,120
and hope intelligence happens.

998
00:37:02,120 --> 00:37:04,080
Sentinel is where you codify detections

999
00:37:04,080 --> 00:37:06,120
that matter for SharePoint automation.

1000
00:37:06,120 --> 00:37:08,320
Oversharing patterns, abnormal access

1001
00:37:08,320 --> 00:37:11,160
and automation identities, doing suspicious things.

1002
00:37:11,160 --> 00:37:13,120
Start with Oversharing detections.

1003
00:37:13,120 --> 00:37:16,640
New anonymous links created on a library that should never allow them.

1004
00:37:16,640 --> 00:37:19,480
A spike in shared with external user's events.

1005
00:37:19,480 --> 00:37:21,160
A folder with broken inheritance

1006
00:37:21,160 --> 00:37:23,600
that suddenly starts receiving labeled content.

1007
00:37:23,600 --> 00:37:25,120
Those are high signal events

1008
00:37:25,120 --> 00:37:27,960
because they represent boundary failure, not just activity.

1009
00:37:27,960 --> 00:37:29,640
Then abnormal access patterns,

1010
00:37:29,640 --> 00:37:32,200
a guest account downloading hundreds of files.

1011
00:37:32,200 --> 00:37:34,680
A user accessing a site they never touched before

1012
00:37:34,680 --> 00:37:36,280
right after an invitation,

1013
00:37:36,280 --> 00:37:38,600
a service principle reading across many sites

1014
00:37:38,600 --> 00:37:40,320
outside its normal scope.

1015
00:37:40,320 --> 00:37:42,080
Those aren't maybe incidences.

1016
00:37:42,080 --> 00:37:42,960
They're the kinds of patterns

1017
00:37:42,960 --> 00:37:45,560
that if you ignore them, become breach narratives.

1018
00:37:45,560 --> 00:37:49,120
And now the part most org skip automation failure signals.

1019
00:37:49,120 --> 00:37:51,040
A flow failing is not an IT problem.

1020
00:37:51,040 --> 00:37:52,360
It's a business process outage.

1021
00:37:52,360 --> 00:37:55,240
So your detections need to include sustained failure rates

1022
00:37:55,240 --> 00:37:57,240
above a threshold, dead letter growth,

1023
00:37:57,240 --> 00:37:59,840
retreats exceeding normal QAG exceeding SLA

1024
00:37:59,840 --> 00:38:02,840
and flows with no owners receiving failure notifications.

1025
00:38:02,840 --> 00:38:05,880
Failure without alerting is just deferred surprise.

1026
00:38:05,880 --> 00:38:07,320
That leads to the brutal question,

1027
00:38:07,320 --> 00:38:08,880
what metrics actually matter?

1028
00:38:08,880 --> 00:38:10,320
Most dashboards are vanity.

1029
00:38:10,320 --> 00:38:13,280
The real signals are latency, throughput, failure rate

1030
00:38:13,280 --> 00:38:15,480
and drift, latency.

1031
00:38:15,480 --> 00:38:17,840
How long from event to enforcement?

1032
00:38:17,840 --> 00:38:20,160
Not run duration and to end time.

1033
00:38:20,160 --> 00:38:22,160
Even approval takes two days fine.

1034
00:38:22,160 --> 00:38:25,120
But if label applied after upload takes 30 minutes,

1035
00:38:25,120 --> 00:38:26,960
you've just created an exposure window.

1036
00:38:26,960 --> 00:38:30,920
throughput, events processed per unit time

1037
00:38:30,920 --> 00:38:33,480
and how that changes during predictable spikes.

1038
00:38:33,480 --> 00:38:36,360
Month end, Monday morning, quarter close,

1039
00:38:36,360 --> 00:38:39,160
the system must survive reality, not average load.

1040
00:38:39,160 --> 00:38:41,240
Failure rate not did it fail once.

1041
00:38:41,240 --> 00:38:42,800
Failure distribution by connector,

1042
00:38:42,800 --> 00:38:46,120
by side, by label, by identity, by workflow version.

1043
00:38:46,120 --> 00:38:48,600
This is how you find systemic brittleness.

1044
00:38:48,600 --> 00:38:50,880
Drift trend lines.

1045
00:38:50,880 --> 00:38:52,920
Permissions inheritance breaks over time,

1046
00:38:52,920 --> 00:38:55,560
guest count per site, number of flows per site,

1047
00:38:55,560 --> 00:38:57,320
number of quick step invocation points,

1048
00:38:57,320 --> 00:38:58,720
number of exceptions.

1049
00:38:58,720 --> 00:39:00,280
Drift is your entropy meter.

1050
00:39:00,280 --> 00:39:01,800
And here's the governance outcome.

1051
00:39:01,800 --> 00:39:04,640
Observability isn't optional because you like monitoring.

1052
00:39:04,640 --> 00:39:06,120
And it's required because automation

1053
00:39:06,120 --> 00:39:08,000
without observability is blind execution

1054
00:39:08,000 --> 00:39:10,320
and blind execution eventually hits the one library

1055
00:39:10,320 --> 00:39:13,080
that contained the one document that triggers the one audit.

1056
00:39:13,080 --> 00:39:15,240
So once you've built the control plane,

1057
00:39:15,240 --> 00:39:17,360
identity labels, DLP and telemetry,

1058
00:39:17,360 --> 00:39:19,200
you can finally talk about scale scenarios

1059
00:39:19,200 --> 00:39:20,520
without lying to yourself.

1060
00:39:20,520 --> 00:39:22,880
And the first one is the most common enterprise fantasy,

1061
00:39:22,880 --> 00:39:25,200
provisioning, scenario one framing.

1062
00:39:25,200 --> 00:39:27,960
Provisioning is a factory line, not a request form.

1063
00:39:27,960 --> 00:39:30,320
Provisioning is where SharePoint automation stops

1064
00:39:30,320 --> 00:39:32,080
being a convenience feature and becomes

1065
00:39:32,080 --> 00:39:34,160
an enterprise liability generator

1066
00:39:34,160 --> 00:39:36,120
because every organization starts the same way.

1067
00:39:36,120 --> 00:39:38,680
Someone creates a site for a project, then another.

1068
00:39:38,680 --> 00:39:40,360
Someone uses a template.

1069
00:39:40,360 --> 00:39:41,200
Someone doesn't.

1070
00:39:41,200 --> 00:39:42,480
Someone adds owners directly.

1071
00:39:42,480 --> 00:39:44,240
Someone breaks inheritance on a folder

1072
00:39:44,240 --> 00:39:46,080
because finance needs privacy.

1073
00:39:46,080 --> 00:39:47,920
Guests get invited because it's urgent.

1074
00:39:47,920 --> 00:39:51,280
A year later, nobody remembers why half of these sites exist,

1075
00:39:51,280 --> 00:39:54,520
who owns them or which ones contain regulated content.

1076
00:39:54,520 --> 00:39:56,120
That isn't user failure.

1077
00:39:56,120 --> 00:39:57,520
That's a missing factory.

1078
00:39:57,520 --> 00:40:00,600
Most enterprises treat provisioning

1079
00:40:00,600 --> 00:40:02,280
like a request form problem.

1080
00:40:02,280 --> 00:40:04,040
Let's make a form, ask a few questions

1081
00:40:04,040 --> 00:40:05,480
and route it for approval.

1082
00:40:05,480 --> 00:40:06,280
They get the form.

1083
00:40:06,280 --> 00:40:07,640
They even get the approval.

1084
00:40:07,640 --> 00:40:10,160
What they never build is the assembly line behind it.

1085
00:40:10,160 --> 00:40:12,840
Deterministic creation, deterministic configuration,

1086
00:40:12,840 --> 00:40:15,400
deterministic access model and deterministic life cycle.

1087
00:40:15,400 --> 00:40:16,680
So the framing is strict.

1088
00:40:16,680 --> 00:40:18,040
Provisioning is manufacturing.

1089
00:40:18,040 --> 00:40:20,160
A request is just demand signal.

1090
00:40:20,160 --> 00:40:22,600
The product is a workspace with known properties

1091
00:40:22,600 --> 00:40:24,600
and if you don't build it like manufacturing,

1092
00:40:24,600 --> 00:40:26,560
you don't get some inconsistency.

1093
00:40:26,560 --> 00:40:28,280
Are you getting uncontrolled estate?

1094
00:40:28,280 --> 00:40:30,120
Thousands of workspaces that behave differently,

1095
00:40:30,120 --> 00:40:32,440
leak differently and fail audits differently.

1096
00:40:32,440 --> 00:40:35,080
The factory line model starts with a few non-negotiables.

1097
00:40:35,080 --> 00:40:38,920
First, every site is created from a template, not usually.

1098
00:40:38,920 --> 00:40:41,040
Always, the template isn't only branding.

1099
00:40:41,040 --> 00:40:43,920
It's baseline controls, default sharing posture,

1100
00:40:43,920 --> 00:40:46,280
default sensitivity label expectations,

1101
00:40:46,280 --> 00:40:48,920
default library structure, default navigation,

1102
00:40:48,920 --> 00:40:51,120
default owners and members mapping,

1103
00:40:51,120 --> 00:40:53,800
default retention configuration where applicable

1104
00:40:53,800 --> 00:40:56,040
and the metadata standards that make automation

1105
00:40:56,040 --> 00:40:57,520
reliable later.

1106
00:40:57,520 --> 00:41:01,080
Second, every site has a countable ownership at creation time.

1107
00:41:01,080 --> 00:41:03,760
Not a person's name typed into a text field.

1108
00:41:03,760 --> 00:41:06,680
An Entra group as the owner with at least two human owners

1109
00:41:06,680 --> 00:41:09,400
inside it and an actual life cycle expectation.

1110
00:41:09,400 --> 00:41:11,360
If ownership is optional, the estate becomes

1111
00:41:11,360 --> 00:41:12,960
often on day one.

1112
00:41:12,960 --> 00:41:15,280
Then your life cycle policy becomes a clean up script

1113
00:41:15,280 --> 00:41:16,880
that no one wants to run because it will

1114
00:41:16,880 --> 00:41:18,480
delete something important.

1115
00:41:18,480 --> 00:41:20,680
Third, permissions come from the group model,

1116
00:41:20,680 --> 00:41:22,160
not from creativity.

1117
00:41:22,160 --> 00:41:24,680
The provisioning pipeline doesn't ask who should have access.

1118
00:41:24,680 --> 00:41:26,960
And it asks which access model applies.

1119
00:41:26,960 --> 00:41:29,440
Internal project, external collaboration zone,

1120
00:41:29,440 --> 00:41:31,840
records repository, department hub,

1121
00:41:31,840 --> 00:41:35,240
each one maps to a predefined set of groups and site settings.

1122
00:41:35,240 --> 00:41:37,400
That's how you stop every new workspace

1123
00:41:37,400 --> 00:41:41,200
from being a custom snowflake with a custom risk profile.

1124
00:41:41,200 --> 00:41:44,160
Now the part lead is always under estimate volume.

1125
00:41:44,160 --> 00:41:48,080
At enterprise scale, provisioning isn't a few sites per week.

1126
00:41:48,080 --> 00:41:50,000
It's constant background noise, new teams,

1127
00:41:50,000 --> 00:41:52,960
new initiatives, new partners, reorganizations, acquisitions,

1128
00:41:52,960 --> 00:41:54,960
divestitures and compliance requirements

1129
00:41:54,960 --> 00:41:56,720
that force new segregation.

1130
00:41:56,720 --> 00:41:59,480
The demand doesn't slow down because governance is busy.

1131
00:41:59,480 --> 00:42:01,240
It speeds up because the business is busy.

1132
00:42:01,240 --> 00:42:02,600
That means the provisioning system

1133
00:42:02,600 --> 00:42:03,920
can't be a human pipeline.

1134
00:42:03,920 --> 00:42:06,560
It has to be event driven and async

1135
00:42:06,560 --> 00:42:09,160
with predictable throughput and failure handling.

1136
00:42:09,160 --> 00:42:11,240
Because a manual synchronous provisioning flow

1137
00:42:11,240 --> 00:42:12,760
doesn't just create delays.

1138
00:42:12,760 --> 00:42:14,120
It creates bypass behavior.

1139
00:42:14,120 --> 00:42:15,520
People will create sites directly

1140
00:42:15,520 --> 00:42:17,240
because it's urgent and your factory

1141
00:42:17,240 --> 00:42:19,320
gets quietly replaced by shadow manufacturing.

1142
00:42:19,320 --> 00:42:21,600
So a scalable provisioning pattern looks like this.

1143
00:42:21,600 --> 00:42:25,920
Intake, validate, approve, provision, enforce and register.

1144
00:42:25,920 --> 00:42:29,160
Intake is your request portal form or agent-driven entry point.

1145
00:42:29,160 --> 00:42:30,920
That's the only place you collect human intent.

1146
00:42:30,920 --> 00:42:33,720
Validation is where you enforce naming standards,

1147
00:42:33,720 --> 00:42:36,520
required fields and policy eligibility.

1148
00:42:36,520 --> 00:42:39,680
Can this user request an external collaboration site?

1149
00:42:39,680 --> 00:42:43,320
Is this business unit allowed to create a hub site association?

1150
00:42:43,320 --> 00:42:46,600
Does this workload require a retention label?

1151
00:42:46,600 --> 00:42:49,960
The validation step is where you reject bad requests quickly

1152
00:42:49,960 --> 00:42:52,480
before you create infrastructure you'll regret.

1153
00:42:52,480 --> 00:42:54,560
Approval is not about gatekeeping creation.

1154
00:42:54,560 --> 00:42:56,280
Approval is about allocating risk.

1155
00:42:56,280 --> 00:42:57,960
Someone with actual authority signs

1156
00:42:57,960 --> 00:42:59,800
of that this workspace should exist

1157
00:42:59,800 --> 00:43:00,840
with these boundaries.

1158
00:43:00,840 --> 00:43:03,240
And the approval must be tied to the same identity model

1159
00:43:03,240 --> 00:43:04,600
you'll enforce later.

1160
00:43:04,600 --> 00:43:06,640
If approvers are ad hoc, you've created a loophole

1161
00:43:06,640 --> 00:43:08,120
with a pretty UI.

1162
00:43:08,120 --> 00:43:10,640
Provisioning itself is pure execution.

1163
00:43:10,640 --> 00:43:13,800
Create the site using graph, apply the template,

1164
00:43:13,800 --> 00:43:17,040
associate to the correct hub, create libraries and lists,

1165
00:43:17,040 --> 00:43:20,320
apply baseline settings, create the owner member groups

1166
00:43:20,320 --> 00:43:21,720
and apply permissions.

1167
00:43:21,720 --> 00:43:24,760
No branching business logic scattered across 20 flow steps,

1168
00:43:24,760 --> 00:43:28,200
one provisioning service, versioned, testable and repeatable.

1169
00:43:28,200 --> 00:43:29,960
And then the thing everyone forgets.

1170
00:43:29,960 --> 00:43:30,880
Registration.

1171
00:43:30,880 --> 00:43:33,360
If a site exists but isn't registered in an inventory

1172
00:43:33,360 --> 00:43:35,920
with purpose, owner group, classification expectations

1173
00:43:35,920 --> 00:43:37,560
and lifecycle policy, it's invisible.

1174
00:43:37,560 --> 00:43:39,400
Invisible becomes ungovernable.

1175
00:43:39,400 --> 00:43:41,840
Ungovernable becomes, we didn't know it was there

1176
00:43:41,840 --> 00:43:43,560
when co-pilot start surfacing it

1177
00:43:43,560 --> 00:43:46,320
or when an auditor asks why a partner still has access

1178
00:43:46,320 --> 00:43:48,080
two years after the contract ended.

1179
00:43:48,080 --> 00:43:49,680
Finally, lifecycle.

1180
00:43:49,680 --> 00:43:52,240
Provisioning without lifecycle is just automated sprawl.

1181
00:43:52,240 --> 00:43:54,560
So the factory must include in activity thresholds

1182
00:43:54,560 --> 00:43:56,160
renewal prompts for ownership,

1183
00:43:56,160 --> 00:43:59,160
enforced transfer of ownership when owners leave archival pathways

1184
00:43:59,160 --> 00:44:01,680
and retirement that's policy driven instead of emotional.

1185
00:44:01,680 --> 00:44:03,720
The system doesn't ask humans to remember.

1186
00:44:03,720 --> 00:44:06,680
It detects, notifies, escalates and then enforces.

1187
00:44:06,680 --> 00:44:07,440
That's the frame.

1188
00:44:07,440 --> 00:44:10,360
Provisioning is a factory line, not a request form.

1189
00:44:10,360 --> 00:44:12,920
And once you accept that, the next section gets concrete.

1190
00:44:12,920 --> 00:44:15,160
The reference architecture that implements this factory

1191
00:44:15,160 --> 00:44:18,280
with graph provisioning and queue-based orchestration.

1192
00:44:18,280 --> 00:44:20,640
Scenario one reference architecture, graph provisioning

1193
00:44:20,640 --> 00:44:22,440
plus queue-based orchestration.

1194
00:44:22,440 --> 00:44:24,480
The reference architecture is deliberately boring

1195
00:44:24,480 --> 00:44:27,480
because boring is what survives enterprise scale.

1196
00:44:27,480 --> 00:44:30,120
It starts with an entry point that looks like a request

1197
00:44:30,120 --> 00:44:33,760
but behaves like a contract, a form, a portal, an agent.

1198
00:44:33,760 --> 00:44:34,680
It doesn't matter.

1199
00:44:34,680 --> 00:44:36,280
What matters is the payload.

1200
00:44:36,280 --> 00:44:38,720
Purpose, data classification expectations,

1201
00:44:38,720 --> 00:44:41,440
internal versus external, requested owners group

1202
00:44:41,440 --> 00:44:43,440
and any required lifecycle dates.

1203
00:44:43,440 --> 00:44:45,160
And if the request can't express intent

1204
00:44:45,160 --> 00:44:47,280
in a structured way, the provisioning pipeline

1205
00:44:47,280 --> 00:44:49,440
can't enforce it later, you'll be guessing.

1206
00:44:49,440 --> 00:44:51,600
Systems guess badly.

1207
00:44:51,600 --> 00:44:54,160
From there, the first component is validation.

1208
00:44:54,160 --> 00:44:57,040
Not does the form have values, policy validation,

1209
00:44:57,040 --> 00:45:01,000
naming conventions, allowed site types, allowed hubs,

1210
00:45:01,000 --> 00:45:02,640
allowed sharing posture.

1211
00:45:02,640 --> 00:45:05,840
If the request asks for an external collaboration site,

1212
00:45:05,840 --> 00:45:07,840
the validator checks whether the requester

1213
00:45:07,840 --> 00:45:10,160
is allowed to sponsor external access,

1214
00:45:10,160 --> 00:45:12,360
whether the tenant policy allows it

1215
00:45:12,360 --> 00:45:15,520
and whether the right collaboration zone exists.

1216
00:45:15,520 --> 00:45:18,080
If the request fails validation, it stops here,

1217
00:45:18,080 --> 00:45:19,600
cleanly, with a reason.

1218
00:45:19,600 --> 00:45:22,040
The goal is to fail fast before anything exists.

1219
00:45:22,040 --> 00:45:22,920
Then approval.

1220
00:45:22,920 --> 00:45:23,880
This is the risk gate.

1221
00:45:23,880 --> 00:45:26,480
The approver isn't someone in IT.

1222
00:45:26,480 --> 00:45:28,880
It's the authority that owns the risk, business owner

1223
00:45:28,880 --> 00:45:32,080
for the workspace plus, when required, compliance,

1224
00:45:32,080 --> 00:45:34,600
or security for specific data classes.

1225
00:45:34,600 --> 00:45:36,760
The approval object is stored as evidence,

1226
00:45:36,760 --> 00:45:38,600
who approved what they approved

1227
00:45:38,600 --> 00:45:40,560
and what policy profile was applied.

1228
00:45:40,560 --> 00:45:42,080
And if you can't reconstruct that later,

1229
00:45:42,080 --> 00:45:44,520
you don't have governance, you have folklore.

1230
00:45:44,520 --> 00:45:46,560
Now the actual provisioning path, Microsoft Graph,

1231
00:45:46,560 --> 00:45:49,160
Graph creates the site, but the provisioning service

1232
00:45:49,160 --> 00:45:50,800
owns the choreography.

1233
00:45:50,800 --> 00:45:54,360
Site creation, hub association, baseline site settings,

1234
00:45:54,360 --> 00:45:57,000
default sharing posture, feature toggles that matter,

1235
00:45:57,000 --> 00:45:59,600
library creation, list creation, navigation, homepage,

1236
00:45:59,600 --> 00:46:01,720
this is where teams get tempted to embed logic

1237
00:46:01,720 --> 00:46:04,440
into a 200 step flow, don't.

1238
00:46:04,440 --> 00:46:06,440
The provisioning service should be one unit,

1239
00:46:06,440 --> 00:46:08,600
versioned, testable, and repeatable.

1240
00:46:08,600 --> 00:46:09,880
If you can't redeploy it safely,

1241
00:46:09,880 --> 00:46:11,560
you'll end up with old sites and new sites

1242
00:46:11,560 --> 00:46:13,520
that behave differently, and then your support team

1243
00:46:13,520 --> 00:46:16,440
lives in a split-brainer state, permissions are applied next,

1244
00:46:16,440 --> 00:46:18,080
and they are not optional.

1245
00:46:18,080 --> 00:46:20,200
Owners and members map to entra-groups,

1246
00:46:20,200 --> 00:46:22,600
nested groups where you need roll separation.

1247
00:46:22,600 --> 00:46:24,680
No direct assignments because direct assignments

1248
00:46:24,680 --> 00:46:27,680
don't scale and they don't survive staff turnover.

1249
00:46:27,680 --> 00:46:29,480
The provisioning service sets the groups,

1250
00:46:29,480 --> 00:46:32,480
assigns them to the site, and writes the group IDs

1251
00:46:32,480 --> 00:46:35,200
back into the site metadata or a central inventory,

1252
00:46:35,200 --> 00:46:37,000
so you can later prove which group

1253
00:46:37,000 --> 00:46:38,760
was supposed to control access.

1254
00:46:38,760 --> 00:46:40,720
Now the part that makes this actually scale,

1255
00:46:40,720 --> 00:46:42,360
queue-based orchestration.

1256
00:46:42,360 --> 00:46:44,760
The intake and approval pipeline should not do the work.

1257
00:46:44,760 --> 00:46:46,800
It should include the work, a queue message includes

1258
00:46:46,800 --> 00:46:48,760
the request ID, the target site profile,

1259
00:46:48,760 --> 00:46:51,400
the damp-potency key, and the desired state,

1260
00:46:51,400 --> 00:46:54,160
then workers pull from the queue and execute provisioning steps.

1261
00:46:54,160 --> 00:46:56,080
Why? Because you need retries, you need back-off,

1262
00:46:56,080 --> 00:46:57,760
and you need to survive graph throttling

1263
00:46:57,760 --> 00:47:00,240
without turning provisioning into a timeout festival.

1264
00:47:00,240 --> 00:47:02,080
IDem potency is the hard requirement.

1265
00:47:02,080 --> 00:47:04,160
If the same request gets processed twice,

1266
00:47:04,160 --> 00:47:07,160
the second run must detect this site already exists,

1267
00:47:07,160 --> 00:47:09,400
and converge it to the desired configuration,

1268
00:47:09,400 --> 00:47:10,600
not create a duplicate.

1269
00:47:10,600 --> 00:47:13,840
That means the system keeps a durable state record.

1270
00:47:13,840 --> 00:47:16,040
Request received approved site-created,

1271
00:47:16,040 --> 00:47:19,080
hub-joined permissions applied baseline configured registration

1272
00:47:19,080 --> 00:47:19,680
completed.

1273
00:47:19,680 --> 00:47:22,200
If a worker dies halfway, the next worker resumes.

1274
00:47:22,200 --> 00:47:23,200
No guesswork.

1275
00:47:23,200 --> 00:47:25,160
Retries are engineered, not hoped for.

1276
00:47:25,160 --> 00:47:26,960
Transient graph errors get retried

1277
00:47:26,960 --> 00:47:28,400
with exponential back-off.

1278
00:47:28,400 --> 00:47:30,760
Permanent errors get sent to a dead-letter queue

1279
00:47:30,760 --> 00:47:33,400
with the full context needed to replay safely,

1280
00:47:33,400 --> 00:47:35,080
and replay isn't click-run again for it.

1281
00:47:35,080 --> 00:47:37,040
Replay is, re-inqueue the same request

1282
00:47:37,040 --> 00:47:39,840
with the same IDem potency key and let the system converge.

1283
00:47:39,840 --> 00:47:42,520
Finally, registration and reporting.

1284
00:47:42,520 --> 00:47:45,120
Every provisioned site is written to an inventory.

1285
00:47:45,120 --> 00:47:48,360
Purpose, owner group, sensitivity expectations,

1286
00:47:48,360 --> 00:47:51,920
external collaboration status, and life cycle policy.

1287
00:47:51,920 --> 00:47:54,160
This inventory feeds monitoring and governance.

1288
00:47:54,160 --> 00:47:56,240
It's also how you answer the only question leaders

1289
00:47:56,240 --> 00:47:59,920
care about during audits, how many exist, who owns them,

1290
00:47:59,920 --> 00:48:01,120
and are they compliant?

1291
00:48:01,120 --> 00:48:03,360
That's the reference architecture, contract intake,

1292
00:48:03,360 --> 00:48:05,960
policy validation, explicit approval evidence,

1293
00:48:05,960 --> 00:48:08,480
graph-based provisioning, group first permissions,

1294
00:48:08,480 --> 00:48:11,120
and queue-driven orchestration with IDem potency.

1295
00:48:11,120 --> 00:48:12,120
It's not glamorous.

1296
00:48:12,120 --> 00:48:13,200
It's operable.

1297
00:48:13,200 --> 00:48:15,440
Scenario one, SharePoint Native layer,

1298
00:48:15,440 --> 00:48:19,000
Quick steps and integrated workflows as front ends.

1299
00:48:19,000 --> 00:48:20,720
Now comes the part that confuses people

1300
00:48:20,720 --> 00:48:23,880
because they think provisioning ends when the site exists.

1301
00:48:23,880 --> 00:48:24,720
It doesn't.

1302
00:48:24,720 --> 00:48:27,320
Provisioning ends when users can do the right thing by default.

1303
00:48:27,320 --> 00:48:30,520
This is where SharePoint Native automation features fit.

1304
00:48:30,520 --> 00:48:34,480
Quick steps, integrated workflows, and lightweight approvals,

1305
00:48:34,480 --> 00:48:35,840
not as the provisioning system,

1306
00:48:35,840 --> 00:48:37,880
but as the front ends that let humans interact

1307
00:48:37,880 --> 00:48:40,360
with the factory without having to understand the factory.

1308
00:48:40,360 --> 00:48:42,240
Start with Quick steps.

1309
00:48:42,240 --> 00:48:44,800
In this architecture, Quick steps are not random convenience

1310
00:48:44,800 --> 00:48:47,160
buttons created by whoever has edit rights.

1311
00:48:47,160 --> 00:48:49,960
Quick steps are standardized in vocation points.

1312
00:48:49,960 --> 00:48:53,120
The sanctioned set of actions uses can take on content

1313
00:48:53,120 --> 00:48:55,920
that will always root into the governed automation path.

1314
00:48:55,920 --> 00:48:58,880
That means you treat Quick steps like an API surface.

1315
00:48:58,880 --> 00:49:01,440
You decide which actions exist beside template.

1316
00:49:01,440 --> 00:49:04,320
You decide which libraries get which Quick steps,

1317
00:49:04,320 --> 00:49:06,760
and you decide what those Quick steps are allowed to trigger.

1318
00:49:06,760 --> 00:49:09,080
Because the biggest mistake is letting every library owner

1319
00:49:09,080 --> 00:49:12,800
invent their own buttons and accidentally create a shadow process landscape.

1320
00:49:12,800 --> 00:49:16,840
The simple pattern is, Quick steps give users consistent verbs,

1321
00:49:16,840 --> 00:49:18,040
submit for review.

1322
00:49:18,040 --> 00:49:19,320
Request external share.

1323
00:49:19,320 --> 00:49:20,280
Move to funded.

1324
00:49:20,280 --> 00:49:21,200
Create case.

1325
00:49:21,200 --> 00:49:23,800
Those verbs should map to explicit metadata transitions,

1326
00:49:23,800 --> 00:49:25,240
not direct side effects.

1327
00:49:25,240 --> 00:49:28,760
A Quick step that sets status from draft to submit it is predictable.

1328
00:49:28,760 --> 00:49:32,040
A Quick step that moves files between libraries, changes permissions,

1329
00:49:32,040 --> 00:49:34,280
and emails external recipients is not.

1330
00:49:34,280 --> 00:49:37,400
Side effects belong in orchestration, not in UI buttons.

1331
00:49:37,400 --> 00:49:40,840
So you design Quick steps to do one job, mark intent.

1332
00:49:40,840 --> 00:49:42,800
Then your pipeline listens for that intent

1333
00:49:42,800 --> 00:49:45,920
and executes the controlled steps behind it.

1334
00:49:45,920 --> 00:49:49,560
This also makes idempotency easier because status change to submitted

1335
00:49:49,560 --> 00:49:51,560
becomes your stable event rather than user

1336
00:49:51,560 --> 00:49:54,320
click the button five times because the UI lagged.

1337
00:49:54,320 --> 00:49:55,880
Now integrated workflows.

1338
00:49:55,880 --> 00:49:59,080
Microsoft is bringing a workflows UX into SharePoint

1339
00:49:59,080 --> 00:50:03,240
that looks like Teams workflows, templates, pre-configured connections,

1340
00:50:03,240 --> 00:50:06,840
simple edits, and a build from scratch path.

1341
00:50:06,840 --> 00:50:09,480
For enterprise automation, the value isn't that it's easier to build.

1342
00:50:09,480 --> 00:50:13,040
The value is that it's easier to standardize if you treat it correctly.

1343
00:50:13,040 --> 00:50:15,520
Integrated workflows should exist as approved templates

1344
00:50:15,520 --> 00:50:19,360
that implement front and patterns, notifications, reminders, lightweight

1345
00:50:19,360 --> 00:50:21,320
routing, and simple post-approval steps

1346
00:50:21,320 --> 00:50:23,680
that don't cross major governance boundaries.

1347
00:50:23,680 --> 00:50:26,760
They're allowed to accelerate the last mile of team productivity

1348
00:50:26,760 --> 00:50:28,680
because they run inside the site context

1349
00:50:28,680 --> 00:50:30,360
and make the experience cohesive.

1350
00:50:30,360 --> 00:50:32,160
But the system law stays intact.

1351
00:50:32,160 --> 00:50:35,080
Anything that looks like a backend service does not live here.

1352
00:50:35,080 --> 00:50:37,520
Provisioning doesn't live here, life cycle doesn't live here,

1353
00:50:37,520 --> 00:50:41,280
compliance enforcement doesn't live here, high volume event processing doesn't live here.

1354
00:50:41,280 --> 00:50:44,160
Those belong in the central orchestration layer you already designed

1355
00:50:44,160 --> 00:50:46,680
because you need versioning, deployment control,

1356
00:50:46,680 --> 00:50:49,600
retries, and a single place to observe system behavior.

1357
00:50:49,600 --> 00:50:52,560
So the enterprise rule is SharePoint native workflows

1358
00:50:52,560 --> 00:50:54,720
are front ends, not foundations.

1359
00:50:54,720 --> 00:50:56,680
They handle the human facing edges.

1360
00:50:56,680 --> 00:51:00,640
The places where people start a process, get notified, provide input,

1361
00:51:00,640 --> 00:51:01,640
and see status.

1362
00:51:01,640 --> 00:51:04,240
The moment the workflow needs to do something irreversible

1363
00:51:04,240 --> 00:51:07,680
cross boundary or high risk, it hands off to the central pipeline

1364
00:51:07,680 --> 00:51:11,720
through a controlled mechanism, a queue message, a call to a function,

1365
00:51:11,720 --> 00:51:15,640
or a standardized connector action that hits your orchestration endpoint,

1366
00:51:15,640 --> 00:51:19,880
that handoff is the line between team automation and enterprise automation.

1367
00:51:19,880 --> 00:51:23,800
Now the ugly feature, execute flow inside quick steps.

1368
00:51:23,800 --> 00:51:27,760
It's powerful because it turns any document library into a launch pad for process.

1369
00:51:27,760 --> 00:51:31,240
It's dangerous because it turns any document library into a launch pad for process.

1370
00:51:31,240 --> 00:51:33,760
The governance issue isn't that it can trigger a flow.

1371
00:51:33,760 --> 00:51:38,520
The issue is that it can trigger a flow that lives outside the mental model of the site.

1372
00:51:38,520 --> 00:51:41,400
And because it can target flows outside the default environment,

1373
00:51:41,400 --> 00:51:44,600
you can end up with a button in a library that invokes automation

1374
00:51:44,600 --> 00:51:49,120
in an environment your governance team doesn't associate with that site's risk profile.

1375
00:51:49,120 --> 00:51:52,880
So the control is simple, don't govern flows, govern invocation.

1376
00:51:52,880 --> 00:51:55,040
Only approved quick steps can execute flows.

1377
00:51:55,040 --> 00:51:57,880
Only approved flows can be executed from quick steps.

1378
00:51:57,880 --> 00:52:01,440
And those approvals need to be enforced by environment strategy and ownership rules,

1379
00:52:01,440 --> 00:52:03,080
not by please don't.

1380
00:52:03,080 --> 00:52:07,080
This is where power platform governance intersects with SharePoint design.

1381
00:52:07,080 --> 00:52:10,880
If your environment strategy is loose, quick steps become a convenient bypass.

1382
00:52:10,880 --> 00:52:15,080
If your environment strategy is strict, quick steps become a safe accelerator.

1383
00:52:15,080 --> 00:52:20,200
Now talk about accountability because enterprise workflows don't fail gracefully when nobody owns them.

1384
00:52:20,200 --> 00:52:24,120
SharePoints workflows pay and exposes things like run history and owners.

1385
00:52:24,120 --> 00:52:27,840
That's useful, but it's not enough unless you standardize ownership as a requirement.

1386
00:52:27,840 --> 00:52:30,480
Every workflow must have an owner group, not a person.

1387
00:52:30,480 --> 00:52:35,160
Every workflow must emit failure signals to a monitored channel, not to someone's inbox.

1388
00:52:35,160 --> 00:52:38,880
And every workflow must be tied to the site inventory so you can answer

1389
00:52:38,880 --> 00:52:42,280
what automations exist here, who owns them and what happens when they break.

1390
00:52:42,280 --> 00:52:47,880
This is also why the SharePoint native layer should be deployed through templates, not created ad hoc.

1391
00:52:47,880 --> 00:52:51,800
The template defines the quick steps, the allowed workflows, the approval settings,

1392
00:52:51,800 --> 00:52:54,000
and the metadata columns that represent state.

1393
00:52:54,000 --> 00:52:57,600
Users get a clean experience, the enterprise gets a predictable control surface.

1394
00:52:57,600 --> 00:53:00,600
And with that, the front end and the factory finally align.

1395
00:53:00,600 --> 00:53:05,320
People click a simple button, metadata moves to a new state, the event pipeline triggers,

1396
00:53:05,320 --> 00:53:10,080
the orchestration executes, and enforcement applies labels, permissions, and logging.

1397
00:53:10,080 --> 00:53:12,560
The UI stays simple, the architecture stays real.

1398
00:53:12,560 --> 00:53:16,800
Scenario one, lifecycle enforcement archive, log transfer ownership, retire.

1399
00:53:16,800 --> 00:53:20,760
Lifecycle enforcement is the part everyone agrees with in theory and then quietly avoids

1400
00:53:20,760 --> 00:53:24,080
because it forces the organization to admit something uncomfortable.

1401
00:53:24,080 --> 00:53:26,240
Workspaces are liabilities.

1402
00:53:26,240 --> 00:53:28,600
A SharePoint site is not a place to collaborate.

1403
00:53:28,600 --> 00:53:32,120
It's a permission boundary, a data container, and a long-term obligation.

1404
00:53:32,120 --> 00:53:36,760
If the lifecycle is optional, your automation program doesn't scale into productivity.

1405
00:53:36,760 --> 00:53:39,320
It scales into an estate, you can't explain.

1406
00:53:39,320 --> 00:53:43,160
So the lifecycle pattern has to be designed like enforcement, not like reminders.

1407
00:53:43,160 --> 00:53:47,040
Start with inactivity handling because that's the cleanest signal you'll ever get.

1408
00:53:47,040 --> 00:53:52,280
A site stops being used, file stop changing, pages stop being edited, membership stops shifting.

1409
00:53:52,280 --> 00:53:55,520
And yes, there are edge cases, a site can be quiet and still important.

1410
00:53:55,520 --> 00:53:57,520
That's why the system doesn't delete first.

1411
00:53:57,520 --> 00:54:02,720
It detects, then it notifies, then it escalates, then it enforces.

1412
00:54:02,720 --> 00:54:04,720
A scalable policy looks like this.

1413
00:54:04,720 --> 00:54:08,880
After end days of inactivity, notify the owner group with a simple choice.

1414
00:54:08,880 --> 00:54:11,520
Extend, archive, or retire.

1415
00:54:11,520 --> 00:54:14,480
If they extend, they must supply a reason and an end date.

1416
00:54:14,480 --> 00:54:17,720
That reason becomes evidence, not because auditors love text fields,

1417
00:54:17,720 --> 00:54:21,240
but because future humans need to understand why the exception existed.

1418
00:54:21,240 --> 00:54:23,920
If nobody responds, the system does what humans always avoid.

1419
00:54:23,920 --> 00:54:24,920
It proceeds.

1420
00:54:24,920 --> 00:54:27,240
Archival is not a vibe, it's a state transition.

1421
00:54:27,240 --> 00:54:31,400
Archived means membership is locked down, editing is restricted,

1422
00:54:31,400 --> 00:54:37,320
external sharing is disabled, and the site becomes read only, or near read only, depending on your policy.

1423
00:54:37,320 --> 00:54:41,800
If the business needs to reopen it, they can, but reopening is an explicit action

1424
00:54:41,800 --> 00:54:45,880
with an audit trail, not an accident caused by someone stumbling into ad member,

1425
00:54:45,880 --> 00:54:50,440
then you implement locking because some content should remain accessible but not mutable.

1426
00:54:50,440 --> 00:54:54,640
Locking is the difference between we kept it and we preserved evidence.

1427
00:54:54,640 --> 00:54:59,840
Now if a project is over, you don't want someone to upload final documents six months later and rewrite history.

1428
00:54:59,840 --> 00:55:02,080
So the policy defines when the system locks.

1429
00:55:02,080 --> 00:55:07,320
Project end date, contract termination, regulatory trigger, or a status transition like closed.

1430
00:55:07,320 --> 00:55:12,080
The lock should be enforced by permission changes and sharing posture, not by telling users to behave.

1431
00:55:12,080 --> 00:55:15,760
Now ownership often sites are the default outcome of staff turnover.

1432
00:55:15,760 --> 00:55:19,360
People change roles, leave the company, or stop caring about the project.

1433
00:55:19,360 --> 00:55:24,560
If site ownership is tied to individuals, the system will inevitably lose its accountable humans

1434
00:55:24,560 --> 00:55:28,880
and your life cycle engine becomes a dead process, emailing an empty inbox.

1435
00:55:28,880 --> 00:55:31,440
So ownership enforcement is an identity workflow.

1436
00:55:31,440 --> 00:55:36,080
On a schedule, the system checks whether the owner group still has active human owners.

1437
00:55:36,080 --> 00:55:39,520
If not, it triggers a transfer policy, notify the business unit sponsor,

1438
00:55:39,520 --> 00:55:42,720
require reassignment within a time window, and if that doesn't happen,

1439
00:55:42,720 --> 00:55:48,560
the site moves to a restricted state, not deleted, restricted, because unowned mutable collaboration zones

1440
00:55:48,560 --> 00:55:51,920
are how data leaks and governance collapses, and yes, this feels harsh.

1441
00:55:51,920 --> 00:55:52,720
Good.

1442
00:55:52,720 --> 00:55:54,800
Harsh is what prevents your future incident review.

1443
00:55:54,800 --> 00:55:59,520
The next step is content hygiene, which is where people want magic and the platform provides reality.

1444
00:55:59,520 --> 00:56:05,200
Stale pages, broken links, duplicate documents, and we have five versions of the same policy in five sites.

1445
00:56:05,200 --> 00:56:07,920
Some of this can be detected, some of it can't.

1446
00:56:07,920 --> 00:56:09,840
The architecture principle stays simple.

1447
00:56:09,840 --> 00:56:13,120
Hygiene is a signal generator, not a cleanup promise.

1448
00:56:13,120 --> 00:56:15,920
So you run periodic scans where capabilities exist.

1449
00:56:15,920 --> 00:56:20,160
Detect orphaned pages, detect broken links, detect duplicate files by hash,

1450
00:56:20,160 --> 00:56:24,160
where your tooling supports it, flag libraries with extreme item counts,

1451
00:56:24,160 --> 00:56:27,120
and flag unlabeled content in high risk locations.

1452
00:56:27,120 --> 00:56:30,080
The outcome isn't the system fixes everything.

1453
00:56:30,080 --> 00:56:34,240
The outcome is the system produces a prioritized backlog for the owner group,

1454
00:56:34,240 --> 00:56:38,400
and it can gait future automation on unresolved hygiene when risk requires it.

1455
00:56:38,400 --> 00:56:43,840
Now automation failure handling, because life cycle workflows are long running and long running workflows fail.

1456
00:56:43,840 --> 00:56:47,200
At scale, a life cycle engine needs dead letter patterns.

1457
00:56:47,200 --> 00:56:51,200
When an archive action fails, the message goes to a dead letter queue with context,

1458
00:56:51,200 --> 00:56:52,720
not to a buried run history.

1459
00:56:52,720 --> 00:56:54,080
It needs retreats with back off.

1460
00:56:54,080 --> 00:56:59,280
It needs idempotency, so you don't lock and unlock repeatedly because of duplicate events.

1461
00:56:59,280 --> 00:57:01,920
And it needs a human override path that's logged in time bound,

1462
00:57:01,920 --> 00:57:05,040
because someone fixed it manually is not an operational model.

1463
00:57:05,040 --> 00:57:07,760
The retirement step is the one everyone wants to skip.

1464
00:57:07,760 --> 00:57:11,520
Retire means content is disposed according to retention policy.

1465
00:57:11,520 --> 00:57:15,200
The site is deleted when it is legally allowed, and the inventory record is updated,

1466
00:57:15,200 --> 00:57:16,640
so you can prove it happened.

1467
00:57:16,640 --> 00:57:19,280
Retire is not a button, it's a governed outcome.

1468
00:57:19,280 --> 00:57:21,360
And the whole life cycle model has one purpose.

1469
00:57:21,360 --> 00:57:25,360
Keep your share point automation estate converging toward policy over time,

1470
00:57:25,360 --> 00:57:26,880
instead of drifting away from it.

1471
00:57:26,880 --> 00:57:31,360
Because automation doesn't create order, enforcement does, scenario two framing.

1472
00:57:31,360 --> 00:57:33,920
Compliance isn't a project, it's continuous evidence.

1473
00:57:33,920 --> 00:57:36,880
Compliance is where we'll clean it up later, goes to die.

1474
00:57:36,880 --> 00:57:39,520
Because leaders keep treating compliance like a project,

1475
00:57:39,520 --> 00:57:42,160
hire someone right-of-policy runner-migration,

1476
00:57:42,160 --> 00:57:44,320
do an audit, celebrate, and move on.

1477
00:57:44,320 --> 00:57:46,400
That model works only if content stops changing.

1478
00:57:46,400 --> 00:57:47,920
SharePoint does not stop changing.

1479
00:57:47,920 --> 00:57:49,920
Automation makes it change faster.

1480
00:57:49,920 --> 00:57:51,760
AI makes it change in more places at once,

1481
00:57:51,760 --> 00:57:53,360
so compliance can't be an initiative.

1482
00:57:53,360 --> 00:57:55,360
It has to be a continuous evidence system.

1483
00:57:55,360 --> 00:57:59,280
That distinction matters because regulators don't ask whether you had good intentions.

1484
00:57:59,280 --> 00:58:01,040
They ask whether you can prove outcomes.

1485
00:58:01,040 --> 00:58:03,840
Retention happened, holes were honored, access was controlled,

1486
00:58:03,840 --> 00:58:05,760
and you can reconstruct who did what,

1487
00:58:05,760 --> 00:58:09,360
to which record, under which authority, at which time.

1488
00:58:09,360 --> 00:58:12,240
And proof means evidence you can generate on demand.

1489
00:58:12,240 --> 00:58:14,480
Not a spreadsheet someone updated manually,

1490
00:58:14,480 --> 00:58:15,920
not a screenshot from a portal,

1491
00:58:15,920 --> 00:58:18,960
not a story that begins with, normally, our process is.

1492
00:58:18,960 --> 00:58:21,520
The compliance reality is this.

1493
00:58:21,520 --> 00:58:25,760
Once automation exists, the blast radius of a failure becomes a legal event.

1494
00:58:25,760 --> 00:58:28,800
If a workflow mis-roots a document underhold,

1495
00:58:28,800 --> 00:58:31,520
or a label gets skipped, or a library becomes overshared,

1496
00:58:31,520 --> 00:58:34,080
and an agent surfaces it, the impact isn't only technical,

1497
00:58:34,080 --> 00:58:35,280
it's defensibility.

1498
00:58:35,280 --> 00:58:37,520
So scenario two is built around one idea.

1499
00:58:37,520 --> 00:58:41,280
Compliance is continuous because the system never stops producing new content,

1500
00:58:41,280 --> 00:58:43,840
new copies, new links, and new access parts.

1501
00:58:43,840 --> 00:58:46,400
Start with the regulatory requirements you actually face.

1502
00:58:46,400 --> 00:58:49,440
Retention and disposal, what must be kept,

1503
00:58:49,440 --> 00:58:51,920
for how long, and what must be deleted when allowed.

1504
00:58:51,920 --> 00:58:56,560
Legal hold, what must be preserved immediately and indefinitely when a case triggers it.

1505
00:58:56,560 --> 00:59:00,720
Immutability, where records must not be altered even by administrators.

1506
00:59:00,720 --> 00:59:05,120
Audit trail, the ability to show a chain of custody for content and decisions.

1507
00:59:05,120 --> 00:59:07,280
Those aren't features, their system properties.

1508
00:59:07,280 --> 00:59:10,640
And this is where organizations make the foundational mistake,

1509
00:59:10,640 --> 00:59:13,280
they try to bolt these properties onto a chaotic estate.

1510
00:59:13,280 --> 00:59:16,880
They treat records management as a set of labels you apply after the fact.

1511
00:59:16,880 --> 00:59:19,680
But at scale, retroactive compliance is fantasy.

1512
00:59:19,680 --> 00:59:21,680
It always becomes a backlog that never ends,

1513
00:59:21,680 --> 00:59:24,880
because the platform produces content faster than you can classify it.

1514
00:59:24,880 --> 00:59:26,000
So the framing has to flip.

1515
00:59:26,000 --> 00:59:28,800
Compliance begins at creation, not at audit time.

1516
00:59:28,800 --> 00:59:31,280
That leads directly into the records model,

1517
00:59:31,280 --> 00:59:33,760
because compliance isn't just keep everything.

1518
00:59:33,760 --> 00:59:35,920
You have to define what becomes a record,

1519
00:59:35,920 --> 00:59:38,960
when it becomes a record, and who has the authority to declare it.

1520
00:59:38,960 --> 00:59:42,240
A draft contract in negotiation is not the same as an executed contract.

1521
00:59:42,240 --> 00:59:45,360
A policy page in progress is not the same as an approved policy.

1522
00:59:45,360 --> 00:59:48,720
A project document under review is not the same as the final deliverable

1523
00:59:48,720 --> 00:59:50,320
that drives a regulated decision.

1524
00:59:50,320 --> 00:59:52,560
If you don't encode that difference into the system,

1525
00:59:52,560 --> 00:59:55,600
you end up retaining everything forever because nobody trusts,

1526
00:59:55,600 --> 00:59:57,360
disposal, then storage explodes.

1527
00:59:57,360 --> 01:00:00,720
Discovery becomes impossible, and audits become painful.

1528
01:00:00,720 --> 01:00:04,560
So the records model has to be expressed as deterministic state transitions.

1529
01:00:04,560 --> 01:00:06,640
Approved becomes record.

1530
01:00:07,280 --> 01:00:08,880
Published becomes record.

1531
01:00:08,880 --> 01:00:11,040
Case opened, applies, hold.

1532
01:00:11,040 --> 01:00:13,440
That's the only model that scales because it ties compliance

1533
01:00:13,440 --> 01:00:15,680
to workflow outcomes the platform can observe.

1534
01:00:15,680 --> 01:00:17,920
Now, here's the part people try to negotiate.

1535
01:00:17,920 --> 01:00:18,880
Label first.

1536
01:00:18,880 --> 01:00:22,080
They want to treat labeling as optional because it slows users down.

1537
01:00:22,080 --> 01:00:25,280
But in compliance workloads, label first is not optional.

1538
01:00:25,280 --> 01:00:27,920
It's the only scalable classifier under pressure.

1539
01:00:27,920 --> 01:00:30,480
Without labels, retention policies can't target correctly,

1540
01:00:30,480 --> 01:00:32,400
DLP can't reason consistently,

1541
01:00:32,400 --> 01:00:34,240
and audit evidence becomes ambiguous.

1542
01:00:34,240 --> 01:00:37,440
And ambiguities what gets organizations hurt in audits.

1543
01:00:37,440 --> 01:00:40,800
So the compliance blueprint forces label assignment into the system.

1544
01:00:40,800 --> 01:00:43,680
Templates apply default sensitivity expectations.

1545
01:00:43,680 --> 01:00:46,960
Workflows validate labeling before moving content across boundaries.

1546
01:00:46,960 --> 01:00:50,080
Approval completion triggers retention outcomes where required,

1547
01:00:50,080 --> 01:00:52,160
and exceptions are not allowed silently.

1548
01:00:52,160 --> 01:00:56,240
If something can't be labeled, it goes into an exception lane with an owner and a timer.

1549
01:00:56,240 --> 01:00:57,600
That's what leaders need to understand.

1550
01:00:57,600 --> 01:01:00,240
You don't get compliance by asking people to care.

1551
01:01:00,240 --> 01:01:04,160
You get compliance by making the compliant path the path of least resistance.

1552
01:01:04,160 --> 01:01:06,640
Now, layer in the continuous evidence part.

1553
01:01:06,640 --> 01:01:09,200
Continuous evidence means the system continuously

1554
01:01:09,200 --> 01:01:10,720
emits proof artifacts.

1555
01:01:10,720 --> 01:01:13,840
Label applied events, retention policy evaluation,

1556
01:01:13,840 --> 01:01:17,200
sharing decisions, access changes, and workflow actions

1557
01:01:17,200 --> 01:01:18,800
that affect records state.

1558
01:01:18,800 --> 01:01:22,240
It also means the organization can answer hard questions quickly.

1559
01:01:22,240 --> 01:01:24,320
Show all records in this category.

1560
01:01:24,320 --> 01:01:25,920
Show all items under hold.

1561
01:01:25,920 --> 01:01:28,400
Show all external shares for labeled content.

1562
01:01:28,400 --> 01:01:32,560
Show all workflows that moved content out of a retention scope location.

1563
01:01:32,560 --> 01:01:35,520
If that query requires five teams in two weeks, you don't have evidence.

1564
01:01:35,520 --> 01:01:37,200
You have organizational memory.

1565
01:01:37,200 --> 01:01:40,560
An organizational memory fails exactly when you need it most.

1566
01:01:40,560 --> 01:01:42,960
So scenario two isn't how to do retention.

1567
01:01:42,960 --> 01:01:45,200
It's how to design an enterprise compliance plane

1568
01:01:45,200 --> 01:01:48,080
that stays true as automation accelerates change.

1569
01:01:48,080 --> 01:01:49,840
Deterministic records state.

1570
01:01:49,840 --> 01:01:51,920
Label first classification, enforced holds,

1571
01:01:51,920 --> 01:01:54,800
and evidence you can stream into monitoring and investigations.

1572
01:01:54,800 --> 01:01:56,640
And once that framing is clear,

1573
01:01:56,640 --> 01:01:58,480
the next section becomes straightforward.

1574
01:01:58,480 --> 01:01:59,680
The actual architecture,

1575
01:01:59,680 --> 01:02:03,120
purview for retention and labels, DLP as runtime enforcement,

1576
01:02:03,120 --> 01:02:05,360
and audit streaming for defensibility.

1577
01:02:05,360 --> 01:02:08,400
Scenario two architecture retention, legal hold,

1578
01:02:08,400 --> 01:02:10,400
and audit defensibility by design.

1579
01:02:10,400 --> 01:02:13,680
So the architecture for compliance has to do three things at once.

1580
01:02:13,680 --> 01:02:15,440
Enforced retention outcomes,

1581
01:02:15,440 --> 01:02:17,920
freeze content instantly when legal says so,

1582
01:02:17,920 --> 01:02:21,040
and generate evidence without begging humans for screenshots.

1583
01:02:21,040 --> 01:02:24,640
Start with purview retention labels and retention policies

1584
01:02:24,640 --> 01:02:27,360
because that's where you declare the immutable truth.

1585
01:02:27,360 --> 01:02:30,480
What gets kept for how long and what happens at the end.

1586
01:02:30,480 --> 01:02:32,400
Labels are the per-item truth.

1587
01:02:32,400 --> 01:02:35,040
Policies are the where does this truth apply?

1588
01:02:35,040 --> 01:02:36,480
And in enterprise terms,

1589
01:02:36,480 --> 01:02:39,920
the only design that survives scale is scope intentionally,

1590
01:02:39,920 --> 01:02:42,000
publish intentionally, improve intentionally.

1591
01:02:42,000 --> 01:02:44,480
Scope means you don't spray retention across the tenant

1592
01:02:44,480 --> 01:02:45,440
and hope it works.

1593
01:02:45,440 --> 01:02:48,400
You define locations and categories that map to business purpose,

1594
01:02:48,400 --> 01:02:49,600
a contracts library,

1595
01:02:49,600 --> 01:02:52,080
an HRK site, a finance record center,

1596
01:02:52,080 --> 01:02:53,360
a regulated project hub.

1597
01:02:53,360 --> 01:02:56,160
Then you publish the label or policy into those places

1598
01:02:56,160 --> 01:02:58,160
so the system can defend the claim,

1599
01:02:58,160 --> 01:03:02,400
content of this type in this location follows this rule.

1600
01:03:02,400 --> 01:03:05,360
And yes, that means you need fewer clearer locations

1601
01:03:05,360 --> 01:03:07,280
because retention can't fix architecture.

1602
01:03:07,280 --> 01:03:08,960
It can only enforce what you designed.

1603
01:03:08,960 --> 01:03:09,840
Now legal hold.

1604
01:03:09,840 --> 01:03:13,840
Legal hold is where automation usually embarrasses people

1605
01:03:13,840 --> 01:03:15,760
because the business thinks hold is a label

1606
01:03:15,760 --> 01:03:18,560
and IT thinks hold is an e-discovery case

1607
01:03:18,560 --> 01:03:21,360
and nobody designs the state transition in between.

1608
01:03:21,360 --> 01:03:23,920
Architecturally, a hold is a freeze order

1609
01:03:23,920 --> 01:03:26,640
that must override every convenience feature,

1610
01:03:26,640 --> 01:03:29,680
deletion overrides, clean up scripts,

1611
01:03:29,680 --> 01:03:31,120
life cycle retirement,

1612
01:03:31,120 --> 01:03:33,520
and will just move the files.

1613
01:03:33,520 --> 01:03:36,880
So the blueprint is holds are triggered centrally,

1614
01:03:36,880 --> 01:03:38,400
applied automatically,

1615
01:03:38,400 --> 01:03:41,840
and treated as higher priority than every life cycle mechanism.

1616
01:03:41,840 --> 01:03:43,040
If a site is under hold,

1617
01:03:43,040 --> 01:03:45,040
the life cycle engine can still archive it,

1618
01:03:45,040 --> 01:03:46,160
but it cannot dispose it.

1619
01:03:46,160 --> 01:03:48,160
If a record is under hold,

1620
01:03:48,160 --> 01:03:49,440
a workflow can still root it,

1621
01:03:49,440 --> 01:03:51,040
but it cannot transform it into a new

1622
01:03:51,040 --> 01:03:53,920
untracked copy without logging and policy review.

1623
01:03:53,920 --> 01:03:55,040
Holds don't stop work.

1624
01:03:55,040 --> 01:03:56,560
They stop irreversible outcomes.

1625
01:03:56,560 --> 01:03:57,840
That distinction matters.

1626
01:03:57,840 --> 01:04:00,400
Now sensitivity labels.

1627
01:04:00,400 --> 01:04:02,800
Sensitivity is the access expectation layer

1628
01:04:02,800 --> 01:04:04,480
and for compliance it's the difference between

1629
01:04:04,480 --> 01:04:06,560
we retain it and we retain it safely.

1630
01:04:06,560 --> 01:04:09,600
If the organization retains regulated data

1631
01:04:09,600 --> 01:04:10,960
but allows broad sharing,

1632
01:04:10,960 --> 01:04:13,680
then retention just preserves the evidence of failure longer.

1633
01:04:13,680 --> 01:04:15,040
So you use sensitivity labels

1634
01:04:15,040 --> 01:04:16,240
to carry enforcement behaviors

1635
01:04:16,240 --> 01:04:18,160
that align with your compliance model.

1636
01:04:18,160 --> 01:04:19,920
Encryption where required,

1637
01:04:19,920 --> 01:04:22,560
restrictions on external sharing where required,

1638
01:04:22,560 --> 01:04:24,560
and consistent user experience signals.

1639
01:04:24,560 --> 01:04:27,040
So people don't accidentally treat sensitive content

1640
01:04:27,040 --> 01:04:29,040
as general collaboration content.

1641
01:04:29,040 --> 01:04:30,560
And this is where the platform's behavior

1642
01:04:30,560 --> 01:04:31,520
becomes uncomfortable.

1643
01:04:31,520 --> 01:04:32,880
Labels need to be applied early

1644
01:04:32,880 --> 01:04:34,720
because retroactive labeling after exposure

1645
01:04:34,720 --> 01:04:37,040
is just an audit artifact, not protection.

1646
01:04:37,040 --> 01:04:39,440
So your architecture wires labeling into creation

1647
01:04:39,440 --> 01:04:41,120
and into state transitions.

1648
01:04:41,120 --> 01:04:43,200
New site created with a compliance profile

1649
01:04:43,200 --> 01:04:45,520
gets a default sensitivity expectation.

1650
01:04:45,520 --> 01:04:48,160
Content declared as a record gets a label validation step.

1651
01:04:48,160 --> 01:04:51,200
Content moved into a records library gets labeling enforced

1652
01:04:51,200 --> 01:04:53,760
as part of the move, not after it lands.

1653
01:04:53,760 --> 01:04:54,560
Then DLP.

1654
01:04:54,560 --> 01:04:58,320
In this scenario, DLP is the runtime enforcement

1655
01:04:58,320 --> 01:05:00,560
that stops the most common compliance violation

1656
01:05:00,560 --> 01:05:02,400
exporting regulated content into a path

1657
01:05:02,400 --> 01:05:04,640
that retention and hold controls can't see.

1658
01:05:04,640 --> 01:05:06,080
That includes email attachments,

1659
01:05:06,080 --> 01:05:08,080
unmanaged connectors, external shares

1660
01:05:08,080 --> 01:05:10,240
and temporary copies to personal locations.

1661
01:05:10,240 --> 01:05:11,680
DLP doesn't replace retention.

1662
01:05:11,680 --> 01:05:13,680
It protects retention scope boundaries.

1663
01:05:13,680 --> 01:05:16,640
So you design DLP to align with your retention locations

1664
01:05:16,640 --> 01:05:18,400
and your sensitivity labels.

1665
01:05:18,400 --> 01:05:20,560
If content carries a regulated label,

1666
01:05:20,560 --> 01:05:23,120
DLP blocks the obvious exfiltration paths

1667
01:05:23,120 --> 01:05:24,560
and where the business must proceed,

1668
01:05:24,560 --> 01:05:26,560
DLP allows with justification

1669
01:05:26,560 --> 01:05:28,720
and logs the event as a compliance signal.

1670
01:05:28,720 --> 01:05:30,160
Now audit defensibility.

1671
01:05:30,160 --> 01:05:31,920
This is the part everyone says they want,

1672
01:05:31,920 --> 01:05:34,560
but almost nobody implements beyond default logging.

1673
01:05:34,560 --> 01:05:37,440
Defensibility requires correlation,

1674
01:05:37,440 --> 01:05:38,880
a retention decision,

1675
01:05:38,880 --> 01:05:40,240
a hold application,

1676
01:05:40,240 --> 01:05:42,080
a label change, a sharing event,

1677
01:05:42,080 --> 01:05:45,680
and a workflow action all need to be explainable as one narrative.

1678
01:05:45,680 --> 01:05:47,600
So you stream audit logs into a place

1679
01:05:47,600 --> 01:05:49,600
where investigations can actually happen at speed.

1680
01:05:49,600 --> 01:05:52,160
Microsoft's unified audit log gives you the compliance trail

1681
01:05:52,160 --> 01:05:53,920
but you need correlation and detection,

1682
01:05:53,920 --> 01:05:57,120
which means connecting audit signals to Sentinel

1683
01:05:57,120 --> 01:05:59,600
or another seam workflow where you can build queries

1684
01:05:59,600 --> 01:06:01,760
and alerts that answer real questions.

1685
01:06:01,760 --> 01:06:03,760
Show all external shares of content

1686
01:06:03,760 --> 01:06:05,200
with this sensitivity label.

1687
01:06:05,200 --> 01:06:07,600
Show all attempts to delete content under hold,

1688
01:06:07,600 --> 01:06:09,120
show all automation identities

1689
01:06:09,120 --> 01:06:11,600
that modified records libraries show all sites

1690
01:06:11,600 --> 01:06:14,080
where retention policies were removed or changed.

1691
01:06:14,080 --> 01:06:16,160
And because compliance is continuous evidence,

1692
01:06:16,160 --> 01:06:17,840
you don't only investigate incidents,

1693
01:06:17,840 --> 01:06:20,160
you generate proof packs on a schedule.

1694
01:06:20,160 --> 01:06:23,280
For leadership, that means the architecture

1695
01:06:23,280 --> 01:06:25,200
includes reporting by design,

1696
01:06:25,200 --> 01:06:27,120
retention coverage by location,

1697
01:06:27,120 --> 01:06:28,640
hold coverage by case,

1698
01:06:28,640 --> 01:06:30,720
oversharing for regulated labels

1699
01:06:30,720 --> 01:06:33,440
and workflow pathways that touch regulated content.

1700
01:06:33,440 --> 01:06:37,040
If those reports require a one-time project to assemble,

1701
01:06:37,040 --> 01:06:39,120
they won't exist when the auditor asks,

1702
01:06:39,120 --> 01:06:42,240
so the compliance architecture is not turn on retention.

1703
01:06:42,240 --> 01:06:43,200
It is.

1704
01:06:43,200 --> 01:06:46,240
Scoped retention enforcement centralised hold priority,

1705
01:06:46,240 --> 01:06:48,320
label-driven access expectations,

1706
01:06:48,320 --> 01:06:49,920
DLP as boundary protection

1707
01:06:49,920 --> 01:06:52,640
and audit streaming that produces defensible narratives

1708
01:06:52,640 --> 01:06:53,520
without heroics.

1709
01:06:53,520 --> 01:06:56,320
Scenario two workflows,

1710
01:06:56,320 --> 01:06:58,400
lightweight approvals versus custom flows

1711
01:06:58,400 --> 01:07:00,080
versus backend orchestration.

1712
01:07:00,080 --> 01:07:01,600
Now the workflows question,

1713
01:07:01,600 --> 01:07:03,520
because this is where compliance programs

1714
01:07:03,520 --> 01:07:05,520
quietly sabotage themselves.

1715
01:07:05,520 --> 01:07:06,880
They take a regulated process,

1716
01:07:06,880 --> 01:07:08,560
then they scatter its logic across

1717
01:07:08,560 --> 01:07:10,560
whatever automation primitive was easiest

1718
01:07:10,560 --> 01:07:11,840
for the last person who touched it.

1719
01:07:11,840 --> 01:07:13,200
A lightweight approval here,

1720
01:07:13,200 --> 01:07:14,240
a personal flow there,

1721
01:07:14,240 --> 01:07:17,200
a temporary branching workflow in someone's environment.

1722
01:07:17,200 --> 01:07:18,400
Then they call it covered.

1723
01:07:18,400 --> 01:07:21,600
It isn't compliance workflows need one property above all others.

1724
01:07:21,600 --> 01:07:24,080
The decision path must be reconstructable later,

1725
01:07:24,080 --> 01:07:26,080
not just approved or rejected,

1726
01:07:26,080 --> 01:07:27,920
but who approved in what order,

1727
01:07:27,920 --> 01:07:29,120
under what policy,

1728
01:07:29,120 --> 01:07:30,560
with what evidence attached

1729
01:07:30,560 --> 01:07:32,160
and what happened after the approval.

1730
01:07:32,160 --> 01:07:33,680
If you can't replay the logic,

1731
01:07:33,680 --> 01:07:34,960
you can't defend the outcome,

1732
01:07:34,960 --> 01:07:37,600
so pick the primitive based on what must be provable,

1733
01:07:37,600 --> 01:07:39,200
not what is fastest to build.

1734
01:07:39,200 --> 01:07:40,560
Start with lightweight approvals

1735
01:07:40,560 --> 01:07:42,240
in SharePoint lists and libraries.

1736
01:07:42,240 --> 01:07:44,400
They are useful specifically because they keep state

1737
01:07:44,400 --> 01:07:45,200
close to the content,

1738
01:07:45,200 --> 01:07:47,200
the approval status becomes metadata.

1739
01:07:47,200 --> 01:07:48,720
The experience stays in the grid.

1740
01:07:48,720 --> 01:07:50,400
You can define default approvals

1741
01:07:50,400 --> 01:07:52,720
and you can stage and sequence them.

1742
01:07:52,720 --> 01:07:54,880
That's a clean pattern for simple gates.

1743
01:07:54,880 --> 01:07:57,680
This document must be approved before it becomes visible,

1744
01:07:57,680 --> 01:08:00,560
or this item must be reviewed before it gets published.

1745
01:08:00,560 --> 01:08:02,240
And the hidden advantage is governance.

1746
01:08:02,240 --> 01:08:04,240
When the approval status stored on the item,

1747
01:08:04,240 --> 01:08:05,680
it's harder to lose the trail.

1748
01:08:05,680 --> 01:08:07,760
You're not hunting across flow run histories

1749
01:08:07,760 --> 01:08:09,600
and emails to figure out what happened.

1750
01:08:09,600 --> 01:08:12,400
But lightweight approvals have a hard boundary.

1751
01:08:12,400 --> 01:08:14,640
They are not a compliance workflow engine.

1752
01:08:14,640 --> 01:08:16,400
They don't model complex branching,

1753
01:08:16,400 --> 01:08:17,920
conditional attestations,

1754
01:08:17,920 --> 01:08:19,360
dynamic evidence collection,

1755
01:08:19,360 --> 01:08:20,880
or multi-path escalation.

1756
01:08:20,880 --> 01:08:23,840
They also don't replace your need for centralized monitoring.

1757
01:08:23,840 --> 01:08:25,360
They're a front and gate that works

1758
01:08:25,360 --> 01:08:26,560
when the policy is simple

1759
01:08:26,560 --> 01:08:28,480
and the blast radius is contained.

1760
01:08:28,480 --> 01:08:30,400
Now custom power automate approvals.

1761
01:08:30,400 --> 01:08:31,440
This is where people go

1762
01:08:31,440 --> 01:08:33,520
when they need real workflow behavior.

1763
01:08:33,520 --> 01:08:35,200
Branching based on metadata,

1764
01:08:35,200 --> 01:08:36,960
parallel versus sequential approvals,

1765
01:08:36,960 --> 01:08:37,920
conditional routing,

1766
01:08:37,920 --> 01:08:39,920
reminders, SLA's exception handling,

1767
01:08:39,920 --> 01:08:41,440
and recorded justifications.

1768
01:08:41,440 --> 01:08:43,120
And yes, power automate can do it.

1769
01:08:43,120 --> 01:08:44,880
The problem is scale and life cycle.

1770
01:08:44,880 --> 01:08:47,600
A power automate approval flow is a software artifact.

1771
01:08:47,600 --> 01:08:48,560
It needs versioning.

1772
01:08:48,560 --> 01:08:50,080
It needs a deployment model.

1773
01:08:50,080 --> 01:08:52,240
It needs ownership that survives turnover.

1774
01:08:52,240 --> 01:08:53,680
And it needs to be designed

1775
01:08:53,680 --> 01:08:55,600
so that an approver can't be bypassed

1776
01:08:55,600 --> 01:08:58,320
by someone cloning a flow and tweaking one condition.

1777
01:08:58,320 --> 01:09:00,000
The uncomfortable truth is that

1778
01:09:00,000 --> 01:09:02,080
power automate makes it easy to create

1779
01:09:02,080 --> 01:09:04,080
production logic without production discipline.

1780
01:09:04,080 --> 01:09:06,880
That's why compliance teams end up with approval sprawl.

1781
01:09:06,880 --> 01:09:08,560
Dozens of nearly identical flows,

1782
01:09:08,560 --> 01:09:09,680
each slightly different,

1783
01:09:09,680 --> 01:09:11,600
each with its own connector assumptions,

1784
01:09:11,600 --> 01:09:13,520
each with its own failure mode.

1785
01:09:13,520 --> 01:09:14,720
So the rule is strict.

1786
01:09:14,720 --> 01:09:16,880
If you use custom flows for compliance,

1787
01:09:16,880 --> 01:09:19,200
you standardize them as managed assets.

1788
01:09:19,200 --> 01:09:22,560
Solutions, environments naming owners and run visibility.

1789
01:09:22,560 --> 01:09:25,200
No personal flows, no, I'll just fix it in my account.

1790
01:09:25,200 --> 01:09:28,080
EZN says, "Temperties in beer, how is it?"

1791
01:09:28,080 --> 01:09:30,640
That's not automation that's delegated risk.

1792
01:09:30,640 --> 01:09:33,280
Now back-end orchestration logic apps are Azure Functions.

1793
01:09:33,280 --> 01:09:36,000
This is for when the workflow is either high volume,

1794
01:09:36,000 --> 01:09:38,320
high complexity or high consequence.

1795
01:09:38,320 --> 01:09:40,160
High volume means you can't tolerate

1796
01:09:40,160 --> 01:09:43,280
per-run UX, throttles, and fragile connector behavior.

1797
01:09:43,280 --> 01:09:45,520
High complexity means you're transforming content

1798
01:09:45,520 --> 01:09:47,280
calling multiple systems using cues

1799
01:09:47,280 --> 01:09:49,920
and you need deterministic retreatries and idempotency.

1800
01:09:49,920 --> 01:09:53,680
High consequence means a mistake creates legal exposure.

1801
01:09:53,680 --> 01:09:55,760
Records declaration, hold enforcement,

1802
01:09:55,760 --> 01:09:58,560
regulated exports, or irreversible state changes.

1803
01:09:58,560 --> 01:10:00,720
In those cases, the workflow belongs

1804
01:10:00,720 --> 01:10:03,760
in an orchestration layer that behaves like software.

1805
01:10:03,760 --> 01:10:07,440
Source control, deployment pipelines, unit tests where possible,

1806
01:10:07,440 --> 01:10:11,600
structured logging, and a clear separation between decision and execution.

1807
01:10:11,600 --> 01:10:14,160
This is where the approval becomes a service boundary.

1808
01:10:14,160 --> 01:10:16,960
The approval interaction can still happen in SharePoint or Teams

1809
01:10:16,960 --> 01:10:18,800
because humans need a place to click buttons.

1810
01:10:18,800 --> 01:10:20,800
But the system that interprets that approval

1811
01:10:20,800 --> 01:10:23,760
and performs downstream actions lives in the back-end

1812
01:10:23,760 --> 01:10:25,360
where you can actually control it.

1813
01:10:25,360 --> 01:10:27,920
And here's the anti-pattern to call out clearly.

1814
01:10:27,920 --> 01:10:30,800
Approval logic scattered across personal flows.

1815
01:10:30,800 --> 01:10:32,560
That design fails three ways at scale.

1816
01:10:32,560 --> 01:10:35,280
First, it destroys audit defensibility

1817
01:10:35,280 --> 01:10:37,600
because you can't prove which version ran and why.

1818
01:10:37,600 --> 01:10:40,480
Second, it breaks continuity

1819
01:10:40,480 --> 01:10:42,640
because the flow dies when the owner leaves

1820
01:10:42,640 --> 01:10:45,040
or changes their password or loses a license.

1821
01:10:45,040 --> 01:10:47,120
Third, it creates inconsistent enforcement

1822
01:10:47,120 --> 01:10:49,920
because two teams will implement the same policy differently

1823
01:10:49,920 --> 01:10:51,440
and both will swear they're compliant.

1824
01:10:51,440 --> 01:10:52,000
They aren't.

1825
01:10:52,000 --> 01:10:53,440
So the decision matrix is simple.

1826
01:10:53,440 --> 01:10:56,480
If you need a lightweight gate and the state should live on the item,

1827
01:10:56,480 --> 01:10:58,080
use lightweight approvals.

1828
01:10:58,080 --> 01:11:00,560
If you need richer branching, but the process stays inside

1829
01:11:00,560 --> 01:11:02,960
the team boundary use power automate approvals

1830
01:11:02,960 --> 01:11:05,200
but only as a governed managed asset.

1831
01:11:05,200 --> 01:11:07,600
If the workflow crosses systems, crosses tenants,

1832
01:11:07,600 --> 01:11:09,840
touches regulated data at scale

1833
01:11:09,840 --> 01:11:12,160
or must survive organizational entropy,

1834
01:11:12,160 --> 01:11:13,920
move it to back-end orchestration

1835
01:11:13,920 --> 01:11:17,040
and treat approvals as inputs, not as the engine.

1836
01:11:17,040 --> 01:11:18,560
And that sets up the next scenario

1837
01:11:18,560 --> 01:11:20,720
because external collaboration is where approval

1838
01:11:20,720 --> 01:11:23,440
stop being workflow questions and become boundary questions.

1839
01:11:23,440 --> 01:11:24,640
Scenario three framing.

1840
01:11:24,640 --> 01:11:26,480
External sharing is a controlled zone,

1841
01:11:26,480 --> 01:11:27,920
not a per-side preference.

1842
01:11:27,920 --> 01:11:29,600
External sharing is where SharePoint

1843
01:11:29,600 --> 01:11:30,880
stops being collaboration

1844
01:11:30,880 --> 01:11:33,520
and becomes a boundary negotiation with your legal team.

1845
01:11:33,520 --> 01:11:35,600
And the foundational mistake is predictable.

1846
01:11:35,600 --> 01:11:39,040
Organizations treat external sharing as a per-side preference,

1847
01:11:39,040 --> 01:11:42,080
a toggle, a convenient setting the site owner can adjust

1848
01:11:42,080 --> 01:11:44,400
when the partner relationship feels urgent.

1849
01:11:44,400 --> 01:11:45,760
That model is not governance,

1850
01:11:45,760 --> 01:11:47,760
it's delegated risk with a ribbon on it

1851
01:11:47,760 --> 01:11:50,880
because once you allow external sharing as a local preference,

1852
01:11:50,880 --> 01:11:53,200
you don't get one external sharing posture.

1853
01:11:53,200 --> 01:11:55,600
You get hundreds, each one with different link types,

1854
01:11:55,600 --> 01:11:58,240
different expiration behaviors, different guest controls

1855
01:11:58,240 --> 01:12:00,960
and different expectations about what safe means.

1856
01:12:00,960 --> 01:12:02,960
Then the business asks for co-pilot.

1857
01:12:02,960 --> 01:12:05,440
And suddenly your partner side is no longer a quiet place

1858
01:12:05,440 --> 01:12:06,720
to upload documents.

1859
01:12:06,720 --> 01:12:08,480
It's an AI-grounded knowledge surface

1860
01:12:08,480 --> 01:12:10,720
that can summarize, search, and surface content

1861
01:12:10,720 --> 01:12:11,600
at machine speed.

1862
01:12:11,600 --> 01:12:13,760
So the framing for scenario three is strict.

1863
01:12:13,760 --> 01:12:15,760
External sharing is a controlled zone.

1864
01:12:15,760 --> 01:12:17,360
A zone is not a site template.

1865
01:12:17,360 --> 01:12:19,920
A zone is a policy boundary with dedicated defaults,

1866
01:12:19,920 --> 01:12:22,480
dedicated monitoring and dedicated lifecycle rules.

1867
01:12:22,480 --> 01:12:26,400
It exists because external collaboration is not a feature request.

1868
01:12:26,400 --> 01:12:29,120
It's a threat model. Start with the problem reality.

1869
01:12:29,120 --> 01:12:31,280
Partner workspace is happened constantly.

1870
01:12:31,280 --> 01:12:35,360
Vendors, joint ventures, auditors, contractors, client delivery teams.

1871
01:12:35,360 --> 01:12:38,080
And even if IT blocks external sharing broadly,

1872
01:12:38,080 --> 01:12:39,680
users will still share externally.

1873
01:12:39,680 --> 01:12:42,080
They'll email attachments, use personal storage

1874
01:12:42,080 --> 01:12:43,280
or spin-up shadow tools.

1875
01:12:43,280 --> 01:12:46,240
So no external sharing is not a strategy.

1876
01:12:46,240 --> 01:12:47,440
It's denial.

1877
01:12:47,440 --> 01:12:50,000
The strategy is provide an approved path

1878
01:12:50,000 --> 01:12:51,840
that is safer than the bypass.

1879
01:12:51,840 --> 01:12:54,160
That path is the external collaboration zone.

1880
01:12:54,160 --> 01:12:56,400
It's a dedicated site or hub structure

1881
01:12:56,400 --> 01:12:59,120
where every site inherits hard and defaults.

1882
01:12:59,120 --> 01:13:01,680
No anonymous links required authentication,

1883
01:13:01,680 --> 01:13:04,560
enforced expiration, restricted download where needed,

1884
01:13:04,560 --> 01:13:07,920
and labels that reflect the data types allowed in that zone.

1885
01:13:07,920 --> 01:13:10,320
If the business needs to collaborate with partners,

1886
01:13:10,320 --> 01:13:13,040
they do it here, not in random internal project sites,

1887
01:13:13,040 --> 01:13:15,840
not in HR team sites, not in someone's personal one drive.

1888
01:13:15,840 --> 01:13:17,360
This is also where you stop pretending

1889
01:13:17,360 --> 01:13:19,600
that site owner education scales.

1890
01:13:19,600 --> 01:13:21,440
Owners change. They get busy.

1891
01:13:21,440 --> 01:13:23,280
They forget. They inherit sites.

1892
01:13:23,280 --> 01:13:24,400
They didn't create.

1893
01:13:24,400 --> 01:13:26,160
And they will make exceptions under pressure

1894
01:13:26,160 --> 01:13:27,760
because the partner relationship matters

1895
01:13:27,760 --> 01:13:29,120
more than your policy document.

1896
01:13:29,120 --> 01:13:31,920
So the zone has to survive convenience pressure by design.

1897
01:13:31,920 --> 01:13:33,920
Policy is inherited and enforced,

1898
01:13:33,920 --> 01:13:35,200
not configured repeatedly.

1899
01:13:35,200 --> 01:13:37,200
Now the uncomfortable truth about external sharing.

1900
01:13:37,200 --> 01:13:38,640
It's not just about guests.

1901
01:13:38,640 --> 01:13:39,360
It's about links.

1902
01:13:39,360 --> 01:13:42,880
Most leakage happens through links that outlive intent.

1903
01:13:42,880 --> 01:13:44,720
Links created for a short term partner.

1904
01:13:44,720 --> 01:13:46,240
Links forwarded to the wrong person.

1905
01:13:46,240 --> 01:13:47,440
Links never revoked.

1906
01:13:47,440 --> 01:13:49,680
Links that keep working after the contract ends

1907
01:13:49,680 --> 01:13:51,280
because nobody remembered they existed.

1908
01:13:51,280 --> 01:13:53,280
So the zone model treats link creation

1909
01:13:53,280 --> 01:13:55,200
as an auditable action with life cycle.

1910
01:13:55,200 --> 01:13:57,440
Exploration is the default, not the exception.

1911
01:13:57,440 --> 01:13:59,840
High risk labels require shorter expiration.

1912
01:13:59,840 --> 01:14:01,920
And if the business needs no expiration,

1913
01:14:01,920 --> 01:14:04,160
that's an exception with explicit owner approval

1914
01:14:04,160 --> 01:14:05,280
and ongoing review.

1915
01:14:05,280 --> 01:14:06,640
Then guest life cycle.

1916
01:14:06,640 --> 01:14:07,440
Guests aren't users.

1917
01:14:07,440 --> 01:14:09,040
They're temporary risk allocations.

1918
01:14:09,040 --> 01:14:11,280
So every guest needs sponsorship.

1919
01:14:11,280 --> 01:14:13,360
And that sponsorship has to be enforceable.

1920
01:14:13,360 --> 01:14:15,200
If a guest loses their sponsor,

1921
01:14:15,200 --> 01:14:16,560
they don't remain in the tenant

1922
01:14:16,560 --> 01:14:18,080
as a ghost identity with access.

1923
01:14:18,080 --> 01:14:19,040
Nobody can explain.

1924
01:14:19,040 --> 01:14:20,560
They get reviewed and removed.

1925
01:14:20,560 --> 01:14:24,800
If a partner project ends, guests get deprovisioned automatically,

1926
01:14:24,800 --> 01:14:26,720
not when someone remembers.

1927
01:14:26,720 --> 01:14:28,400
That means external collaboration zones

1928
01:14:28,400 --> 01:14:30,960
need life cycle hooks, start date, end date,

1929
01:14:30,960 --> 01:14:32,960
renewal prompts and a clean tear down path.

1930
01:14:32,960 --> 01:14:34,720
Otherwise, your tenant becomes a museum

1931
01:14:34,720 --> 01:14:37,280
of expired partnerships with valid access.

1932
01:14:37,280 --> 01:14:39,520
Now add GDPR and data sovereignty pressure

1933
01:14:39,520 --> 01:14:41,760
because this is where regulators stop accepting

1934
01:14:41,760 --> 01:14:42,800
we didn't mean to.

1935
01:14:42,800 --> 01:14:44,800
If PII enters an external zone,

1936
01:14:44,800 --> 01:14:46,560
you need deterministic controls

1937
01:14:46,560 --> 01:14:48,000
that prevent it from spreading.

1938
01:14:48,000 --> 01:14:50,480
Sensitivity labels that restrict sharing behavior

1939
01:14:50,480 --> 01:14:53,440
DLP rules that block obvious exfiltration

1940
01:14:53,440 --> 01:14:55,840
and an audit trail you can produce without panic.

1941
01:14:55,840 --> 01:14:58,240
External collaboration is where

1942
01:14:58,240 --> 01:14:59,680
least privilege becomes real

1943
01:14:59,680 --> 01:15:01,040
because you are now collaborating

1944
01:15:01,040 --> 01:15:02,800
with identities you don't fully control

1945
01:15:02,800 --> 01:15:04,480
which is why the zone is not optional.

1946
01:15:04,480 --> 01:15:05,840
It's the only way to separate

1947
01:15:05,840 --> 01:15:07,520
internal collaboration ergonomics

1948
01:15:07,520 --> 01:15:09,120
from external boundary enforcement

1949
01:15:09,120 --> 01:15:12,000
without trying to do per-site exceptions forever.

1950
01:15:12,000 --> 01:15:13,440
And yes, business units will ask,

1951
01:15:13,440 --> 01:15:15,280
why can't we just enable external sharing

1952
01:15:15,280 --> 01:15:16,800
on this one internal site?

1953
01:15:16,800 --> 01:15:19,840
Because this one internal site becomes 50.

1954
01:15:19,840 --> 01:15:21,760
Then 500, then it's normal,

1955
01:15:21,760 --> 01:15:24,000
then your data classification doesn't mean anything

1956
01:15:24,000 --> 01:15:25,760
because anything can be shared from anywhere

1957
01:15:25,760 --> 01:15:27,760
with the right owner clicking the right button.

1958
01:15:27,760 --> 01:15:28,880
That is the drift model.

1959
01:15:28,880 --> 01:15:32,320
So scenario three starts with a design decision,

1960
01:15:32,320 --> 01:15:33,680
not a tool decision.

1961
01:15:33,680 --> 01:15:36,160
External collaboration happens in controlled zones

1962
01:15:36,160 --> 01:15:37,360
with hardened defaults

1963
01:15:37,360 --> 01:15:39,680
and everything else is internal by default.

1964
01:15:39,680 --> 01:15:40,960
Once that line exists,

1965
01:15:40,960 --> 01:15:42,200
you can implement it with

1966
01:15:42,200 --> 01:15:45,520
Entra B2B controls conditional access sensitivity labels

1967
01:15:45,520 --> 01:15:47,760
and DLP and that's the next section.

1968
01:15:47,760 --> 01:15:50,400
The architecture that makes cross-tenant collaboration

1969
01:15:50,400 --> 01:15:51,600
survivable.

1970
01:15:51,600 --> 01:15:53,520
Scenario three, architecture,

1971
01:15:53,520 --> 01:15:55,760
cross-tenant collaboration with least privilege

1972
01:15:55,760 --> 01:15:57,120
and continuous audit.

1973
01:15:57,120 --> 01:16:00,560
The architecture for external collaboration has one job.

1974
01:16:00,560 --> 01:16:03,840
Make working with outsiders behave like a controlled system,

1975
01:16:03,840 --> 01:16:06,080
not a series of one-off exceptions.

1976
01:16:06,080 --> 01:16:07,440
Start with Entra B2B

1977
01:16:07,440 --> 01:16:09,840
because that's where the boundary becomes enforceable.

1978
01:16:09,840 --> 01:16:11,920
Guests need a defined onboarding path

1979
01:16:11,920 --> 01:16:14,400
and that path must be policy-driven.

1980
01:16:14,400 --> 01:16:15,440
Who can invite?

1981
01:16:15,440 --> 01:16:17,680
Which domains are allowed, what terms apply

1982
01:16:17,680 --> 01:16:20,160
and what happens when the sponsor disappears?

1983
01:16:20,160 --> 01:16:22,480
A guest is not a user object you tolerate.

1984
01:16:22,480 --> 01:16:24,560
It's a time-bound access allocation

1985
01:16:24,560 --> 01:16:26,640
with an accountable human attached to it.

1986
01:16:26,640 --> 01:16:28,640
That's why sponsorship and life cycle matter

1987
01:16:28,640 --> 01:16:30,000
more than the invite itself.

1988
01:16:30,000 --> 01:16:31,120
If the sponsor leaves,

1989
01:16:31,120 --> 01:16:33,200
access should not quietly persist.

1990
01:16:33,200 --> 01:16:35,280
The system must trigger an access review,

1991
01:16:35,280 --> 01:16:37,920
then remove the guest if no one reclaims ownership.

1992
01:16:37,920 --> 01:16:39,280
That is not bureaucracy.

1993
01:16:39,280 --> 01:16:40,960
It is how you prevent former partners

1994
01:16:40,960 --> 01:16:43,840
still downloading files from becoming a quarterly tradition.

1995
01:16:43,840 --> 01:16:45,040
Then conditional access.

1996
01:16:45,040 --> 01:16:47,280
External collaboration without conditional access

1997
01:16:47,280 --> 01:16:49,440
is just a shared folder with better marketing.

1998
01:16:49,440 --> 01:16:50,960
Require MFA for guests.

1999
01:16:50,960 --> 01:16:52,480
Block legacy authentication.

2000
01:16:52,480 --> 01:16:54,160
Apply device controls where you can.

2001
01:16:54,160 --> 01:16:57,440
And most importantly, separate the guest experience by zone.

2002
01:16:57,440 --> 01:16:58,960
External collaboration sites

2003
01:16:58,960 --> 01:17:00,640
should enforce stricter access conditions

2004
01:17:00,640 --> 01:17:01,840
than internal project sites

2005
01:17:01,840 --> 01:17:03,360
because the threat model is different.

2006
01:17:03,360 --> 01:17:04,640
Treat this as deterministic.

2007
01:17:04,640 --> 01:17:07,760
If it's a guest, the access decision is harder by default.

2008
01:17:07,760 --> 01:17:08,960
Now cross-tenant patterns.

2009
01:17:08,960 --> 01:17:11,520
Most organizations default to B2B guests everywhere

2010
01:17:11,520 --> 01:17:12,560
because it's familiar.

2011
01:17:12,560 --> 01:17:14,960
But in some partner relationships B2B direct connect

2012
01:17:14,960 --> 01:17:17,680
makes sense to organizations with mature identity,

2013
01:17:17,680 --> 01:17:18,880
deliberate trust,

2014
01:17:18,880 --> 01:17:20,880
and a need for persistent collaboration

2015
01:17:20,880 --> 01:17:22,640
without endless guest churn.

2016
01:17:22,640 --> 01:17:24,080
The point isn't which feature wins.

2017
01:17:24,080 --> 01:17:25,440
The point is boundary clarity.

2018
01:17:25,440 --> 01:17:26,800
If you use direct connect,

2019
01:17:26,800 --> 01:17:28,320
you document the trust relationship,

2020
01:17:28,320 --> 01:17:30,400
you constrain it to the collaboration zone

2021
01:17:30,400 --> 01:17:32,720
and you monitor it like a production dependency.

2022
01:17:32,720 --> 01:17:33,840
Because that's what it is.

2023
01:17:33,840 --> 01:17:35,280
Next permissions.

2024
01:17:35,280 --> 01:17:36,960
This is where entropy explodes

2025
01:17:36,960 --> 01:17:38,400
so the model has to be boring.

2026
01:17:38,400 --> 01:17:40,080
Group-based access only.

2027
01:17:40,080 --> 01:17:41,840
Guests assigned to guest access groups

2028
01:17:41,840 --> 01:17:43,760
never directly to share point items.

2029
01:17:43,760 --> 01:17:46,400
Owners assigned through owner groups, not individuals,

2030
01:17:46,400 --> 01:17:48,800
and guest access should be limited to the minimum roles

2031
01:17:48,800 --> 01:17:50,160
that make the project function.

2032
01:17:50,160 --> 01:17:52,160
If a partner needs edit rights, fine.

2033
01:17:52,160 --> 01:17:53,760
But granted through a controlled group

2034
01:17:53,760 --> 01:17:55,120
that you can review and rotate,

2035
01:17:55,120 --> 01:17:56,800
not through a pile of direct permissions

2036
01:17:56,800 --> 01:17:58,720
that no one can inventory later.

2037
01:17:58,720 --> 01:18:00,080
Then sensitivity labels

2038
01:18:00,080 --> 01:18:02,240
because they encode the collaboration contract

2039
01:18:02,240 --> 01:18:03,360
into the content itself.

2040
01:18:03,360 --> 01:18:05,200
In this zone labels shouldn't be decorative.

2041
01:18:05,200 --> 01:18:07,040
They should drive enforcement outcomes.

2042
01:18:07,040 --> 01:18:08,960
Encryption, restricted sharing,

2043
01:18:08,960 --> 01:18:10,880
and download controls were required.

2044
01:18:10,880 --> 01:18:13,440
The label is how you prevent someone copied the file

2045
01:18:13,440 --> 01:18:15,360
to a different site and now it's ungoverned

2046
01:18:15,360 --> 01:18:17,120
from becoming the default data flow.

2047
01:18:17,120 --> 01:18:18,960
When content moves, the label travels

2048
01:18:18,960 --> 01:18:21,760
and when the label travels your policy intent travels.

2049
01:18:21,760 --> 01:18:22,960
Auto-labeling can help here,

2050
01:18:22,960 --> 01:18:25,120
but only inside boundaries you can defend.

2051
01:18:25,120 --> 01:18:26,480
Models will misclassify.

2052
01:18:26,480 --> 01:18:27,520
They always do.

2053
01:18:27,520 --> 01:18:29,680
So use auto-labeling for obvious cases

2054
01:18:29,680 --> 01:18:31,040
and high-confidence patterns

2055
01:18:31,040 --> 01:18:32,800
and make humans own exceptions.

2056
01:18:32,800 --> 01:18:36,000
The worst design is pretending the model is a compliance officer.

2057
01:18:36,000 --> 01:18:36,560
It isn't.

2058
01:18:36,560 --> 01:18:38,960
It's a classifier with probabilistic outcomes.

2059
01:18:38,960 --> 01:18:39,600
Now DLP.

2060
01:18:39,600 --> 01:18:42,160
In external collaboration, DLP isn't optional friction.

2061
01:18:42,160 --> 01:18:43,440
It's the runtime guardrail

2062
01:18:43,440 --> 01:18:45,600
that stops the obvious leakage paths.

2063
01:18:45,600 --> 01:18:47,760
PII copied into a partner space,

2064
01:18:47,760 --> 01:18:49,680
regulated documents shared by link,

2065
01:18:49,680 --> 01:18:51,440
or content exported through connectors

2066
01:18:51,440 --> 01:18:54,240
that bypass SharePoint's native controls.

2067
01:18:54,240 --> 01:18:56,080
And the stratification still applies.

2068
01:18:56,080 --> 01:18:57,920
PII policies behave differently

2069
01:18:57,920 --> 01:18:59,520
than source code policies.

2070
01:18:59,520 --> 01:19:00,960
Your finance team's tolerance

2071
01:19:00,960 --> 01:19:03,920
for false positives is not your engineering team's tolerance

2072
01:19:03,920 --> 01:19:05,280
designed for that reality.

2073
01:19:05,280 --> 01:19:08,000
A key pattern here is allow with justification

2074
01:19:08,000 --> 01:19:09,200
in the external zone,

2075
01:19:09,200 --> 01:19:11,520
but only when the business has a defensible need.

2076
01:19:11,520 --> 01:19:13,200
The justification isn't for feelings.

2077
01:19:13,200 --> 01:19:14,000
It's for evidence.

2078
01:19:14,000 --> 01:19:16,080
If an exception happens, you want a named human,

2079
01:19:16,080 --> 01:19:18,560
a reason, and a timestamp, you can query later.

2080
01:19:18,560 --> 01:19:20,000
Otherwise, you don't have governance.

2081
01:19:20,000 --> 01:19:21,280
You have vibes.

2082
01:19:21,280 --> 01:19:22,720
Now, continuous audit.

2083
01:19:22,720 --> 01:19:24,640
External collaboration is where you need

2084
01:19:24,640 --> 01:19:26,000
near-real time detection,

2085
01:19:26,000 --> 01:19:27,360
not end-of-quarter review.

2086
01:19:27,360 --> 01:19:28,880
Stream the right signals.

2087
01:19:28,880 --> 01:19:30,080
Guest invitations.

2088
01:19:30,080 --> 01:19:31,280
Guest sign-ins.

2089
01:19:31,280 --> 01:19:32,400
Link creation.

2090
01:19:32,400 --> 01:19:33,520
Sharing events.

2091
01:19:33,520 --> 01:19:34,720
Download spikes.

2092
01:19:34,720 --> 01:19:37,520
Permission changes and DLP overrides.

2093
01:19:37,520 --> 01:19:38,960
Then correlate them with identities

2094
01:19:38,960 --> 01:19:40,560
which user, which guest,

2095
01:19:40,560 --> 01:19:41,760
which service principal,

2096
01:19:41,760 --> 01:19:42,960
which site, which label.

2097
01:19:42,960 --> 01:19:44,400
If you can't join those dots,

2098
01:19:44,400 --> 01:19:45,760
you can't investigate quickly

2099
01:19:45,760 --> 01:19:46,960
and you will lose the narrative

2100
01:19:46,960 --> 01:19:48,240
when something goes wrong.

2101
01:19:48,240 --> 01:19:49,840
And watch for the specific anomalies

2102
01:19:49,840 --> 01:19:51,440
that matter in cross-tenant work.

2103
01:19:51,440 --> 01:19:53,440
A guest suddenly accessing a new site

2104
01:19:53,440 --> 01:19:54,960
outside their normal zone,

2105
01:19:54,960 --> 01:19:56,800
a wave of anonymous links appearing

2106
01:19:56,800 --> 01:19:58,160
where they should be forbidden,

2107
01:19:58,160 --> 01:19:59,520
or a service principal reading

2108
01:19:59,520 --> 01:20:02,000
across multiple external sites in a short window.

2109
01:20:02,000 --> 01:20:04,800
Those are not interesting logs.

2110
01:20:04,800 --> 01:20:06,320
They're breach precursors.

2111
01:20:06,320 --> 01:20:08,080
So the architecture closes the loop.

2112
01:20:08,080 --> 01:20:09,840
Entra controls the identities.

2113
01:20:09,840 --> 01:20:12,000
Conditional access controls the sessions.

2114
01:20:12,000 --> 01:20:14,400
Group-based access controls the permissions.

2115
01:20:14,400 --> 01:20:17,120
Sensitivity labels control the content behavior.

2116
01:20:17,120 --> 01:20:19,040
DLP controls the egress

2117
01:20:19,040 --> 01:20:21,040
and Sentinel controls the story you'll need

2118
01:20:21,040 --> 01:20:22,640
when leadership asks what happened.

2119
01:20:22,640 --> 01:20:24,480
Agents in the enterprise

2120
01:20:24,480 --> 01:20:26,880
where autonomy fits, where it must be caged.

2121
01:20:26,880 --> 01:20:28,640
Now the part everyone wants to talk about

2122
01:20:28,640 --> 01:20:31,040
usually in the least useful way, agents.

2123
01:20:31,040 --> 01:20:33,840
Most organizations treat agents like the next UI.

2124
01:20:33,840 --> 01:20:35,760
A chat box bolted onto a site.

2125
01:20:35,760 --> 01:20:37,680
Asked anything about this library.

2126
01:20:37,680 --> 01:20:39,520
That's fine, but it's not the enterprise problem.

2127
01:20:39,520 --> 01:20:41,360
The enterprise problem is that agents turn

2128
01:20:41,360 --> 01:20:44,560
SharePoint from a workflow surface into a decision surface

2129
01:20:44,560 --> 01:20:46,080
and decisions create liability

2130
01:20:46,080 --> 01:20:48,160
when nobody can explain why they happened.

2131
01:20:48,160 --> 01:20:49,120
So the framing is simple.

2132
01:20:49,120 --> 01:20:50,480
Agents are interfaces first.

2133
01:20:50,480 --> 01:20:51,360
They are not pipelines.

2134
01:20:51,360 --> 01:20:53,760
They sit at the edge, helping humans find,

2135
01:20:53,760 --> 01:20:55,520
summarize, and initiate.

2136
01:20:55,520 --> 01:20:57,680
They do not replace deterministic enforcement.

2137
01:20:57,680 --> 01:20:59,600
They do not own compliance outcomes.

2138
01:20:59,600 --> 01:21:02,080
And they absolutely do not get to freestyle changes

2139
01:21:02,080 --> 01:21:04,640
across systems because the prompt sounded confident.

2140
01:21:04,640 --> 01:21:06,480
Where agents fit is the reasoning layer

2141
01:21:06,480 --> 01:21:08,960
when the output is advisory or bounded.

2142
01:21:08,960 --> 01:21:10,640
Knowledge retrieval on a site.

2143
01:21:10,640 --> 01:21:13,360
Guided actions that map to approved workflows.

2144
01:21:13,360 --> 01:21:14,160
Triage.

2145
01:21:14,160 --> 01:21:15,360
Which policy applies?

2146
01:21:15,360 --> 01:21:16,400
Who owns this?

2147
01:21:16,400 --> 01:21:18,160
Where is the latest approved version?

2148
01:21:18,160 --> 01:21:19,680
What template should we use?

2149
01:21:19,680 --> 01:21:21,360
Which intake form is correct?

2150
01:21:21,360 --> 01:21:24,240
Those tasks reduce cognitive load without changing system state.

2151
01:21:24,240 --> 01:21:27,520
Everything clicked for enterprises when they realize the pattern.

2152
01:21:27,520 --> 01:21:29,280
The agent can decide what to ask,

2153
01:21:29,280 --> 01:21:30,960
but it must not decide what to do.

2154
01:21:30,960 --> 01:21:32,240
If it's going to do something,

2155
01:21:32,240 --> 01:21:34,000
it does it through a cage.

2156
01:21:34,000 --> 01:21:37,520
A controlled tool set with explicit permissions, explicit inputs,

2157
01:21:37,520 --> 01:21:39,520
explicit logging, and an approval gate

2158
01:21:39,520 --> 01:21:41,760
when the action crosses a boundary.

2159
01:21:41,760 --> 01:21:43,200
That cage can be technical.

2160
01:21:43,200 --> 01:21:46,080
A set of graph scopes limited to one-side collection

2161
01:21:46,080 --> 01:21:47,600
read only by default,

2162
01:21:47,600 --> 01:21:50,000
write actions routed through an orchestration service

2163
01:21:50,000 --> 01:21:52,800
that validates policy and state before it commits.

2164
01:21:52,800 --> 01:21:54,080
It can be organizational.

2165
01:21:54,080 --> 01:21:56,000
Agents require sponsors have life cycles

2166
01:21:56,000 --> 01:21:58,000
and get deleted when the sponsor disappears.

2167
01:21:58,000 --> 01:21:59,760
But the cage must exist because autonomy

2168
01:21:59,760 --> 01:22:01,840
without containment isn't innovation.

2169
01:22:01,840 --> 01:22:03,120
It's conditional chaos.

2170
01:22:03,760 --> 01:22:06,560
The other mistake is treating agents as smart users.

2171
01:22:06,560 --> 01:22:07,680
They're not.

2172
01:22:07,680 --> 01:22:09,920
In architectural terms,

2173
01:22:09,920 --> 01:22:12,000
an agent is a non-human identity

2174
01:22:12,000 --> 01:22:14,560
with tool access and a probabilistic reasoning engine.

2175
01:22:14,560 --> 01:22:16,960
That means it inherits the two worst properties

2176
01:22:16,960 --> 01:22:18,240
of enterprise systems.

2177
01:22:18,240 --> 01:22:20,400
It can act quickly and it can be wrong quickly.

2178
01:22:20,400 --> 01:22:23,120
So the enterprise model treats agents as identities,

2179
01:22:23,120 --> 01:22:25,440
registered, permissioned, monitored, and reviewed.

2180
01:22:25,440 --> 01:22:27,520
The same rules apply as with service principles

2181
01:22:27,520 --> 01:22:28,880
and managed identities.

2182
01:22:28,880 --> 01:22:30,720
Leased privilege, group-based access

2183
01:22:30,720 --> 01:22:32,080
and zero standing privilege.

2184
01:22:32,080 --> 01:22:34,240
If an agent needs to perform privileged actions,

2185
01:22:34,240 --> 01:22:36,160
it does it under just-in-time elevation

2186
01:22:36,160 --> 01:22:38,160
and logs every action with correlation IDs

2187
01:22:38,160 --> 01:22:39,600
you can join in Sentinel.

2188
01:22:39,600 --> 01:22:42,640
Now the risk model because this is where leader stops smiling.

2189
01:22:42,640 --> 01:22:45,920
There's a failure triangle that always shows up with agents.

2190
01:22:45,920 --> 01:22:48,000
Oversharing, untrusted input,

2191
01:22:48,000 --> 01:22:49,360
and external actions.

2192
01:22:49,360 --> 01:22:52,160
Oversharing means the underlying SharePoint permission model

2193
01:22:52,160 --> 01:22:55,600
is messy and the agent faithfully surfaces what it can see.

2194
01:22:55,600 --> 01:22:57,040
That's not an AI failure.

2195
01:22:57,040 --> 01:22:59,840
That's your access model showing up at machine speed.

2196
01:22:59,840 --> 01:23:03,200
Untrusted input means the agent reads content it didn't control,

2197
01:23:03,200 --> 01:23:06,800
uploaded files, emails, partner documents, pages edited by anyone.

2198
01:23:06,800 --> 01:23:09,120
If you don't assume malicious or misleading content

2199
01:23:09,120 --> 01:23:11,040
will enter the system, you will eventually learn

2200
01:23:11,040 --> 01:23:12,160
that assumption was wrong.

2201
01:23:12,160 --> 01:23:14,720
External actions means the agent can call tools,

2202
01:23:14,720 --> 01:23:17,360
send messages, change permissions, create links,

2203
01:23:17,360 --> 01:23:19,120
move files, trigger flows.

2204
01:23:19,120 --> 01:23:21,360
The moment an agent can act outside its own boundary,

2205
01:23:21,360 --> 01:23:24,160
prompt injection stops being a theory and becomes an incident type.

2206
01:23:24,160 --> 01:23:26,640
So the enterprise pattern is to break that triangle.

2207
01:23:26,640 --> 01:23:30,800
You reduce oversharing with the group model labels and DLP you already built.

2208
01:23:30,800 --> 01:23:33,680
You treat untrusted input as normal and sanitize

2209
01:23:33,680 --> 01:23:35,840
what the agent can use as instructions.

2210
01:23:35,840 --> 01:23:37,840
And you tightly constrain external actions,

2211
01:23:37,840 --> 01:23:41,840
read before write and write only through policy enforcement services.

2212
01:23:41,840 --> 01:23:43,920
Now, a practical architecture view.

2213
01:23:43,920 --> 01:23:47,280
Agents become entry points into your existing automation stack.

2214
01:23:47,280 --> 01:23:49,120
A site agent can answer questions,

2215
01:23:49,120 --> 01:23:52,080
then offer approved actions that map two quick steps

2216
01:23:52,080 --> 01:23:53,360
or orchestrated workflows.

2217
01:23:53,360 --> 01:23:55,360
A knowledge agent can propose metadata fixes

2218
01:23:55,360 --> 01:23:56,560
but humans confirm.

2219
01:23:56,560 --> 01:23:58,560
An admin agent can serve as drift signals

2220
01:23:58,560 --> 01:24:01,360
but enforcement runs through deterministic controls

2221
01:24:01,360 --> 01:24:03,920
and log remediation that keeps your system stable.

2222
01:24:03,920 --> 01:24:06,240
Humans get speed but governance stays real.

2223
01:24:06,240 --> 01:24:08,880
Because the truth is agents don't reduce governance needs.

2224
01:24:08,880 --> 01:24:10,000
They amplify them.

2225
01:24:10,000 --> 01:24:11,920
The blueprint that survives growth.

2226
01:24:11,920 --> 01:24:15,120
Scalable SharePoint automation isn't more flows or more AI.

2227
01:24:15,120 --> 01:24:16,720
It's enforced intent.

2228
01:24:16,720 --> 01:24:19,120
Entra identity, purview labels,

2229
01:24:19,120 --> 01:24:21,520
DLP gates and observable orchestration

2230
01:24:21,520 --> 01:24:24,000
that converges instead of drifting.

2231
01:24:24,000 --> 01:24:26,080
If you want the next layer, watch the episode

2232
01:24:26,080 --> 01:24:27,760
on designing the Entra group model

2233
01:24:27,760 --> 01:24:29,360
that prevents permission fanfiction

2234
01:24:29,360 --> 01:24:31,520
because everything depends on that perimeter.

2235
01:24:31,520 --> 01:24:33,440
Subscribe to M365FM

2236
01:24:33,440 --> 01:24:35,280
and connect with milk-o-peaters on LinkedIn

2237
01:24:35,280 --> 01:24:37,360
with your hardest SharePoint automation problem

2238
01:24:37,360 --> 01:24:38,800
for a future breakdown.