The Power Platform Explained- Choosing the Right Tool (Before You Build Anything)

1
00:00:00,000 --> 00:00:05,600
Hello, my name is Mirko Peters and I translate how technology actually shapes business reality.

2
00:00:05,600 --> 00:00:09,080
Most power platform projects don't fail because the people are weak or the tools are missing

3
00:00:09,080 --> 00:00:10,740
or the budget was too small.

4
00:00:10,740 --> 00:00:12,320
They fail much earlier than that.

5
00:00:12,320 --> 00:00:16,000
The collapse happens, the moment a team decides what to build before they have even identified

6
00:00:16,000 --> 00:00:17,400
what is actually broken.

7
00:00:17,400 --> 00:00:21,720
If you build on a flawed starting point, even a high quality app becomes nothing more than

8
00:00:21,720 --> 00:00:24,080
structural compensation for a bad process.

9
00:00:24,080 --> 00:00:27,520
We need to slow this down and choose the right power platform tool before we commit to

10
00:00:27,520 --> 00:00:28,720
building anything at all.

11
00:00:28,720 --> 00:00:32,560
If you are responsible for building or governing Microsoft systems, hit subscribe and let's

12
00:00:32,560 --> 00:00:36,160
keep pressure testing these decisions together.

13
00:00:36,160 --> 00:00:38,200
The real mistake is starting with a tool.

14
00:00:38,200 --> 00:00:41,600
I see this pattern play out in boardrooms and dev sessions all the time.

15
00:00:41,600 --> 00:00:46,840
A team feels friction somewhere in the business because requests are slow, approvals are messy

16
00:00:46,840 --> 00:00:48,560
and reporting feels weak.

17
00:00:48,560 --> 00:00:52,040
People are frustrated with a daily grind and almost immediately someone suggests that

18
00:00:52,040 --> 00:00:53,960
they should build an app to fix it.

19
00:00:53,960 --> 00:00:57,160
That reaction sounds smart in the moment because it feels proactive and gives the room a

20
00:00:57,160 --> 00:00:59,200
concrete solution to hold on to.

21
00:00:59,200 --> 00:01:02,280
But from a system perspective that isn't clarity, it's bias.

22
00:01:02,280 --> 00:01:06,160
Once the conversation starts with the shape of a solution, the room stops asking what the

23
00:01:06,160 --> 00:01:11,360
actual failure is and the real problem gets buried under excitement for a new interface.

24
00:01:11,360 --> 00:01:13,600
Let me make this real with a specific example.

25
00:01:13,600 --> 00:01:17,840
Imagine the team at Contoso Manufacturing dealing with a vacation request process that is annoying

26
00:01:17,840 --> 00:01:20,360
enough that everybody knows it's a problem.

27
00:01:20,360 --> 00:01:24,800
Employees send their requests by email, managers frequently miss them and HR keeps a manual

28
00:01:24,800 --> 00:01:27,440
spreadsheet because nobody trusts the inbox trail.

29
00:01:27,440 --> 00:01:30,960
Someone eventually spots power apps and decides it's the perfect time to build a vacation

30
00:01:30,960 --> 00:01:32,360
app to solve the headache.

31
00:01:32,360 --> 00:01:36,160
While an app might be part of the eventual answer, it is almost never the first move a

32
00:01:36,160 --> 00:01:37,520
healthy system requires.

33
00:01:37,520 --> 00:01:38,800
And why is that?

34
00:01:38,800 --> 00:01:43,160
Because a vacation app is not a diagnosis of a business problem but rather it is just

35
00:01:43,160 --> 00:01:45,600
a preferred interface for a broken system.

36
00:01:45,600 --> 00:01:48,960
If the real issue is that a provoked sit with managers for four days because nobody

37
00:01:48,960 --> 00:01:52,520
owns the escalation logic then a new screen won't fix the delay.

38
00:01:52,520 --> 00:01:57,280
If the real problem is that HR and managers classify leaf types differently then adding

39
00:01:57,280 --> 00:02:01,480
automation will only spread that inconsistency across the company faster.

40
00:02:01,480 --> 00:02:05,120
When nobody can see the approval lag or the staffing impact across different teams,

41
00:02:05,120 --> 00:02:08,800
the missing layer is visibility, not just a better way to input data.

42
00:02:08,800 --> 00:02:11,640
This is where many power platforms conversations go off the rails.

43
00:02:11,640 --> 00:02:15,800
We tend to collapse five different tool categories into one mental shortcut called building

44
00:02:15,800 --> 00:02:19,240
something and then we act surprised when the result looks polished.

45
00:02:19,240 --> 00:02:21,040
But the process still drags.

46
00:02:21,040 --> 00:02:25,080
The data still conflicts and the reporting still depends on manual reconciliation because

47
00:02:25,080 --> 00:02:28,320
we started with a tool instead of starting with a constraint.

48
00:02:28,320 --> 00:02:31,960
When you start with a tool you inherit every assumption that tool makes before you've

49
00:02:31,960 --> 00:02:33,360
even defined the job.

50
00:02:33,360 --> 00:02:37,280
Power Apps forces you to think about screens while power automate makes you think about steps

51
00:02:37,280 --> 00:02:40,400
and power BI pulls your focus towards reports.

52
00:02:40,400 --> 00:02:43,960
None of those perspectives are inherently wrong but each one pulls your attention to

53
00:02:43,960 --> 00:02:46,200
what a different layer of the operating model.

54
00:02:46,200 --> 00:02:50,520
If you choose your tool too early in the process you narrow the problem down too fast and

55
00:02:50,520 --> 00:02:52,080
miss the structural reality.

56
00:02:52,080 --> 00:02:55,640
I remember sitting with teams where the first 10 minutes of a workshop were spent debating

57
00:02:55,640 --> 00:02:57,720
canvas apps versus model driven apps.

58
00:02:57,720 --> 00:03:01,200
Nobody in that room had agreed on where the source of truth lived or who owned the process

59
00:03:01,200 --> 00:03:05,840
once it crossed departments which meant the metric that mattered most was completely ignored.

60
00:03:05,840 --> 00:03:07,640
That is not a productive tooling discussion.

61
00:03:07,640 --> 00:03:12,120
What I was witnessing was architecture drift happening in real time where teams build exactly

62
00:03:12,120 --> 00:03:15,680
what they asked for but fail to deliver what the business actually needed.

63
00:03:15,680 --> 00:03:19,160
Before we ever name a specific Microsoft product we need to name the failure in structural

64
00:03:19,160 --> 00:03:21,640
terms so we know what we are actually fighting.

65
00:03:21,640 --> 00:03:24,360
We have to ask what is actually breaking in the workflow.

66
00:03:24,360 --> 00:03:28,560
Is the friction happening at the intake level or is the delay caused by a routing problem

67
00:03:28,560 --> 00:03:29,840
further down the line?

68
00:03:29,840 --> 00:03:33,680
Perhaps the issue is data in consistency or a total lack of external access for field

69
00:03:33,680 --> 00:03:34,680
workers.

70
00:03:34,680 --> 00:03:38,720
Those are fundamentally different failures that require different first moves from a system

71
00:03:38,720 --> 00:03:39,720
architect.

72
00:03:39,720 --> 00:03:43,600
Sometimes the right answer is a custom app but other times it is automation first or perhaps

73
00:03:43,600 --> 00:03:46,200
reporting much earlier than the team expected.

74
00:03:46,200 --> 00:03:49,920
What the most honest answer is that you are not ready to build anything because the data

75
00:03:49,920 --> 00:03:53,680
is still scattered across Excel files and mailbox history.

76
00:03:53,680 --> 00:03:56,960
That answer usually frustrates people because it feels slower than jumping straight into

77
00:03:56,960 --> 00:04:00,520
development but it saves months of expensive rework later on.

78
00:04:00,520 --> 00:04:03,600
The platform itself is not confused about what it can do.

79
00:04:03,600 --> 00:04:04,880
We are the ones who are confused.

80
00:04:04,880 --> 00:04:08,520
We keep asking a single tool to compensate for upstream ambiguity.

81
00:04:08,520 --> 00:04:12,200
And then we blame the platform when it behaves like a tool set instead of a rescue mission

82
00:04:12,200 --> 00:04:17,280
we need to take one step back and map the process the way an architect would rather than reacting

83
00:04:17,280 --> 00:04:21,320
to how a request sounds when it first lands in an inbox.

84
00:04:21,320 --> 00:04:23,560
Contoso mapped as a system instead of a request.

85
00:04:23,560 --> 00:04:24,920
So let's map Contoso properly.

86
00:04:24,920 --> 00:04:28,440
We need to stop looking at this as a simple request for a vacation app and start seeing

87
00:04:28,440 --> 00:04:30,200
it for what it actually is.

88
00:04:30,200 --> 00:04:35,400
In reality we have a cross-functional absence management process that currently produces delay,

89
00:04:35,400 --> 00:04:37,440
rework and weak visibility.

90
00:04:37,440 --> 00:04:41,360
That sounds less exciting than a new app but it is also a lot more useful because it allows

91
00:04:41,360 --> 00:04:44,640
us to look at actual behavior instead of just user preference.

92
00:04:44,640 --> 00:04:48,400
When an employee wants time off they usually send an email or fill in a form attached to

93
00:04:48,400 --> 00:04:49,400
a message.

94
00:04:49,400 --> 00:04:53,960
A manager receives that request in Outlook where it might get buried inside a wider conversation

95
00:04:53,960 --> 00:04:56,040
or missed entirely while they are traveling.

96
00:04:56,040 --> 00:05:00,680
HR gets copied sometimes but not always, which forces them to record the request in Excel

97
00:05:00,680 --> 00:05:03,360
because payroll needs a list and planning needs a list.

98
00:05:03,360 --> 00:05:06,520
Nobody trusts the email chain to act as a reliable record so the spreadsheet becomes

99
00:05:06,520 --> 00:05:07,880
the only source of truth.

100
00:05:07,880 --> 00:05:11,960
It is the current process and it is a system doing exactly what it was designed to do.

101
00:05:11,960 --> 00:05:14,920
Now look at what the people inside that system are feeling.

102
00:05:14,920 --> 00:05:18,160
Employees live with constant uncertainty because they never truly know if their request

103
00:05:18,160 --> 00:05:20,960
was received or approved or simply lost in an inbox.

104
00:05:20,960 --> 00:05:25,120
Managers feel a sense of constant interruption because every request arrives as another message

105
00:05:25,120 --> 00:05:28,880
to interpret rather than a structured task with a clear decision path.

106
00:05:28,880 --> 00:05:33,360
Meanwhile HR feels a massive administrative drag because they are acting as the human integration

107
00:05:33,360 --> 00:05:36,920
layer between inboxes, company policy and reporting.

108
00:05:36,920 --> 00:05:40,480
From a system perspective those are not separate complaints but rather they are signals coming

109
00:05:40,480 --> 00:05:42,640
from the same broken operating model.

110
00:05:42,640 --> 00:05:46,600
The intake layer is weak because requests enter the process in inconsistent formats that

111
00:05:46,600 --> 00:05:48,480
require manual sorting.

112
00:05:48,480 --> 00:05:52,680
Because ownership and escalation are unclear once a message leaves the employee, the approval

113
00:05:52,680 --> 00:05:53,760
layer is also weak.

114
00:05:53,760 --> 00:05:57,600
The record layer fails because Excel becomes a compensating control after the fact and

115
00:05:57,600 --> 00:06:01,240
the visibility layer stays dark because nobody sees the process as it runs.

116
00:06:01,240 --> 00:06:04,320
They only see the fragments after someone finally complains.

117
00:06:04,320 --> 00:06:07,600
Once you lay it out that way the friction points become much easier to locate.

118
00:06:07,600 --> 00:06:09,440
The first friction point sits at intake.

119
00:06:09,440 --> 00:06:13,800
If one employee writes a quick note about needing next Friday off while another sends specific

120
00:06:13,800 --> 00:06:17,360
dates without a leaf type the process starts with deep ambiguity.

121
00:06:17,360 --> 00:06:21,840
That ambiguity does not stay small as it travels through the company and HR eventually has

122
00:06:21,840 --> 00:06:24,520
to spend time interpreting what was meant.

123
00:06:24,520 --> 00:06:28,080
Managers approve different things under different assumptions which means the reports eventually

124
00:06:28,080 --> 00:06:29,440
inherit bad categories.

125
00:06:29,440 --> 00:06:33,200
The first leak in the system is not a lack of speed, it is a lack of structure.

126
00:06:33,200 --> 00:06:35,640
The second friction point sits in the approval phase.

127
00:06:35,640 --> 00:06:39,960
A request reaches a manager who has no deadline, no queue and no reminder logic to help them

128
00:06:39,960 --> 00:06:40,960
stay on track.

129
00:06:40,960 --> 00:06:44,960
They often have no clean view of the employee's request history or the wider team context,

130
00:06:44,960 --> 00:06:46,080
so the request just waits.

131
00:06:46,080 --> 00:06:49,760
This doesn't happen because the manager is careless but because the process depends entirely

132
00:06:49,760 --> 00:06:51,520
on memory and goodwill.

133
00:06:51,520 --> 00:06:55,280
That is a fragile design and it is exactly where cycle time stalls first.

134
00:06:55,280 --> 00:06:58,360
The third friction point sits in the handoff.

135
00:06:58,360 --> 00:07:02,040
Once an approval finally happens somebody has to tell HR but that is often automatic only

136
00:07:02,040 --> 00:07:03,040
in theory.

137
00:07:03,040 --> 00:07:06,960
In practice it is usually another email or a spreadsheet update done much later in the

138
00:07:06,960 --> 00:07:07,960
week.

139
00:07:07,960 --> 00:07:11,880
When handoffs rely on people remembering the next step, errors enter the system quietly and

140
00:07:11,880 --> 00:07:13,120
dates get typed wrong.

141
00:07:13,120 --> 00:07:17,680
A leaf category gets changed or status stays outdated for two days and then payroll or

142
00:07:17,680 --> 00:07:20,320
staffing has to absorb the impact of that bad data.

143
00:07:20,320 --> 00:07:22,520
The fourth friction point sits in visibility.

144
00:07:22,520 --> 00:07:27,080
Leaders want to know simple things like where approvals are delayed or which teams have

145
00:07:27,080 --> 00:07:28,400
too much absence overlap.

146
00:07:28,400 --> 00:07:32,440
They want to see how many exceptions are happening outside of standard policy but the data

147
00:07:32,440 --> 00:07:35,720
needed to answer those questions lives in scattered messages.

148
00:07:35,720 --> 00:07:39,720
Management operates on anecdote because by the time a pattern becomes visible it has already

149
00:07:39,720 --> 00:07:42,000
turned into a significant operational cost.

150
00:07:42,000 --> 00:07:45,200
Every one of those symptoms points to a different design need.

151
00:07:45,200 --> 00:07:49,520
Intake friction points to what guided capture while approval delay points to what an executable

152
00:07:49,520 --> 00:07:51,120
workflow.

153
00:07:51,120 --> 00:07:55,640
Poor handoffs require state change and automation and weak visibility points to what the

154
00:07:55,640 --> 00:07:57,560
need for real time analytics.

155
00:07:57,560 --> 00:08:01,760
If contractors or temporary workers enter the process, that points to what a secure boundary

156
00:08:01,760 --> 00:08:03,040
beyond your internal tools.

157
00:08:03,040 --> 00:08:06,400
So when someone asks if we can just build one app, the honest answer is no.

158
00:08:06,400 --> 00:08:08,840
Not if you expect one surface to carry the whole process.

159
00:08:08,840 --> 00:08:12,720
The process does not break in just one place, it breaks across multiple layers.

160
00:08:12,720 --> 00:08:16,400
Once we see that the platform starts to make more sense as a set of tools with different

161
00:08:16,400 --> 00:08:18,880
jobs rather than a single answer.

162
00:08:18,880 --> 00:08:21,640
The platform is five tools, not one answer.

163
00:08:21,640 --> 00:08:23,160
Now we can name the next problem.

164
00:08:23,160 --> 00:08:26,760
Most people say power platform as if it were a single product or one big branded box

165
00:08:26,760 --> 00:08:29,920
where you put business pain in and get working software out.

166
00:08:29,920 --> 00:08:34,080
That mental shortcut creates a lot of bad decisions because the platform is actually a collection

167
00:08:34,080 --> 00:08:36,160
of tools with very different operating roles.

168
00:08:36,160 --> 00:08:41,160
If we flatten them into a single idea, we start expecting one product to handle user experience,

169
00:08:41,160 --> 00:08:44,160
process execution and AI interaction all at once.

170
00:08:44,160 --> 00:08:46,200
That is too much to ask from any single layer.

171
00:08:46,200 --> 00:08:50,120
Once that expectation settles in, teams start building with the wrong assumptions and assuming

172
00:08:50,120 --> 00:08:53,120
the platform will solve everything just because they chose it.

173
00:08:53,120 --> 00:08:57,160
But choosing the platform is not the same as assigning specific jobs inside that platform

174
00:08:57,160 --> 00:08:58,960
and that is where true architecture starts.

175
00:08:58,960 --> 00:09:02,960
At a high level, we are dealing with five core tools, power apps, power automate, power

176
00:09:02,960 --> 00:09:05,440
BI, power pages and co-pilot studio.

177
00:09:05,440 --> 00:09:09,040
Each one of these solves a different class of problem and changes a different part of

178
00:09:09,040 --> 00:09:10,280
your business reality.

179
00:09:10,280 --> 00:09:13,640
None of them should be treated like a hero product that can do it all.

180
00:09:13,640 --> 00:09:17,120
Power apps is where people interact with data while power automate is where logic moves

181
00:09:17,120 --> 00:09:18,400
in the background.

182
00:09:18,400 --> 00:09:22,400
Power BI is the layer where patterns become visible, power pages is where external users

183
00:09:22,400 --> 00:09:26,640
enter safely and co-pilot studio is where conversational access sits on top of everything

184
00:09:26,640 --> 00:09:27,640
else.

185
00:09:27,640 --> 00:09:31,040
The separation matters because once you stop treating them as interchangeable, the design

186
00:09:31,040 --> 00:09:33,200
conversation gets sharper very quickly.

187
00:09:33,200 --> 00:09:34,720
Take the contoso example again.

188
00:09:34,720 --> 00:09:38,880
If an employee needs a cleaner way to submit a vacation request, that points toward the

189
00:09:38,880 --> 00:09:39,960
interface layer.

190
00:09:39,960 --> 00:09:43,960
If those approvals need reminders and rooting, that points toward automation.

191
00:09:43,960 --> 00:09:47,680
And if leadership needs to see absence trends, that points toward reporting.

192
00:09:47,680 --> 00:09:51,840
If contractors need access without becoming full internal users, that requires external

193
00:09:51,840 --> 00:09:53,160
facing capability.

194
00:09:53,160 --> 00:09:57,240
If people want to ask about the leave policy in natural language, that points toward an

195
00:09:57,240 --> 00:09:58,600
assistant layer.

196
00:09:58,600 --> 00:10:02,480
Those are different jobs and once you say them out loud, it becomes obvious why one tool

197
00:10:02,480 --> 00:10:04,080
cannot carry the full load.

198
00:10:04,080 --> 00:10:08,000
This confusion keeps happening because the branding encourages us to group everything

199
00:10:08,000 --> 00:10:09,000
together.

200
00:10:09,000 --> 00:10:13,040
Microsoft presents it as one platform, which is fair at the ecosystem level because the tools

201
00:10:13,040 --> 00:10:15,080
share identity and data services.

202
00:10:15,080 --> 00:10:18,920
That integration is a huge part of why the platform is useful, but integration does not

203
00:10:18,920 --> 00:10:19,920
mean sameness.

204
00:10:19,920 --> 00:10:24,080
A building is one property, but that does not mean the front door, the elevator and the

205
00:10:24,080 --> 00:10:26,280
electrical wiring are the same component.

206
00:10:26,280 --> 00:10:28,040
Now map that to how we work today.

207
00:10:28,040 --> 00:10:32,240
When a leader hears the term low code, they often imagine faster delivery through one flexible

208
00:10:32,240 --> 00:10:33,240
toolset.

209
00:10:33,240 --> 00:10:37,360
While that is partly true, speed without role clarity creates fragile builds that eventually

210
00:10:37,360 --> 00:10:38,360
break.

211
00:10:38,360 --> 00:10:42,160
A maker might reach for power apps because a request sounds visual, and then another person

212
00:10:42,160 --> 00:10:44,560
adds power automate because it needs approvals.

213
00:10:44,560 --> 00:10:48,720
Later someone asks for a dashboard, so power BI gets added after the fact that the reaction,

214
00:10:48,720 --> 00:10:51,840
that is not a platform strategy, it is just tool accumulation.

215
00:10:51,840 --> 00:10:56,680
A tool accumulation usually produces a solution that works in a demo, but strains in operations

216
00:10:56,680 --> 00:11:00,640
because each layer arrived as a reaction instead of a coherent shape.

217
00:11:00,640 --> 00:11:05,240
The business problem is not that the platform has five tools, but rather that many organizations

218
00:11:05,240 --> 00:11:06,600
pretend it only has one.

219
00:11:06,600 --> 00:11:10,320
That shortcut hides the design choices that should stay visible, like where data should

220
00:11:10,320 --> 00:11:12,160
live or where logic should execute.

221
00:11:12,160 --> 00:11:15,840
It hides who the real user is and whether the process crosses a trust boundary.

222
00:11:15,840 --> 00:11:20,680
It also hides whether AI is actually helping or just compensating for poor structure.

223
00:11:20,680 --> 00:11:24,760
Before we go deeper into any one product, we need a mental model that survives contact with

224
00:11:24,760 --> 00:11:25,760
reality.

225
00:11:25,760 --> 00:11:29,120
We need something simple enough for executives to use, but accurate enough for architects

226
00:11:29,120 --> 00:11:30,280
to respect.

227
00:11:30,280 --> 00:11:34,400
Once we separate the jobs clearly, the platform stops looking confusing and starts looking

228
00:11:34,400 --> 00:11:38,640
like a coordinated set of layers where each one is useful, but none are sufficient on their

229
00:11:38,640 --> 00:11:39,640
own.

230
00:11:39,640 --> 00:11:43,920
A simple mental model that actually holds up, so let's make this usable.

231
00:11:43,920 --> 00:11:48,560
If a platform only starts to make sense after a 30 minute architecture deep dive, it isn't

232
00:11:48,560 --> 00:11:50,760
a functional model for leaders or delivery teams.

233
00:11:50,760 --> 00:11:51,880
We need something that sticks.

234
00:11:51,880 --> 00:11:56,160
I prefer a model that is stable rather than simplistic and it helps us categorize these

235
00:11:56,160 --> 00:11:59,320
tools by the specific job they do within a business system.

236
00:11:59,320 --> 00:12:01,000
The way I look at it is straightforward.

237
00:12:01,000 --> 00:12:02,280
Power Apps is the interface.

238
00:12:02,280 --> 00:12:03,680
Power Automate is the engine.

239
00:12:03,680 --> 00:12:04,840
Power BI is the eyes.

240
00:12:04,840 --> 00:12:06,280
Power Pages is the front door.

241
00:12:06,280 --> 00:12:07,800
Copilot Studio is the assistant.

242
00:12:07,800 --> 00:12:12,400
This isn't a licensing map or a product list, but rather a way to assign clear responsibility

243
00:12:12,400 --> 00:12:14,720
before anyone writes a single line of code.

244
00:12:14,720 --> 00:12:18,440
When you use this framework, your team stops treating every business frustration, like

245
00:12:18,440 --> 00:12:19,880
a request for a new app.

246
00:12:19,880 --> 00:12:21,240
We start with Power Apps.

247
00:12:21,240 --> 00:12:25,720
This is the layer where people enter data, review their tasks, and actually take action.

248
00:12:25,720 --> 00:12:28,520
It is the physical part of the system that users touch.

249
00:12:28,520 --> 00:12:32,120
When a stakeholder says the user experience is clunky or people need a cleaner way to work,

250
00:12:32,120 --> 00:12:33,920
they are talking about the interface.

251
00:12:33,920 --> 00:12:37,320
The job here is to reduce friction at the exact moment of interaction by guiding the

252
00:12:37,320 --> 00:12:39,400
user and making the next step obvious.

253
00:12:39,400 --> 00:12:42,680
While that matters immensely, it doesn't mean the app should be forced to carry the

254
00:12:42,680 --> 00:12:46,680
weight of the entire business process on its back, and then we have Power Automate.

255
00:12:46,680 --> 00:12:51,080
Power Automate handles everything that happens the moment someone clicks a submit button.

256
00:12:51,080 --> 00:12:55,520
It roots the data, sends the reminders, escalates the delays, and moves the project state from

257
00:12:55,520 --> 00:12:56,640
one phase to the next.

258
00:12:56,640 --> 00:13:00,480
If you think of Power Apps as the visible skin of the process, then Power Automate is the

259
00:13:00,480 --> 00:13:02,160
executable logic underneath.

260
00:13:02,160 --> 00:13:05,880
This is where the process becomes a reality, because background logic determines whether

261
00:13:05,880 --> 00:13:09,640
work actually flows or just sits rotting in someone's inbox.

262
00:13:09,640 --> 00:13:11,280
Next is Power BI.

263
00:13:11,280 --> 00:13:15,800
Power BI shows us what the process is actually doing over time, providing a version of the

264
00:13:15,800 --> 00:13:19,640
truth that isn't filtered by department claims or personal opinions.

265
00:13:19,640 --> 00:13:23,440
It reveals where requests are stalling, which categories are inconsistent, and which teams

266
00:13:23,440 --> 00:13:25,280
are triggering the most errors.

267
00:13:25,280 --> 00:13:29,560
Once you implement this layer, reporting stops being a decorative slide in a meeting and

268
00:13:29,560 --> 00:13:32,520
starts becoming a legitimate tool for management control.

269
00:13:32,520 --> 00:13:33,840
Then there is Power Pages.

270
00:13:33,840 --> 00:13:35,120
This tool becomes relevant.

271
00:13:35,120 --> 00:13:39,280
The moment a process needs to cross the company boundary to reach a supplier, a contractor,

272
00:13:39,280 --> 00:13:40,280
or a job applicant.

273
00:13:40,280 --> 00:13:43,640
These are people who need to interact with your data, but should never be dropped into

274
00:13:43,640 --> 00:13:46,160
your internal tools or your internal mess.

275
00:13:46,160 --> 00:13:50,440
That boundary is a structural necessity, not just a cosmetic choice, because internal,

276
00:13:50,440 --> 00:13:55,440
employee experience and external partner access are two completely different design problems.

277
00:13:55,440 --> 00:13:58,280
Finally, Copilot Studio sits on top as the assistant layer.

278
00:13:58,280 --> 00:14:02,480
It allows people to ask questions in plain English, trigger complex actions, and get guided

279
00:14:02,480 --> 00:14:04,560
answers without navigating a menu.

280
00:14:04,560 --> 00:14:06,640
But you have to notice where it sits in the system.

281
00:14:06,640 --> 00:14:08,120
It is on top, not underneath.

282
00:14:08,120 --> 00:14:09,640
It doesn't replace your data layer.

283
00:14:09,640 --> 00:14:11,760
It doesn't fix poor process ownership.

284
00:14:11,760 --> 00:14:15,760
And it certainly won't solve a week security model, an AI assistant works best when the

285
00:14:15,760 --> 00:14:18,720
layers sitting below it already make logical sense.

286
00:14:18,720 --> 00:14:21,480
And why does this model actually hold up in the real world?

287
00:14:21,480 --> 00:14:25,080
It works because it maps directly to how a business functions.

288
00:14:25,080 --> 00:14:28,800
Executives can use these categories to ask better questions during a project kickoff.

289
00:14:28,800 --> 00:14:32,600
Are we trying to fix how we interact with data, how we execute the work, or how we see

290
00:14:32,600 --> 00:14:34,080
the results?

291
00:14:34,080 --> 00:14:37,880
Architects can use it to distribute responsibilities across the stack without collapsing

292
00:14:37,880 --> 00:14:40,520
every requirement into a single bloated tool.

293
00:14:40,520 --> 00:14:44,320
And the makers benefit because it keeps them from overloading the very first product they

294
00:14:44,320 --> 00:14:45,520
happen to open.

295
00:14:45,520 --> 00:14:48,680
Governance teams also find value here because it makes risk visible.

296
00:14:48,680 --> 00:14:52,360
They can see exactly where a threat might enter, whether that is at the identity layer,

297
00:14:52,360 --> 00:14:55,360
the automation logic, or the external exposure point.

298
00:14:55,360 --> 00:14:58,800
This discipline helps us avoid the most common mistake in digital transformation, which

299
00:14:58,800 --> 00:15:02,720
is confusing what a user sees with what the business actually needs to survive.

300
00:15:02,720 --> 00:15:05,480
People usually ask for the part they can visualize in their heads.

301
00:15:05,480 --> 00:15:06,640
They imagine a screen.

302
00:15:06,640 --> 00:15:11,120
They rarely imagine the workflow orchestration, the data ownership, or the access boundaries

303
00:15:11,120 --> 00:15:12,640
that keep the lights on.

304
00:15:12,640 --> 00:15:16,400
Yet those hidden layers are exactly what determines if a solution will still be running

305
00:15:16,400 --> 00:15:19,480
six months after the initial enthusiasm fades away.

306
00:15:19,480 --> 00:15:22,320
This mental model gives us a simple, repeatable discipline.

307
00:15:22,320 --> 00:15:27,000
When a new request hits your desk, don't start by asking which tool the team likes the most.

308
00:15:27,000 --> 00:15:30,560
Instead, ask these questions, where do the people interact with the system?

309
00:15:30,560 --> 00:15:32,240
Where does the logic actually execute?

310
00:15:32,240 --> 00:15:33,800
Where does our visibility come from?

311
00:15:33,800 --> 00:15:36,040
Who is standing inside the boundary and who is outside?

312
00:15:36,040 --> 00:15:38,440
What should an assistant help with if anything at all?

313
00:15:38,440 --> 00:15:43,280
Once you separate these jobs, the conversation about which tool to buy or build becomes much easier.

314
00:15:43,280 --> 00:15:47,040
We can finally test each piece of technology against the reality of the business process

315
00:15:47,040 --> 00:15:52,120
instead of treating the entire platform like one giant blurry answer to every problem.

316
00:15:52,120 --> 00:15:55,320
Power Apps, where interface solves friction, not structure.

317
00:15:55,320 --> 00:15:59,200
Now let's take that first layer and test it against a real world scenario.

318
00:15:59,200 --> 00:16:03,760
Power Apps is almost always where teams want to start because it provides the most immediate

319
00:16:03,760 --> 00:16:04,760
gratification.

320
00:16:04,760 --> 00:16:08,720
You can open the designer, drag a few elements onto a screen and show the stakeholders

321
00:16:08,720 --> 00:16:11,680
something that looks like progress within an hour.

322
00:16:11,680 --> 00:16:14,240
That visibility creates a lot of confidence.

323
00:16:14,240 --> 00:16:18,120
And a working interface helps people believe that real change is finally happening, but

324
00:16:18,120 --> 00:16:21,240
we have to remember that the interface is not the process itself.

325
00:16:21,240 --> 00:16:25,680
It is just the point of contact between a human being and a system that still requires

326
00:16:25,680 --> 00:16:27,420
structure behind the curtain.

327
00:16:27,420 --> 00:16:30,640
That distinction is more important than most project teams realize.

328
00:16:30,640 --> 00:16:34,840
In a standard vacation request process, power apps can absolutely remove the pain of the

329
00:16:34,840 --> 00:16:36,000
initial step.

330
00:16:36,000 --> 00:16:40,560
An employee opens a simple form on their phone, picks their dates and submits the request

331
00:16:40,560 --> 00:16:43,040
through a guided flow that prevents mistakes.

332
00:16:43,040 --> 00:16:47,240
The manager then opens a dedicated task view to see all pending requests and clicks a single

333
00:16:47,240 --> 00:16:49,160
button to approve or reject them.

334
00:16:49,160 --> 00:16:52,880
Even the HR team gets a specialized view with filters and status tracking to handle the

335
00:16:52,880 --> 00:16:53,880
exceptions.

336
00:16:53,880 --> 00:16:58,040
This is real, measurable value because it removes the guesswork and lowers the mental effort

337
00:16:58,040 --> 00:16:59,120
for everyone involved.

338
00:16:59,120 --> 00:17:01,360
This is exactly what power apps was built to do.

339
00:17:01,360 --> 00:17:03,280
It excels at guided input.

340
00:17:03,280 --> 00:17:05,720
It provides a clean, modern user experience.

341
00:17:05,720 --> 00:17:08,080
It makes task completion feel effortless.

342
00:17:08,080 --> 00:17:12,360
It replaces the chaos of a loose email chain with a structured, predictable interaction.

343
00:17:12,360 --> 00:17:16,760
If your current failure is that people don't know what to submit or where to send it, then

344
00:17:16,760 --> 00:17:19,480
a well-designed interface will move the needle immediately.

345
00:17:19,480 --> 00:17:21,680
But you have to look at what it doesn't fix on its own.

346
00:17:21,680 --> 00:17:24,360
An app doesn't define who is responsible for an escalation.

347
00:17:24,360 --> 00:17:27,800
It doesn't create the discipline required for a manager to actually do their job.

348
00:17:27,800 --> 00:17:30,360
It doesn't solve the underlying logic of your reporting.

349
00:17:30,360 --> 00:17:34,680
It won't turn a messy, unmanaged spreadsheet into a piece of governed corporate data.

350
00:17:34,680 --> 00:17:38,760
It doesn't even decide if the record should live in a SharePoint list or a professional

351
00:17:38,760 --> 00:17:40,360
database like Dataverse.

352
00:17:40,360 --> 00:17:43,640
When a team says they need an app, they usually mean they want to reduce the friction of

353
00:17:43,640 --> 00:17:44,640
the interaction.

354
00:17:44,640 --> 00:17:48,640
While that might be true, it is almost never the whole story of why the process is broken.

355
00:17:48,640 --> 00:17:52,720
This is often where power apps get blamed for things it was never meant to solve.

356
00:17:52,720 --> 00:17:56,760
A team will build a beautiful form with great colors and easy buttons.

357
00:17:56,760 --> 00:17:59,600
The action rates go up and everyone is happy for about two weeks.

358
00:17:59,600 --> 00:18:03,440
Then the same old delays start creeping back in because the bottleneck was never the form.

359
00:18:03,440 --> 00:18:08,480
The real problem was a manager who had no automated reminders, no clear escalation path,

360
00:18:08,480 --> 00:18:12,280
and no accountability for how long a request sat on their desk.

361
00:18:12,280 --> 00:18:16,040
From a system perspective, the app did its job perfectly by removing the input friction,

362
00:18:16,040 --> 00:18:19,240
but the rest of the system kept failing exactly where it was already weak.

363
00:18:19,240 --> 00:18:20,640
That isn't the sign of a bad app.

364
00:18:20,640 --> 00:18:22,720
It is the sign of a misplaced expectation.

365
00:18:22,720 --> 00:18:26,600
Inside the world of power apps, there is another choice that often trips people up.

366
00:18:26,600 --> 00:18:30,680
To rebuild a canvas app or a model-driven app, I find the best way to frame this isn't

367
00:18:30,680 --> 00:18:35,160
through technical jargon, but through the operational goal you are trying to reach.

368
00:18:35,160 --> 00:18:37,040
Canvas apps are centered on the experience.

369
00:18:37,040 --> 00:18:42,120
You have total freedom to shape the interface around a specific task, which makes them perfect

370
00:18:42,120 --> 00:18:46,240
when the interaction needs to feel simple and tailored to a mobile user.

371
00:18:46,240 --> 00:18:48,160
Model-driven apps are centered on the data.

372
00:18:48,160 --> 00:18:52,400
They are much stronger when your process depends on complex relationships, massive sets of

373
00:18:52,400 --> 00:18:56,480
records, and tight operational control over how that data is managed.

374
00:18:56,480 --> 00:19:00,680
If you want a high-end experience for an employee submitting a request, a canvas app is likely

375
00:19:00,680 --> 00:19:01,800
the right fit.

376
00:19:01,800 --> 00:19:06,120
If your HR department needs a heavy duty workspace to manage thousands of records and

377
00:19:06,120 --> 00:19:10,080
related documents, the model-driven approach is going to be much more resilient.

378
00:19:10,080 --> 00:19:13,160
They are different users doing different jobs with different requirements.

379
00:19:13,160 --> 00:19:16,080
This is why saying let's build an app is only half of a thought.

380
00:19:16,080 --> 00:19:20,160
The second a user hits that submit button, the real work moves away from the screen and

381
00:19:20,160 --> 00:19:22,600
into the world of routing, state changes, and ownership.

382
00:19:22,600 --> 00:19:25,880
The system has to carry that request from one person to the next.

383
00:19:25,880 --> 00:19:30,240
Without relying on someone's memory or a lucky break in an overflowing inbox, power apps

384
00:19:30,240 --> 00:19:33,960
can remove the friction of the moment, but it should never be asked to compensate for

385
00:19:33,960 --> 00:19:37,040
a structural weakness that exists outside the screen.

386
00:19:37,040 --> 00:19:39,240
Use it to make the next action crystal clear.

387
00:19:39,240 --> 00:19:41,440
Use it to force better data into your system.

388
00:19:41,440 --> 00:19:44,720
Use it to lower the effort for the people who have to use it every day.

389
00:19:44,720 --> 00:19:48,480
But never mistake a shiny new interface for a strong operating model, because once

390
00:19:48,480 --> 00:19:53,080
that submit button is pressed, the system has to prove it can actually execute the work.

391
00:19:53,080 --> 00:19:56,040
Power Automate, where process becomes executable.

392
00:19:56,040 --> 00:19:59,560
Now we move from the interface you see to the execution you don't.

393
00:19:59,560 --> 00:20:02,800
The moment an employee hits, submit on a vacation request.

394
00:20:02,800 --> 00:20:06,720
The value of your solution stops being about how the screen looks and starts being about

395
00:20:06,720 --> 00:20:07,720
what happens next.

396
00:20:07,720 --> 00:20:10,920
This is where power automate enters the picture, and it's usually the point where teams

397
00:20:10,920 --> 00:20:14,640
finally discover if they actually understood their own process.

398
00:20:14,640 --> 00:20:17,080
Power Automate isn't the pretty part of the stack.

399
00:20:17,080 --> 00:20:21,160
It is the engine that decides whether work actually moves or just sits there.

400
00:20:21,160 --> 00:20:25,360
It can also just look simple on the surface, because a request comes in and the right manager

401
00:20:25,360 --> 00:20:26,680
gets an approval task.

402
00:20:26,680 --> 00:20:30,880
If that manager doesn't act within a certain window, a reminder triggers, and if they still

403
00:20:30,880 --> 00:20:35,240
don't respond, the system escalates the request or flags it for a follow-up.

404
00:20:35,240 --> 00:20:39,240
Once the approval finally happens, HR gets an update, the employee gets a notification,

405
00:20:39,240 --> 00:20:42,360
and the status changes as the record writes back to the data source.

406
00:20:42,360 --> 00:20:46,080
That entire chain matters because it removes the heavy lifting of people having to remember

407
00:20:46,080 --> 00:20:47,480
what the next step is.

408
00:20:47,480 --> 00:20:49,160
And that is the real job of automation.

409
00:20:49,160 --> 00:20:53,960
It isn't about magic or speed for its own sake, it's about operational continuity.

410
00:20:53,960 --> 00:20:59,040
Power Automate is exceptionally good at routing, notifications, and managing approvals, but

411
00:20:59,040 --> 00:21:04,520
its real strength is connecting one step to the next so the process survives human distraction.

412
00:21:04,520 --> 00:21:08,800
That last part is more important than most leaders admit, because business processes are rarely

413
00:21:08,800 --> 00:21:10,120
broken by complexity.

414
00:21:10,120 --> 00:21:12,800
They are almost always broken by simple interruption.

415
00:21:12,800 --> 00:21:16,960
Someone gets busy, someone else forgets, or a message sits unread in an inbox while a spreadsheet

416
00:21:16,960 --> 00:21:22,160
stays outdated and the organization calls it inefficiency when it's actually just a design problem.

417
00:21:22,160 --> 00:21:24,680
Automation reduces that kind of structural fragility.

418
00:21:24,680 --> 00:21:28,800
In the case of Contoso, the first hard metric this tool moves is cycle time.

419
00:21:28,800 --> 00:21:33,960
If an approval path currently takes five days because work sits in inboxes without any structure,

420
00:21:33,960 --> 00:21:37,400
a well-shaped flow can compress that time dramatically.

421
00:21:37,400 --> 00:21:40,880
This doesn't happen because the managers suddenly change their personalities, but because

422
00:21:40,880 --> 00:21:45,840
the system stopped depending on memory, vague ownership, and manual handoffs to get things

423
00:21:45,840 --> 00:21:46,840
done.

424
00:21:46,840 --> 00:21:51,560
That is a massive shift for any business, but it also exposes a reality that can be a bit

425
00:21:51,560 --> 00:21:52,560
uncomfortable.

426
00:21:52,560 --> 00:21:54,320
Flows are brutally honest.

427
00:21:54,320 --> 00:21:57,760
If your process is ambiguous, the flow will show you exactly where the holes are.

428
00:21:57,760 --> 00:21:59,200
Who is supposed to approve first?

429
00:21:59,200 --> 00:22:01,840
What happens if an employee reports to two different managers?

430
00:22:01,840 --> 00:22:04,720
Does the leave type require an HR review every time?

431
00:22:04,720 --> 00:22:06,200
Or just in certain cases?

432
00:22:06,200 --> 00:22:10,480
What counts as approved if the manager is absent and nobody responds to the notification?

433
00:22:10,480 --> 00:22:13,560
These questions were always there, but email was great at hiding them.

434
00:22:13,560 --> 00:22:17,440
Once you try to automate the workflow, that ambiguity becomes visible immediately.

435
00:22:17,440 --> 00:22:21,400
This is why I always say that automation doesn't actually remove process problems, it just

436
00:22:21,400 --> 00:22:23,400
reveals them in an executable form.

437
00:22:23,400 --> 00:22:27,400
That visibility is useful because hidden ambiguity is incredibly expensive.

438
00:22:27,400 --> 00:22:32,480
It creates constant exceptions, extra support effort, and political friction between departments.

439
00:22:32,480 --> 00:22:36,200
A flow force is the team to define the path, and while that definition work feels slow

440
00:22:36,200 --> 00:22:39,880
in a workshop, it saves massive operating costs down the road.

441
00:22:39,880 --> 00:22:41,800
There is still a trap you have to watch out for.

442
00:22:41,800 --> 00:22:45,520
Many teams reach for power to automate too early because they think they can speed everything

443
00:22:45,520 --> 00:22:46,520
up.

444
00:22:46,520 --> 00:22:51,640
But if the underlying process is still confused, all you are doing is accelerating that confusion.

445
00:22:51,640 --> 00:22:53,400
Bad categorizations move faster.

446
00:22:53,400 --> 00:22:58,400
Weak approvals happen faster, and inconsistent records spread through the business faster,

447
00:22:58,400 --> 00:23:01,680
making the flow a very efficient way to produce the wrong outcome.

448
00:23:01,680 --> 00:23:04,200
So the test isn't whether you can automate something.

449
00:23:04,200 --> 00:23:08,280
The better question is whether the process is clear enough to execute without needing human

450
00:23:08,280 --> 00:23:10,120
interpretation at every single step.

451
00:23:10,120 --> 00:23:14,080
If the answer is no, you are still in the process design phase, not the automation design

452
00:23:14,080 --> 00:23:15,080
phase.

453
00:23:15,080 --> 00:23:19,640
When used well, power automate gives Contoso a real operating backbone where requests stop

454
00:23:19,640 --> 00:23:23,720
drifting between inboxes and handoffs no longer depend on professional courtesy.

455
00:23:23,720 --> 00:23:28,400
Status stops living inside conversations, and once that happens, the organization gets

456
00:23:28,400 --> 00:23:30,640
something much more valuable than speed.

457
00:23:30,640 --> 00:23:32,200
It gets reliability.

458
00:23:32,200 --> 00:23:36,440
But reliability without visibility has its own limit, because a process can run every

459
00:23:36,440 --> 00:23:40,760
day and still create hidden bottlenecks that nobody sees until the complaints return in a different

460
00:23:40,760 --> 00:23:41,760
form.

461
00:23:41,760 --> 00:23:44,960
Power BI, where visibility, becomes management.

462
00:23:44,960 --> 00:23:49,000
Now we reach the layer that many teams treat as an afterthought, even though it should influence

463
00:23:49,000 --> 00:23:51,160
the design much earlier in the project.

464
00:23:51,160 --> 00:23:55,640
Power BI is where the process stops being anecdotal and starts becoming governable.

465
00:23:55,640 --> 00:24:00,240
At Contoso, once requests are entering the system cleanly and flowing through a defined path,

466
00:24:00,240 --> 00:24:02,880
leadership still needs to answer a different kind of question.

467
00:24:02,880 --> 00:24:07,040
They don't need to know if someone can submit leave or if an approval email went out.

468
00:24:07,040 --> 00:24:09,840
They need to know what the process is doing to the business over time.

469
00:24:09,840 --> 00:24:11,000
That is a reporting question.

470
00:24:11,000 --> 00:24:14,960
And reporting isn't just decoration for a slide deck, it is a control layer.

471
00:24:14,960 --> 00:24:19,400
Without visibility, a process can be fully digitized and still remain completely unmanaged.

472
00:24:19,400 --> 00:24:24,280
Work moves, notifications fire and records update so people assume progress is happening.

473
00:24:24,280 --> 00:24:28,840
But nobody sees the buildup of delays, the repeat exceptions, or the quiet drift in data

474
00:24:28,840 --> 00:24:33,720
quality until it becomes another operational disaster that someone has to clean up by hand.

475
00:24:33,720 --> 00:24:35,800
So what does Power BI actually do well here?

476
00:24:35,800 --> 00:24:39,440
It shows trends, it identifies bottlenecks and it flags exceptions.

477
00:24:39,440 --> 00:24:42,560
It turns isolated events into a pattern you can actually manage.

478
00:24:42,560 --> 00:24:46,720
At Contoso, a useful dashboard wouldn't start with vanity numbers that make everyone feel

479
00:24:46,720 --> 00:24:47,720
good.

480
00:24:47,720 --> 00:24:50,880
It would start with operational questions that map directly to the three metrics we care

481
00:24:50,880 --> 00:24:54,520
about, cycle time, error rate and cost to serve.

482
00:24:54,520 --> 00:24:58,280
We might show the average approval time broken down by manager or department to see where

483
00:24:58,280 --> 00:24:59,280
the friction is.

484
00:24:59,280 --> 00:25:04,120
We could show exactly how many requests sit untouched after 2448 or 72 hours.

485
00:25:04,120 --> 00:25:08,240
We might track where HR is spending the most time correcting leaf categories or chasing

486
00:25:08,240 --> 00:25:12,680
down missing fields or show overlap trends by team so leaders can spot staffing pressure

487
00:25:12,680 --> 00:25:14,920
before it turns into a delivery crisis.

488
00:25:14,920 --> 00:25:16,880
Now the entire conversation changes.

489
00:25:16,880 --> 00:25:21,080
Instead of hearing that approvals feel slow lately, leaders can see exactly where they

490
00:25:21,080 --> 00:25:24,240
are slow, who is responsible and how long the delay has lasted.

491
00:25:24,240 --> 00:25:28,880
Instead of hearing that HR keeps fixing mistakes, they can see which categories trigger the

492
00:25:28,880 --> 00:25:32,080
most corrections and exactly where those bad entries are coming from.

493
00:25:32,080 --> 00:25:36,960
Instead of hearing that the team seems short-staffed every August, they can map absence patterns

494
00:25:36,960 --> 00:25:40,920
against actual workload and planning cycles that shift matters because executives cannot

495
00:25:40,920 --> 00:25:42,240
manage stories at scale.

496
00:25:42,240 --> 00:25:43,760
They manage signals.

497
00:25:43,760 --> 00:25:47,120
This is where Power BI earns its place in the architecture because it gives management

498
00:25:47,120 --> 00:25:52,120
a way to observe process behavior without relying on complaints as an alert mechanism.

499
00:25:52,120 --> 00:25:57,040
It also helps with something people often underestimate which is error reduction through simple visibility.

500
00:25:57,040 --> 00:26:00,640
A lot of inconsistency survives in a business simply because nobody can see it all in one

501
00:26:00,640 --> 00:26:01,640
place.

502
00:26:01,640 --> 00:26:06,120
One manager might approve leave as vacation, while another calls it annual leave.

503
00:26:06,120 --> 00:26:09,840
And while HR normalizes some of those entries, they inevitably miss others.

504
00:26:09,840 --> 00:26:14,360
The process still runs, but the reporting layer starts to reveal that category drift and

505
00:26:14,360 --> 00:26:19,360
the patterns of bad input that would otherwise stay hidden inside the daily operational noise.

506
00:26:19,360 --> 00:26:21,960
That means reporting isn't just for the leaders at the top.

507
00:26:21,960 --> 00:26:24,160
It is feedback for the design of the system itself.

508
00:26:24,160 --> 00:26:28,320
If the dashboard keeps surfacing messy categories, the problem might not be in Power BI at all.

509
00:26:28,320 --> 00:26:31,840
It likely points back to the app, the data model, or the approval logic.

510
00:26:31,840 --> 00:26:34,240
The reporting layer does more than just observe outcomes.

511
00:26:34,240 --> 00:26:37,120
It tells us exactly where the rest of the solution is still weak.

512
00:26:37,120 --> 00:26:40,680
This is why I never treat Power BI as the thing you add once the build is finished.

513
00:26:40,680 --> 00:26:42,720
I treat it as the way you close the loop.

514
00:26:42,720 --> 00:26:46,320
You build the interaction layer, you build the process layer, and then you make the behavior

515
00:26:46,320 --> 00:26:47,320
visible.

516
00:26:47,320 --> 00:26:50,760
Because once behavior becomes visible, management can intervene much earlier, governance

517
00:26:50,760 --> 00:26:55,080
gets sharper and improvement stops depending on someone raising their hand in frustration.

518
00:26:55,080 --> 00:26:58,440
At that point, Contoso is no longer just processing vacation requests.

519
00:26:58,440 --> 00:27:03,680
It is learning from the process while it runs, and that is a very different level of maturity.

520
00:27:03,680 --> 00:27:07,680
But some processes do not stop at the edge of the company, which means visibility and workflow

521
00:27:07,680 --> 00:27:12,840
still aren't enough if the people who need access are not actually inside your tenant.

522
00:27:12,840 --> 00:27:15,720
Power pages when the process crosses the company boundary.

523
00:27:15,720 --> 00:27:19,760
Now we reach a boundary that changes the design more than most teams expect, and it shifts

524
00:27:19,760 --> 00:27:24,120
the entire conversation from internal efficiency to external trust.

525
00:27:24,120 --> 00:27:28,000
Up to this point, our work at Contoso has stayed within a single house where employees

526
00:27:28,000 --> 00:27:31,880
request leave, managers approve those requests, and HR updates the records.

527
00:27:31,880 --> 00:27:35,320
Everything fits inside one organizational trust model, and while the process still needs

528
00:27:35,320 --> 00:27:38,520
discipline to work, everyone involved is already on the payroll.

529
00:27:38,520 --> 00:27:40,960
But not every process stays inside the company walls.

530
00:27:40,960 --> 00:27:44,800
The moment suppliers, contractors, applicants or partners need to interact with that same

531
00:27:44,800 --> 00:27:48,200
business flow, you are no longer just solving for usability.

532
00:27:48,200 --> 00:27:52,520
You are solving for boundary control, which is a much more sensitive architectural challenge.

533
00:27:52,520 --> 00:27:54,680
And that is where power pages start to matter.

534
00:27:54,680 --> 00:27:58,480
Power pages is not just a website builder in the casual sense, and treating it like one

535
00:27:58,480 --> 00:28:00,960
is a mistake that leads to major security gaps.

536
00:28:00,960 --> 00:28:05,320
In the power platform world, this tool serves as the front door for external users who need

537
00:28:05,320 --> 00:28:08,640
structured access without being dropped into your internal environment.

538
00:28:08,640 --> 00:28:12,960
That difference is vital because internal tools carry assumptions about identity and permissions

539
00:28:12,960 --> 00:28:16,840
that usually break the moment you force them onto people outside your tenant.

540
00:28:16,840 --> 00:28:18,480
I see this mistake happen constantly.

541
00:28:18,480 --> 00:28:22,840
The team builds a great tool for internal staff, and then a stakeholder asks if they can

542
00:28:22,840 --> 00:28:26,200
just let contractors use the same interface to save time.

543
00:28:26,200 --> 00:28:29,920
While that might be technically possible in a few narrow cases, it is almost always the

544
00:28:29,920 --> 00:28:31,840
wrong move structurally.

545
00:28:31,840 --> 00:28:35,840
Internal apps forced onto external users tend to create massive security problems and support

546
00:28:35,840 --> 00:28:39,160
friction that eventually makes life miserable for everybody involved.

547
00:28:39,160 --> 00:28:40,160
Why is that?

548
00:28:40,160 --> 00:28:44,040
Because external access is not just a smaller restricted version of internal access, it is

549
00:28:44,040 --> 00:28:46,120
a completely different architecture problem.

550
00:28:46,120 --> 00:28:49,880
Make a simple extension of the Contoso case where the company brings in seasonal workers

551
00:28:49,880 --> 00:28:51,280
through an outside agency.

552
00:28:51,280 --> 00:28:54,720
Those contractors might need to submit their availability, confirm their assignments,

553
00:28:54,720 --> 00:28:57,720
or upload required documents to finish their onboarding steps.

554
00:28:57,720 --> 00:29:02,400
Now we have a process that touches real operational data, but the people interacting with it are

555
00:29:02,400 --> 00:29:05,920
not standard internal users who understand your company culture.

556
00:29:05,920 --> 00:29:09,880
They should not see the internal mess, they should not inherit your internal navigation,

557
00:29:09,880 --> 00:29:13,520
and they definitely should not get broad access just because the original process started

558
00:29:13,520 --> 00:29:15,400
as an employee request.

559
00:29:15,400 --> 00:29:20,480
So the right question becomes, what is the smallest, safest, and clearest surface we can expose

560
00:29:20,480 --> 00:29:21,640
to the outside world?

561
00:29:21,640 --> 00:29:24,520
That is the specific job power pages was built to handle.

562
00:29:24,520 --> 00:29:29,360
It gives you an external facing experience connected to the same platform, logic, usually

563
00:29:29,360 --> 00:29:34,080
through data verse, without turning your internal architecture into a public hallway.

564
00:29:34,080 --> 00:29:38,240
The data stays part of the broader solution model, and the process can still trigger automated

565
00:29:38,240 --> 00:29:42,680
flows, but the external user gets a shaped entry point instead of accidental access to

566
00:29:42,680 --> 00:29:43,960
the whole building.

567
00:29:43,960 --> 00:29:47,280
That separation creates a few practical benefits for the business.

568
00:29:47,280 --> 00:29:51,440
First, security becomes much more intentional because you define access for the external role

569
00:29:51,440 --> 00:29:54,400
instead of trying to patch holes in your internal permissions.

570
00:29:54,400 --> 00:29:59,600
Second, the user experience improves significantly because external users only see what they actually

571
00:29:59,600 --> 00:30:03,040
need in a language and path that fits their specific job.

572
00:30:03,040 --> 00:30:07,120
Third, your support desk will have an easier time because they are no longer explaining a complex

573
00:30:07,120 --> 00:30:10,760
internal app design to people who are never meant to live inside it.

574
00:30:10,760 --> 00:30:13,480
Now I also want to keep this grounded in reality.

575
00:30:13,480 --> 00:30:14,760
Not every portal needs to exist.

576
00:30:14,760 --> 00:30:19,080
A lot of organizations create portals because the idea sounds mature and professional, but

577
00:30:19,080 --> 00:30:22,800
the actual process doesn't always justify adding a new boundary layer.

578
00:30:22,800 --> 00:30:27,080
If your interaction volume is tiny, or the use case is only temporary, then using email

579
00:30:27,080 --> 00:30:32,320
plus a secure upload path might handle the job well enough without the overhead of a full

580
00:30:32,320 --> 00:30:33,320
portal.

581
00:30:33,320 --> 00:30:37,640
Powerpages is not the automatic answer every time an external person appears in your business

582
00:30:37,640 --> 00:30:38,640
story.

583
00:30:38,640 --> 00:30:42,760
But when the process genuinely crosses the company boundary and repeat interaction matters,

584
00:30:42,760 --> 00:30:45,640
and it becomes a very clean and resilient design choice.

585
00:30:45,640 --> 00:30:50,240
That choice matters more as your platform solutions grow, because once external and internal

586
00:30:50,240 --> 00:30:55,520
users start sharing the same underlying business flow, a weak boundary design becomes a direct

587
00:30:55,520 --> 00:30:57,200
risk to the company.

588
00:30:57,200 --> 00:31:01,840
Which brings me to the layer, people are overestimating and undergoverning at the same time.

589
00:31:01,840 --> 00:31:06,040
Co-Pilot Studio, the assistant is not the architecture, and now we get to the layer that

590
00:31:06,040 --> 00:31:08,000
creates the most excitement.

591
00:31:08,000 --> 00:31:10,240
And in a lot of organizations, the most confusion.

592
00:31:10,240 --> 00:31:14,600
Co-Pilot Studio adds a conversational layer to the platform, which means people can ask

593
00:31:14,600 --> 00:31:18,240
questions in natural language and move through a process without navigating a complex

594
00:31:18,240 --> 00:31:19,400
abstracture.

595
00:31:19,400 --> 00:31:23,120
When you use it well, it reduces friction for common interactions and gives people a

596
00:31:23,120 --> 00:31:26,040
faster path into the work they are already trying to do.

597
00:31:26,040 --> 00:31:28,120
But we need to place it correctly in our minds.

598
00:31:28,120 --> 00:31:30,240
Co-Pilot Studio is not the process model.

599
00:31:30,240 --> 00:31:33,760
It is not the data model, it is not the security model, it is simply the assistant layer

600
00:31:33,760 --> 00:31:36,080
sitting on top of those foundational things.

601
00:31:36,080 --> 00:31:40,120
That distinction is critical because many teams are starting to treat AI like a shortcut

602
00:31:40,120 --> 00:31:41,400
around good architecture.

603
00:31:41,400 --> 00:31:45,480
They assume the assistant can compensate for weak navigation or poor data structure, but

604
00:31:45,480 --> 00:31:50,480
it cannot and it will usually just expose those weaknesses in a more conversational format.

605
00:31:50,480 --> 00:31:54,080
To place this properly in the power platform story, it helps to remember that Co-Pilot Studio

606
00:31:54,080 --> 00:31:57,360
is the evolution of what we use to call power virtual agents.

607
00:31:57,360 --> 00:32:01,760
While the old chatbot framing still helps explain how it behaves, the scope is much broader

608
00:32:01,760 --> 00:32:05,000
now that we are moving past scripted question and answer bots.

609
00:32:05,000 --> 00:32:08,840
We are talking about agents that can connect to knowledge and trigger flows, acting as a

610
00:32:08,840 --> 00:32:12,320
sophisticated front layer to your entire business capability.

611
00:32:12,320 --> 00:32:15,000
At Contoso that could be genuinely helpful for the staff.

612
00:32:15,000 --> 00:32:18,680
An employee could ask how many vacation days they have left or they could check the

613
00:32:18,680 --> 00:32:22,000
specific leaf policy for carrying days over into the next year.

614
00:32:22,000 --> 00:32:25,720
They could even start a formal request directly from the conversation and the assistant would

615
00:32:25,720 --> 00:32:29,760
guide them through the right steps and trigger the downstream process automatically.

616
00:32:29,760 --> 00:32:33,760
That sounds good because it is good, but only when the foundation underneath the assistant

617
00:32:33,760 --> 00:32:34,760
is stable.

618
00:32:34,760 --> 00:32:38,520
If the leaf balances are actually trustworthy and the request status is kept current, then

619
00:32:38,520 --> 00:32:40,920
the assistant becomes a powerful access layer.

620
00:32:40,920 --> 00:32:44,840
It reduces the cost of navigation and lowers the effort required to find answers, giving

621
00:32:44,840 --> 00:32:47,440
people a more natural way to interact with the system.

622
00:32:47,440 --> 00:32:50,760
But map that same idea onto a weak foundation and things fall apart.

623
00:32:50,760 --> 00:32:55,720
If leaf balances are stored in two different places and the approval status updates late,

624
00:32:55,720 --> 00:32:59,120
the assistant will still respond with a confident tone.

625
00:32:59,120 --> 00:33:02,680
It will still root people somewhere, but because it is sitting on an unstable base, it will

626
00:33:02,680 --> 00:33:05,000
scale confusion instead of reducing it.

627
00:33:05,000 --> 00:33:07,360
This is why I keep the placement of this tool very firm.

628
00:33:07,360 --> 00:33:09,600
AI should sit on top of a stable process.

629
00:33:09,600 --> 00:33:11,440
It should never be asked to replace one.

630
00:33:11,440 --> 00:33:15,440
And this matters even more because the current direction of the industry is clear.

631
00:33:15,440 --> 00:33:19,560
Agents are becoming the primary acceleration layer across the entire Microsoft stack.

632
00:33:19,560 --> 00:33:23,560
They can answer, root, and summarize work across systems, which is incredibly useful, but

633
00:33:23,560 --> 00:33:25,640
also carries a very specific kind of risk.

634
00:33:25,640 --> 00:33:30,360
The smarter these tools get, the more dangerous your bad architectural decisions become.

635
00:33:30,360 --> 00:33:35,000
A weak app usually fails in a visible way that you can fix, and a weak automation fails

636
00:33:35,000 --> 00:33:39,200
in an operational way that shows up in your logs, but a weak assistant can fail in a persuasive

637
00:33:39,200 --> 00:33:42,920
way, which is much harder to detect because people tend to trust the interaction before

638
00:33:42,920 --> 00:33:45,080
they ever think to verify the foundation.

639
00:33:45,080 --> 00:33:48,640
So for leaders and architects, the question is not whether you should use Copilot Studio.

640
00:33:48,640 --> 00:33:53,200
The better question is, what stable capability is this assistant actually sitting on top of?

641
00:33:53,200 --> 00:33:57,400
If the answer to that is unclear, then the assistant is arriving too early in your roadmap.

642
00:33:57,400 --> 00:34:02,480
If the answer is strong, then Copilot Studio can be a very practical layer for policy guidance,

643
00:34:02,480 --> 00:34:05,880
status retrieval, and conversational entry into your structured actions.

644
00:34:05,880 --> 00:34:09,640
So yes, use the assistant, but do not confuse it with the architecture because the moment

645
00:34:09,640 --> 00:34:14,960
you do that, you stop designing a real operating model and start hoping the interface can think

646
00:34:14,960 --> 00:34:17,680
its way out of your structural weaknesses.

647
00:34:17,680 --> 00:34:22,040
Once we can see that clearly we are finally ready for the harder part, which is how to choose

648
00:34:22,040 --> 00:34:26,400
among these tools in a way that holds up before the first build even starts.

649
00:34:26,400 --> 00:34:28,800
The three forces model, data gravity.

650
00:34:28,800 --> 00:34:33,040
We have separated our tools by role, but that still doesn't tell us where the work actually

651
00:34:33,040 --> 00:34:34,040
begins.

652
00:34:34,040 --> 00:34:36,920
This is where I introduce a concept I've been thinking about lately, which I call the three

653
00:34:36,920 --> 00:34:37,920
forces model.

654
00:34:37,920 --> 00:34:40,040
The first of these forces is data gravity.

655
00:34:40,040 --> 00:34:41,040
And why is that?

656
00:34:41,040 --> 00:34:44,920
It's because every decision you make later gets pulled by where the data already lives,

657
00:34:44,920 --> 00:34:49,240
how it's structured, who owns it, and how much you can actually trust it under pressure.

658
00:34:49,240 --> 00:34:53,640
If you ignore that force, the rest of your design will start to drift almost immediately.

659
00:34:53,640 --> 00:34:56,280
At Contoso, this is the question beneath the question.

660
00:34:56,280 --> 00:35:00,440
We aren't just asking if we need an app, we're asking where the vacation request actually

661
00:35:00,440 --> 00:35:01,440
becomes real.

662
00:35:01,440 --> 00:35:06,520
Is the source of truth sitting in a manager's inbox or is it tucked away in an HR spreadsheet?

663
00:35:06,520 --> 00:35:10,320
Maybe it's a share point list someone created last year or perhaps it's an ERP system that

664
00:35:10,320 --> 00:35:11,840
already stores leave balances.

665
00:35:11,840 --> 00:35:15,080
If nobody can answer that clearly, then the build is already unstable.

666
00:35:15,080 --> 00:35:19,280
Because if your process writes to three places, reads from two others and still depends on

667
00:35:19,280 --> 00:35:22,960
one spreadsheet for reconciliation, you don't have a platform problem.

668
00:35:22,960 --> 00:35:24,280
You have a gravity problem.

669
00:35:24,280 --> 00:35:28,640
The data is scattered and every new layer you add will eventually get dragged into that

670
00:35:28,640 --> 00:35:29,640
fragmentation.

671
00:35:29,640 --> 00:35:34,000
This is why Quick Builds feel good on day one, but become incredibly expensive later.

672
00:35:34,000 --> 00:35:37,920
A team usually starts with the easiest available source, which is often a share point list or

673
00:35:37,920 --> 00:35:38,920
an Excel file.

674
00:35:38,920 --> 00:35:42,440
It works just enough to prove the concept, the app loads and the flow runs.

675
00:35:42,440 --> 00:35:45,880
A few requests get processed and everyone feels like they're making progress, but then

676
00:35:45,880 --> 00:35:46,880
the cracks show up.

677
00:35:46,880 --> 00:35:50,960
A leaf type exists in one place, but not another or a manager's name changes and the system

678
00:35:50,960 --> 00:35:51,960
doesn't catch it.

679
00:35:51,960 --> 00:35:56,160
The record gets updated in the sheet, but not in the app, so HR keeps a side file because

680
00:35:56,160 --> 00:35:58,240
they still don't trust the operational data.

681
00:35:58,240 --> 00:36:02,800
Now reporting becomes an argument about which record is correct and automation turns into

682
00:36:02,800 --> 00:36:06,000
a messenger carrying inconsistency from one point to another.

683
00:36:06,000 --> 00:36:07,400
That is what data gravity does.

684
00:36:07,400 --> 00:36:11,280
It pulls everything toward the real condition of the data layer, not the story we tell ourselves

685
00:36:11,280 --> 00:36:12,280
in the workshop.

686
00:36:12,280 --> 00:36:15,880
So before you start building, you need to ask a harder set of questions.

687
00:36:15,880 --> 00:36:17,120
What is the source of truth?

688
00:36:17,120 --> 00:36:20,480
What is the system of record and what is just a convenience copy?

689
00:36:20,480 --> 00:36:23,660
Who will the process read from and where exactly will it write back?

690
00:36:23,660 --> 00:36:27,940
Who owns the schema when it field changes and who decides what counts as approved, canceled

691
00:36:27,940 --> 00:36:28,940
or exceptional?

692
00:36:28,940 --> 00:36:33,120
How long does this data need to live and who needs access to it six months from now,

693
00:36:33,120 --> 00:36:34,500
not just on Go Live Week?

694
00:36:34,500 --> 00:36:37,120
And then there is one more question that leaders often leave too late.

695
00:36:37,120 --> 00:36:38,760
How sensitive is the data?

696
00:36:38,760 --> 00:36:43,400
Once a process includes personal info, HR records or contractor access, week answers at

697
00:36:43,400 --> 00:36:47,520
the data layer stop being a design annoyance and start becoming a governance problem.

698
00:36:47,520 --> 00:36:51,160
This is why I say very directly that if you don't understand your data, you're not ready

699
00:36:51,160 --> 00:36:52,160
to build.

700
00:36:52,160 --> 00:36:56,760
It's not because the team is incapable, but because the build will inherit every ambiguity

701
00:36:56,760 --> 00:36:57,760
you leave unresolved.

702
00:36:57,760 --> 00:37:02,040
Now, this does not mean every process needs a giant data strategy before anything happens.

703
00:37:02,040 --> 00:37:05,880
We don't need ceremony for the sake of ceremony, but we do need enough clarity to know whether

704
00:37:05,880 --> 00:37:10,440
we are shaping the process around stable records or just digitizing confusion.

705
00:37:10,440 --> 00:37:14,360
Once you understand that a gravity, the first move becomes much easier to judge.

706
00:37:14,360 --> 00:37:18,480
If the main issue at Contoso is scattered records and conflicting categories, then starting

707
00:37:18,480 --> 00:37:20,640
with app design is probably the wrong move.

708
00:37:20,640 --> 00:37:24,680
You might need data cleanup first or a clearer structure or you may need to decide whether

709
00:37:24,680 --> 00:37:29,520
this belongs in DITAverse or if the platform should just orchestrate around another authoritative

710
00:37:29,520 --> 00:37:30,520
source.

711
00:37:30,520 --> 00:37:34,760
If the data is already reliable enough, then the interface or automation can come earlier.

712
00:37:34,760 --> 00:37:37,320
Data gravity is not an abstract architecture term.

713
00:37:37,320 --> 00:37:42,000
It is the force that decides whether your solution sits on a stable floor or a moving one.

714
00:37:42,000 --> 00:37:45,480
Once that force is visible, we can judge the next one, which is the process itself and

715
00:37:45,480 --> 00:37:47,560
how much damage it does when it fails.

716
00:37:47,560 --> 00:37:50,040
The three forces model, process criticality.

717
00:37:50,040 --> 00:37:51,920
The second force is process criticality.

718
00:37:51,920 --> 00:37:55,360
This is where we stop asking only where the data lives and start asking what the business

719
00:37:55,360 --> 00:38:00,520
absorbs when the process fails, slows down or quietly produces bad outcomes for long enough

720
00:38:00,520 --> 00:38:03,400
that nobody notices until the cost shows up.

721
00:38:03,400 --> 00:38:06,920
Because if you look closely, not every workflow deserves the same architecture.

722
00:38:06,920 --> 00:38:11,360
Some processes are occasional, local and low risk, meaning if they break once, the business

723
00:38:11,360 --> 00:38:14,560
feels an inconvenience rather than structural damage.

724
00:38:14,560 --> 00:38:19,000
Other processes look simple on the surface, but sit inside payroll, staffing, compliance

725
00:38:19,000 --> 00:38:20,600
or legal obligations.

726
00:38:20,600 --> 00:38:24,480
When those fail, the blast radius is much bigger than the form that started it.

727
00:38:24,480 --> 00:38:28,160
Contoso's vacation process is a perfect example of that misunderstanding.

728
00:38:28,160 --> 00:38:31,560
Most people here leave request and think of a lightweight admin task that we can clean

729
00:38:31,560 --> 00:38:32,560
up later.

730
00:38:32,560 --> 00:38:36,600
But if you map it properly, it touches workforce planning, manager accountability, payroll

731
00:38:36,600 --> 00:38:38,480
timing and employee trust.

732
00:38:38,480 --> 00:38:42,440
While the interaction feels small, the process is not actually small once it starts moving

733
00:38:42,440 --> 00:38:43,440
through the business.

734
00:38:43,440 --> 00:38:45,080
That is what criticality helps us see.

735
00:38:45,080 --> 00:38:46,400
How often does the process run?

736
00:38:46,400 --> 00:38:47,920
How many people depend on it?

737
00:38:47,920 --> 00:38:50,920
What breaks if it stalls or what breaks if it completes with the wrong data?

738
00:38:50,920 --> 00:38:54,040
And how expensive is the work around when the process does not hold?

739
00:38:54,040 --> 00:38:56,000
Those questions change the build order fast.

740
00:38:56,000 --> 00:39:00,480
If a process runs twice a quarter and affects one team, you can tolerate more manual handling.

741
00:39:00,480 --> 00:39:03,960
You still want clarity and decent control, but you probably do not need to architect it

742
00:39:03,960 --> 00:39:06,120
like a mission critical operating backbone.

743
00:39:06,120 --> 00:39:11,360
However, if a process runs every day and crosses departments while triggering downstream actions,

744
00:39:11,360 --> 00:39:14,960
then weak design stops being a small annoyance and becomes recurring business drag.

745
00:39:14,960 --> 00:39:17,440
That is exactly where Contoso sits today.

746
00:39:17,440 --> 00:39:21,720
Maybe each single request feels minor, but the process repeats constantly and the costs

747
00:39:21,720 --> 00:39:23,120
repeat too.

748
00:39:23,120 --> 00:39:28,040
Managers spend time rereading unclear requests, HR spends time correcting records, and

749
00:39:28,040 --> 00:39:32,160
employees spend time chasing status, teams absorb planning uncertainty because approvals

750
00:39:32,160 --> 00:39:36,320
arrive late or inconsistently, and none of that appears as one dramatic failure.

751
00:39:36,320 --> 00:39:39,920
It shows up as low-grade operational waste spread across the organization.

752
00:39:39,920 --> 00:39:42,600
That is why low criticality framing is so dangerous.

753
00:39:42,600 --> 00:39:46,840
It causes leaders to under design something that keeps producing cost every single week.

754
00:39:46,840 --> 00:39:50,280
So when I assess criticality, I look for three things.

755
00:39:50,280 --> 00:39:53,200
Frequency, dependency, and consequence.

756
00:39:53,200 --> 00:39:57,040
Frequency tells us whether friction compounds over time, dependency tells us how many other

757
00:39:57,040 --> 00:39:59,960
teams or systems rely on the result.

758
00:39:59,960 --> 00:40:04,120
This tells us what the business pays when the process slips, fails or produces the wrong

759
00:40:04,120 --> 00:40:05,120
output.

760
00:40:05,120 --> 00:40:08,760
If you put that back onto power platform selection, the path becomes clear.

761
00:40:08,760 --> 00:40:12,960
If the process is high frequency and high dependency, you need stronger architecture earlier.

762
00:40:12,960 --> 00:40:16,720
That may mean automation becomes a higher priority than interface polish, because execution

763
00:40:16,720 --> 00:40:18,960
reliability matters more than visual improvement.

764
00:40:18,960 --> 00:40:23,040
If the process has real downstream consequence, then reporting cannot be an afterthought because

765
00:40:23,040 --> 00:40:25,520
leaders need a signal before the damage accumulates.

766
00:40:25,520 --> 00:40:29,280
And if the process affects controlled records or regulated decisions, then governance enters

767
00:40:29,280 --> 00:40:31,480
much earlier than teams usually expect.

768
00:40:31,480 --> 00:40:33,760
This is also where the metrics become practical.

769
00:40:33,760 --> 00:40:37,720
Cycle time tells us whether the process moves fast enough to support the business, while

770
00:40:37,720 --> 00:40:41,760
the error rate tells us whether the process can be trusted once it does move.

771
00:40:41,760 --> 00:40:45,960
Cost to serve tells us whether the organization is using expensive human effort to compensate

772
00:40:45,960 --> 00:40:47,200
for weak design.

773
00:40:47,200 --> 00:40:50,720
If none of those metrics matter, the process is probably not very critical, but if all three

774
00:40:50,720 --> 00:40:53,120
matter, you are not building a convenience tool.

775
00:40:53,120 --> 00:40:55,160
You are shaping an operational capability.

776
00:40:55,160 --> 00:41:00,160
This distinction matters because teams often overbuilt low-criticality workflows and underbuild

777
00:41:00,160 --> 00:41:01,480
high-criticality ones.

778
00:41:01,480 --> 00:41:05,160
They spend too much effort on a niche request that barely moves anything, then improvise

779
00:41:05,160 --> 00:41:09,920
around a recurring process that keeps draining time from the people inside the system.

780
00:41:09,920 --> 00:41:11,600
So the second force gives us another rule.

781
00:41:11,600 --> 00:41:15,760
The more often the process runs and the more business consequences it carries, the less

782
00:41:15,760 --> 00:41:17,840
room you have for casual architecture.

783
00:41:17,840 --> 00:41:21,880
And even then, a well-shaped process can still collapse if the wrong people can access

784
00:41:21,880 --> 00:41:26,000
it, approve it, or see too much inside it, which takes us to the third force.

785
00:41:26,000 --> 00:41:28,520
The three forces model, identity and governance.

786
00:41:28,520 --> 00:41:30,880
The third force is identity and governance.

787
00:41:30,880 --> 00:41:35,640
Most teams run into this force far too late because early workshops almost always focus on

788
00:41:35,640 --> 00:41:36,960
immediate usefulness.

789
00:41:36,960 --> 00:41:42,120
We ask if people can submit a form, if managers can click approve or if HR can pull a report.

790
00:41:42,120 --> 00:41:46,000
These are fair questions, but once the process starts touching real records and affecting

791
00:41:46,000 --> 00:41:50,240
real people, the conversation has to shift towards something harder and more important.

792
00:41:50,240 --> 00:41:51,800
Who is allowed to see this data?

793
00:41:51,800 --> 00:41:53,280
Who has the authority to take action?

794
00:41:53,280 --> 00:41:56,800
Who actually owns the system once the consultants leave and the project goes live?

795
00:41:56,800 --> 00:42:00,320
This isn't just administrative cleanup or a task for a Friday afternoon.

796
00:42:00,320 --> 00:42:01,960
This is architecture.

797
00:42:01,960 --> 00:42:06,960
At Contoso, this force starts simply enough with basic roles and responsibilities.

798
00:42:06,960 --> 00:42:10,960
Employees need to see their own requests, while managers should only act on items for their

799
00:42:10,960 --> 00:42:11,960
specific team.

800
00:42:11,960 --> 00:42:15,840
HR requires a broader view to support policy and payroll, and leadership might need to

801
00:42:15,840 --> 00:42:18,800
see high-level trends without digging into personal details.

802
00:42:18,800 --> 00:42:22,360
The very moment you write those roles down, you have entered the world of governance, whether

803
00:42:22,360 --> 00:42:25,560
your team uses that specific word or not.

804
00:42:25,560 --> 00:42:28,720
Access is not a setting you just sprinkle on top of a finished product.

805
00:42:28,720 --> 00:42:31,080
It shapes the entire design of the system.

806
00:42:31,080 --> 00:42:35,480
If an app cannot cleanly distinguish between how an employee and a manager should behave,

807
00:42:35,480 --> 00:42:37,560
the interface becomes a cluttered mess.

808
00:42:37,560 --> 00:42:41,680
When a flow cannot identify who is allowed to approve or escalate a request, the entire

809
00:42:41,680 --> 00:42:43,680
process becomes a business risk.

810
00:42:43,680 --> 00:42:48,560
If your reporting layer exposes too much sensitive data or hides too much necessary detail,

811
00:42:48,560 --> 00:42:51,800
your visibility is either dangerous or useless.

812
00:42:51,800 --> 00:42:53,400
Identity isn't sitting outside the build.

813
00:42:53,400 --> 00:42:55,840
It is the thread running through every single layer of it.

814
00:42:55,840 --> 00:42:58,400
Now we have to add one more dimension to the system.

815
00:42:58,400 --> 00:43:01,040
We have to look at internal versus external users.

816
00:43:01,040 --> 00:43:04,160
That single line changes everything about your security posture.

817
00:43:04,160 --> 00:43:08,200
An internal employee usually arrives with an established identity and a known device,

818
00:43:08,200 --> 00:43:11,280
which means they follow clear policies and have a defined support path.

819
00:43:11,280 --> 00:43:15,120
An external contractor or partner does not have those guardrails, and the moment a process

820
00:43:15,120 --> 00:43:18,960
crosses that boundary, your tolerance for improvisation has to drop to zero.

821
00:43:18,960 --> 00:43:22,800
What started as a simple workflow problem quickly turns into an exposure problem if the

822
00:43:22,800 --> 00:43:26,480
wrong person triggers the wrong action or sees a record they shouldn't.

823
00:43:26,480 --> 00:43:30,240
This is exactly why I treat governance as a design requirement rather than just boring

824
00:43:30,240 --> 00:43:31,240
paperwork.

825
00:43:31,240 --> 00:43:35,720
Good governance is not a document that explains what went wrong after the system is already

826
00:43:35,720 --> 00:43:36,720
live and messy.

827
00:43:36,720 --> 00:43:40,240
Instead, it is a set of structural constraints that make the right behavior easy and the

828
00:43:40,240 --> 00:43:42,760
wrong behavior almost impossible from day one.

829
00:43:42,760 --> 00:43:44,880
Who is allowed to build in which environment?

830
00:43:44,880 --> 00:43:47,280
Who has the right to share apps and automated flows?

831
00:43:47,280 --> 00:43:50,560
Who is on the hook for support when a flow fails on a Friday afternoon?

832
00:43:50,560 --> 00:43:53,360
Who has the final say when the data model needs to change?

833
00:43:53,360 --> 00:43:57,560
Who reviews a new connector before someone accidentally wires a sensitive process into

834
00:43:57,560 --> 00:43:59,080
a public-facing website?

835
00:43:59,080 --> 00:44:02,600
These questions sound like operational chores and they are, but structurally they determine

836
00:44:02,600 --> 00:44:04,080
if a solution can scale.

837
00:44:04,080 --> 00:44:05,880
Without these answers, you aren't building a system.

838
00:44:05,880 --> 00:44:10,360
You are building a set of fragile dependencies that rely on a few well-meaning people to keep

839
00:44:10,360 --> 00:44:11,440
things from breaking.

840
00:44:11,440 --> 00:44:13,920
That is the trap so many organizations fall into.

841
00:44:13,920 --> 00:44:16,040
One capable maker builds the first app.

842
00:44:16,040 --> 00:44:20,600
Then another person adds a flow to handle notifications and suddenly someone in HR becomes the

843
00:44:20,600 --> 00:44:24,840
accidental business owner because they are the only one who understands the exceptions.

844
00:44:24,840 --> 00:44:28,440
Because the tools feel accessible and the process looks small at the start, nobody defines

845
00:44:28,440 --> 00:44:30,400
the life cycle or the change control.

846
00:44:30,400 --> 00:44:34,680
Then adoption starts to rise, a data field changes, a manager moves to a different team,

847
00:44:34,680 --> 00:44:38,080
a connector breaks, or an external user gets added to the mix.

848
00:44:38,080 --> 00:44:42,800
Suddenly the entire build becomes a single point of failure wrapped in good intentions.

849
00:44:42,800 --> 00:44:47,120
From a system perspective that isn't a people problem or a lack of training, it is a governance

850
00:44:47,120 --> 00:44:49,320
problem that arrived too late to help.

851
00:44:49,320 --> 00:44:53,280
This is also why managed environments matter more than most teams want to admit.

852
00:44:53,280 --> 00:44:57,440
Most companies try to add control only after the sprawl appears and duplicate apps are

853
00:44:57,440 --> 00:44:58,440
everywhere.

854
00:44:58,440 --> 00:45:02,120
They wait until flows are failing in hidden corners and nobody remembers who published

855
00:45:02,120 --> 00:45:03,360
what in the first place.

856
00:45:03,360 --> 00:45:07,720
That sequence is backwards and while early control might feel slower for a week, late

857
00:45:07,720 --> 00:45:10,040
control will definitely be slower for a year.

858
00:45:10,040 --> 00:45:12,800
The third force gives us a very specific working rule.

859
00:45:12,800 --> 00:45:16,400
If you haven't defined the identity, the ownership and the control boundaries, you haven't

860
00:45:16,400 --> 00:45:18,240
actually finished designing the process.

861
00:45:18,240 --> 00:45:20,120
You have only drafted a pretty interface.

862
00:45:20,120 --> 00:45:25,560
Once all three forces are visible, data gravity, process criticality and identity with governance,

863
00:45:25,560 --> 00:45:27,480
we can finally go back to Contoso.

864
00:45:27,480 --> 00:45:31,720
We can choose the right first move in the right order rather than just building the loudest

865
00:45:31,720 --> 00:45:33,480
idea on the list.

866
00:45:33,480 --> 00:45:35,680
Choosing the right first move at Contoso.

867
00:45:35,680 --> 00:45:38,240
So let's apply the model to the reality of the business.

868
00:45:38,240 --> 00:45:41,840
This is the exact moment where most teams still go wrong even after they understand the

869
00:45:41,840 --> 00:45:43,440
tools and the forces involved.

870
00:45:43,440 --> 00:45:45,800
They still ask what they should build first.

871
00:45:45,800 --> 00:45:49,280
When the better question is to ask what the dominant constraint in the process is right

872
00:45:49,280 --> 00:45:50,280
now.

873
00:45:50,280 --> 00:45:51,280
That is your first move.

874
00:45:51,280 --> 00:45:54,160
It isn't the loudest complaint or the most visible pain point.

875
00:45:54,160 --> 00:45:55,680
It is the dominant constraint.

876
00:45:55,680 --> 00:45:59,040
At Contoso, the loudest complaint might be that the process feels messy but messy is a

877
00:45:59,040 --> 00:46:01,080
symptom rather than a build decision.

878
00:46:01,080 --> 00:46:04,640
We need to identify what is actually producing the drag on the system.

879
00:46:04,640 --> 00:46:08,840
If the main problem is a delay in approval starting with a polished app might feel productive

880
00:46:08,840 --> 00:46:10,880
but it won't actually change the outcome.

881
00:46:10,880 --> 00:46:14,840
In that scenario, the first move has to be process mapping and automation design.

882
00:46:14,840 --> 00:46:18,800
We need to define the routing, the ownership and the escalation parts before we worry about

883
00:46:18,800 --> 00:46:21,640
how elegant the request screen looks to the user.

884
00:46:21,640 --> 00:46:25,520
If the main problem is inconsistent data, then automation is probably the wrong move

885
00:46:25,520 --> 00:46:26,720
to make first.

886
00:46:26,720 --> 00:46:31,040
A flow running on weak categories and duplicate records is just a way to create confusion

887
00:46:31,040 --> 00:46:32,400
at a higher velocity.

888
00:46:32,400 --> 00:46:36,360
In this case, the first move is to define the structure by deciding what the leaf types

889
00:46:36,360 --> 00:46:38,920
are and who owns the record when a policy changes.

890
00:46:38,920 --> 00:46:42,640
Until those answers are stable, your interface and your automation are just standing on

891
00:46:42,640 --> 00:46:43,640
a moving floor.

892
00:46:43,640 --> 00:46:47,840
If management has zero visibility into what is happening, the order changes yet again.

893
00:46:47,840 --> 00:46:51,000
Sometimes the process is running badly but predictably and the first real intervention

894
00:46:51,000 --> 00:46:52,120
should be reporting.

895
00:46:52,120 --> 00:46:57,120
Dashboards don't solve the process on their own, but they reveal exactly where the bottleneck

896
00:46:57,120 --> 00:46:58,120
is sitting.

897
00:46:58,120 --> 00:47:02,080
A basic reporting layer can show if delays are clustering around specific managers or

898
00:47:02,080 --> 00:47:06,160
departments which stops the team from wasting time fixing the wrong thing.

899
00:47:06,160 --> 00:47:10,080
The sequence always depends on the dominant constraint and that is the entire point of

900
00:47:10,080 --> 00:47:11,080
this approach.

901
00:47:11,080 --> 00:47:12,880
Tool choice is really just a choice of order.

902
00:47:12,880 --> 00:47:16,760
If I map out the contoso project based on everything we've discussed, the sequence usually

903
00:47:16,760 --> 00:47:17,760
looks like this.

904
00:47:17,760 --> 00:47:19,000
First you define the data.

905
00:47:19,000 --> 00:47:21,800
Second you design and automate the approval path.

906
00:47:21,800 --> 00:47:25,200
Third you build the app experience around the key user interactions.

907
00:47:25,200 --> 00:47:29,000
Fourth you expose visibility through reporting and finally you add an assistant layer if

908
00:47:29,000 --> 00:47:32,400
conversational access actually improves the experience.

909
00:47:32,400 --> 00:47:35,480
That order isn't based on an ideology, it is structural.

910
00:47:35,480 --> 00:47:39,040
If the request record is unclear, every step that follows it will be weaker.

911
00:47:39,040 --> 00:47:42,520
If the approval path isn't defined, the app just becomes a prettier intake form for the

912
00:47:42,520 --> 00:47:44,000
same old delays.

913
00:47:44,000 --> 00:47:47,920
If visibility arrives too late, the process can drift for months before anyone notices

914
00:47:47,920 --> 00:47:48,920
the new problems.

915
00:47:48,920 --> 00:47:53,520
If you add an AI assistant before the process is stable, you are just giving people a smoother

916
00:47:53,520 --> 00:47:55,760
way to interact with an unstable system.

917
00:47:55,760 --> 00:47:58,960
When leaders ask me what they should build first, I usually translate that into a

918
00:47:58,960 --> 00:48:00,400
much more useful question.

919
00:48:00,400 --> 00:48:04,520
What part of this has to become stable first so the rest of the solution can trust it.

920
00:48:04,520 --> 00:48:08,400
That is a completely different conversation and it almost always produces better architecture

921
00:48:08,400 --> 00:48:09,400
immediately.

922
00:48:09,400 --> 00:48:12,880
For a company like Contoso, I wouldn't start with the excitement of a new UI.

923
00:48:12,880 --> 00:48:15,160
I would start with the logic of sequencing.

924
00:48:15,160 --> 00:48:19,160
You make the record clear, then you make the path executable, then you make the interaction

925
00:48:19,160 --> 00:48:21,760
easy and finally you make the behavior visible.

926
00:48:21,760 --> 00:48:26,680
If the solution earns its place after all that, then you can make the experience conversational.

927
00:48:26,680 --> 00:48:30,640
That is how the platform starts acting like a coordinated solution instead of just a pile

928
00:48:30,640 --> 00:48:32,760
of tools reacting to the latest complaint.

929
00:48:32,760 --> 00:48:36,360
This matters because the wrong first move creates a pattern we've all seen before.

930
00:48:36,360 --> 00:48:40,560
A quick app appears on top of weak data, a few side spreadsheets survive because nobody

931
00:48:40,560 --> 00:48:45,760
fully trusts the new system and a flow gets added later to patch the inevitable delays.

932
00:48:45,760 --> 00:48:49,440
Reporting arrives after the categories have already drifted and adoption falls because

933
00:48:49,440 --> 00:48:52,240
people feel the process is still unreliable.

934
00:48:52,240 --> 00:48:54,640
From the outside that looks like a power platform problem.

935
00:48:54,640 --> 00:48:55,640
It usually isn't.

936
00:48:55,640 --> 00:49:00,000
It is a sequence problem and once you see that clearly a lot of failed builds stop looking

937
00:49:00,000 --> 00:49:01,000
mysterious.

938
00:49:01,000 --> 00:49:03,520
They look exactly like what they are.

939
00:49:03,520 --> 00:49:07,320
Solutions that started at the most visible layer instead of the most constraining one.

940
00:49:07,320 --> 00:49:09,800
The SharePoint and Excel trap, a failure pattern.

941
00:49:09,800 --> 00:49:13,640
Now let's look at the failure pattern that shows up in so many organizations because it explains

942
00:49:13,640 --> 00:49:16,920
exactly why good intentions still produce weak outcomes.

943
00:49:16,920 --> 00:49:18,200
It usually starts the same way.

944
00:49:18,200 --> 00:49:21,160
The team has a process that feels obviously broken.

945
00:49:21,160 --> 00:49:25,000
Everyone is tired of endless email chains and someone usually has a spreadsheet they've

946
00:49:25,000 --> 00:49:26,120
been nursing for months.

947
00:49:26,120 --> 00:49:30,480
A manager wants better visibility and because the Microsoft stack is already sitting there,

948
00:49:30,480 --> 00:49:34,440
the natural reaction is to build something quickly with whatever tools are close at hand.

949
00:49:34,440 --> 00:49:38,440
So they create a SharePoint list, then they build a power app on top of it, then they add

950
00:49:38,440 --> 00:49:40,880
a flow or two to move the data around.

951
00:49:40,880 --> 00:49:44,800
And because that one original spreadsheet still contains old records or special cases

952
00:49:44,800 --> 00:49:48,320
that nobody wanted to model properly, the spreadsheet stays alive right alongside the

953
00:49:48,320 --> 00:49:49,840
new app.

954
00:49:49,840 --> 00:49:51,440
At first this feels like a smart move.

955
00:49:51,440 --> 00:49:54,560
It's a cheap start with fast progress and a visible result that people can actually

956
00:49:54,560 --> 00:49:55,560
see.

957
00:49:55,560 --> 00:49:59,840
Employees can submit requests through the app, managers get an instant notification and

958
00:49:59,840 --> 00:50:03,760
HR sees a list instead of a cluttered mailbox in that very first demo.

959
00:50:03,760 --> 00:50:05,840
It really looks like the problem is getting solved.

960
00:50:05,840 --> 00:50:08,320
But if you look closely, you'll see what actually happened.

961
00:50:08,320 --> 00:50:11,400
The organization didn't actually replace the old operating model.

962
00:50:11,400 --> 00:50:14,880
They just added a new digital surface on top of the same old behavior.

963
00:50:14,880 --> 00:50:18,520
The spreadsheet survives because trust in the new record never fully forms.

964
00:50:18,520 --> 00:50:23,000
And the SharePoint list becomes the main system in name only, while the real exceptions still

965
00:50:23,000 --> 00:50:25,520
get tracked in the shadows.

966
00:50:25,520 --> 00:50:30,080
The flow sends out notifications, but nobody ever defined what should happen when data

967
00:50:30,080 --> 00:50:34,520
enters the system incomplete, inconsistent or duplicated.

968
00:50:34,520 --> 00:50:38,440
Because the build started from a place of convenience rather than structure, the solution

969
00:50:38,440 --> 00:50:40,240
begins to split almost immediately.

970
00:50:40,240 --> 00:50:41,240
This is the trap.

971
00:50:41,240 --> 00:50:43,840
It isn't SharePoint by itself and it isn't Excel by itself.

972
00:50:43,840 --> 00:50:48,880
The trap is using accessible tools as structural compensation for decisions that nobody wanted

973
00:50:48,880 --> 00:50:49,880
to make up front.

974
00:50:49,880 --> 00:50:52,800
At that point a few things tend to happen in a very specific sequence.

975
00:50:52,800 --> 00:50:54,800
As duplicate entry starts to appear.

976
00:50:54,800 --> 00:50:58,640
Someone edits the list, someone else updates the spreadsheet, and a third person resubmits

977
00:50:58,640 --> 00:51:01,520
the form because they weren't sure it worked the first time.

978
00:51:01,520 --> 00:51:05,840
Now the team has three versions of the same request, and nobody feels fully confident about

979
00:51:05,840 --> 00:51:08,280
which one should actually drive the next action.

980
00:51:08,280 --> 00:51:11,600
Second, the references start breaking in softer, quieter ways.

981
00:51:11,600 --> 00:51:15,880
A manager changes roles, a department name gets typed three different ways, or a leave

982
00:51:15,880 --> 00:51:18,600
category gets renamed in one place but not the other.

983
00:51:18,600 --> 00:51:23,200
The flow still runs, but the meaning underneath it starts to drift, and the organization mistakes

984
00:51:23,200 --> 00:51:25,960
technical execution for actual operational integrity.

985
00:51:25,960 --> 00:51:28,640
Third, the reporting becomes unreliable.

986
00:51:28,640 --> 00:51:32,760
This doesn't happen because Power BI failed, but because the categories were never standardized

987
00:51:32,760 --> 00:51:34,240
and the ownership was never cleared.

988
00:51:34,240 --> 00:51:37,960
The data model was treated like a minor admin detail instead of the core business logic

989
00:51:37,960 --> 00:51:39,360
it actually is.

990
00:51:39,360 --> 00:51:43,760
Once that happens, every dashboard becomes a negotiation where HR has one number, manages

991
00:51:43,760 --> 00:51:47,880
have another, and leadership eventually stops trusting the signal entirely.

992
00:51:47,880 --> 00:51:52,520
And once that trust drops, adoption follows it down, that part matters more than people realize.

993
00:51:52,520 --> 00:51:55,680
Users don't abandon digital tools just because the interface is ugly.

994
00:51:55,680 --> 00:51:59,760
They abandon them when the process still feels unreliable after the software arrives.

995
00:51:59,760 --> 00:52:03,880
If employees feel they still need to email HR just to be safe, the app has already lost

996
00:52:03,880 --> 00:52:04,880
its authority.

997
00:52:04,880 --> 00:52:08,920
If managers are still keeping side notes because the status feels incomplete, the platform

998
00:52:08,920 --> 00:52:10,640
is no longer the operating model.

999
00:52:10,640 --> 00:52:12,760
It's just one more layer that people have to work around.

1000
00:52:12,760 --> 00:52:16,320
This is why I call it a foundation failure, not a power platform failure.

1001
00:52:16,320 --> 00:52:20,040
From a system perspective, the tools are doing exactly what they were asked to do.

1002
00:52:20,040 --> 00:52:24,520
The app is collecting input, the list is storing records, and the flow is moving messages.

1003
00:52:24,520 --> 00:52:27,800
While the spreadsheet covers the gaps, the solution never closed.

1004
00:52:27,800 --> 00:52:29,400
Nothing here is happening by accident.

1005
00:52:29,400 --> 00:52:33,800
It is the predictable result of weak sequencing, and this pattern is dangerous because it creates

1006
00:52:33,800 --> 00:52:35,480
a false illusion of maturity.

1007
00:52:35,480 --> 00:52:38,400
There is an app so leadership things digitization happened.

1008
00:52:38,400 --> 00:52:41,000
There is a flow, so people say the process is automated.

1009
00:52:41,000 --> 00:52:43,360
There is a dashboard, so reporting appears covered.

1010
00:52:43,360 --> 00:52:46,280
But underneath all that, the business is still burning human

1011
00:52:46,280 --> 00:52:51,040
effort to reconcile data and manually restore trust where the architecture never created it.

1012
00:52:51,040 --> 00:52:52,520
That is an expensive way to work.

1013
00:52:52,520 --> 00:52:54,040
It costs you more than just hours.

1014
00:52:54,040 --> 00:52:58,240
It costs you confidence, support load, and the slow erosion of belief that the platform

1015
00:52:58,240 --> 00:53:00,680
can carry serious business processes.

1016
00:53:00,680 --> 00:53:04,880
So when people tell me that they tried power platform and it became messy, I usually want

1017
00:53:04,880 --> 00:53:06,560
to ask one specific question.

1018
00:53:06,560 --> 00:53:10,280
Did you actually design a connected operating model or did you just stack tools on top of

1019
00:53:10,280 --> 00:53:12,520
unmanaged data and call that a solution?

1020
00:53:12,520 --> 00:53:13,760
Because those are not the same thing.

1021
00:53:13,760 --> 00:53:16,240
The reason this failure pattern matters is simple.

1022
00:53:16,240 --> 00:53:20,680
The opposite approach looks slower in the first meeting, but it performs better almost everywhere

1023
00:53:20,680 --> 00:53:23,600
once the solution starts carrying a real business load.

1024
00:53:23,600 --> 00:53:26,080
The government platform approach, why it scales?

1025
00:53:26,080 --> 00:53:30,040
The opposite pattern starts slower, and that is exactly why many teams resist it.

1026
00:53:30,040 --> 00:53:33,960
Because the governed approach does not begin with a screen, it begins with hard decisions.

1027
00:53:33,960 --> 00:53:35,560
You have to ask what is the record?

1028
00:53:35,560 --> 00:53:36,560
Who owns it?

1029
00:53:36,560 --> 00:53:38,000
Which environment does this belong in?

1030
00:53:38,000 --> 00:53:40,520
How will changes move from development to production?

1031
00:53:40,520 --> 00:53:44,160
What naming rules will keep this understandable six months from now when the original

1032
00:53:44,160 --> 00:53:45,680
builder is busy or gone?

1033
00:53:45,680 --> 00:53:47,800
None of that feels exciting in a kickoff meeting.

1034
00:53:47,800 --> 00:53:50,840
It feels like drag, but if you look closely, that drag isn't waste.

1035
00:53:50,840 --> 00:53:53,000
It is structural compensation happening early.

1036
00:53:53,000 --> 00:53:56,600
Before the organization starts paying for that same uncertainty every single week through

1037
00:53:56,600 --> 00:53:58,600
support tickets and manual rework.

1038
00:53:58,600 --> 00:54:03,000
In the governed platform approach, we don't start by asking how fast we can launch an app.

1039
00:54:03,000 --> 00:54:05,480
Instead, we begin by defining the actual shape of the solution.

1040
00:54:05,480 --> 00:54:09,520
At Contoso, that means a leave request is treated as an operational record with clear

1041
00:54:09,520 --> 00:54:21,480
states and clear rules around who can create a proof or update it.

1042
00:54:21,480 --> 00:54:23,440
Then and only then the build starts.

1043
00:54:23,440 --> 00:54:27,640
Now the app has something stable to sit on and the flow has something reliable to execute

1044
00:54:27,640 --> 00:54:28,640
against.

1045
00:54:28,640 --> 00:54:32,200
The reporting layer uses categories that mean the same thing every time.

1046
00:54:32,200 --> 00:54:36,040
The business starts to feel a different kind of trust because people are no longer guessing

1047
00:54:36,040 --> 00:54:37,840
whether the platform reflects reality.

1048
00:54:37,840 --> 00:54:38,920
They can see that it does.

1049
00:54:38,920 --> 00:54:42,040
That trust matters more than teams often admit.

1050
00:54:42,040 --> 00:54:43,800
Adoption isn't driven by convenience alone.

1051
00:54:43,800 --> 00:54:45,640
It is driven by confidence.

1052
00:54:45,640 --> 00:54:49,360
If employees believe the request they submit will actually follow the right path, they

1053
00:54:49,360 --> 00:54:51,160
stop sending those backup emails.

1054
00:54:51,160 --> 00:54:54,760
If managers believe the status they see is current, they stop maintaining their own shadow

1055
00:54:54,760 --> 00:54:55,760
notes.

1056
00:54:55,760 --> 00:54:59,120
If HR believes the records are complete, they stop acting as the human integration layer

1057
00:54:59,120 --> 00:55:00,880
between the app and the inbox.

1058
00:55:00,880 --> 00:55:02,720
That is where true scale begins.

1059
00:55:02,720 --> 00:55:04,520
It doesn't happen when more users arrive.

1060
00:55:04,520 --> 00:55:08,360
It happens when fewer manual compensations are needed per transaction.

1061
00:55:08,360 --> 00:55:12,600
Once that happens, your three key metrics start moving in a much cleaner way.

1062
00:55:12,600 --> 00:55:16,440
Cycle time drops because the approval path is defined and executable, rather than being

1063
00:55:16,440 --> 00:55:19,000
improvised differently by every department.

1064
00:55:19,000 --> 00:55:23,440
Arrow rates drop because the structure enforces cleaner input earlier before bad records

1065
00:55:23,440 --> 00:55:25,520
can spread into reporting or payroll.

1066
00:55:25,520 --> 00:55:29,440
Most importantly, the cost to serve drops because managers stop spending their time correcting

1067
00:55:29,440 --> 00:55:32,240
preventable issues and chasing status manually.

1068
00:55:32,240 --> 00:55:34,200
That last one is usually the hidden win.

1069
00:55:34,200 --> 00:55:38,080
A lot of leaders focus on build speed because it's easy to see in the first month, but the

1070
00:55:38,080 --> 00:55:41,240
more expensive question is what the process costs to operate after launch.

1071
00:55:41,240 --> 00:55:45,840
A cheap start can create an expensive operating model if every exception still needs human

1072
00:55:45,840 --> 00:55:46,840
repair.

1073
00:55:46,840 --> 00:55:50,840
A governed start often costs more attention upfront, but it lowers coordination cost over time

1074
00:55:50,840 --> 00:55:54,480
and coordination cost is where a lot of business drag quietly lives.

1075
00:55:54,480 --> 00:55:58,560
This is also why connected build scale better across different departments.

1076
00:55:58,560 --> 00:56:02,560
Once contoso has a clear model for requests and roles, that pattern becomes reusable for

1077
00:56:02,560 --> 00:56:03,560
the next project.

1078
00:56:03,560 --> 00:56:08,440
Another team can extend the same structure without inventing everything from scratch.

1079
00:56:08,440 --> 00:56:12,520
Governance stops feeling like a restriction and starts functioning as a reusable design

1080
00:56:12,520 --> 00:56:13,520
discipline.

1081
00:56:13,520 --> 00:56:14,520
That is the fundamental difference.

1082
00:56:14,520 --> 00:56:17,840
In the failure pattern, every solution becomes a local workaround.

1083
00:56:17,840 --> 00:56:21,440
In the governed pattern, each solution becomes part of an operating model the business

1084
00:56:21,440 --> 00:56:22,680
can actually build on.

1085
00:56:22,680 --> 00:56:26,760
That is where the platform starts earning its name because the individual tools stop

1086
00:56:26,760 --> 00:56:31,160
behaving like isolated fixes and start behaving like coordinated layers of one business

1087
00:56:31,160 --> 00:56:32,160
capability.

1088
00:56:32,160 --> 00:56:35,600
That approach looks slower to impatient teams and it usually is at first.

1089
00:56:35,600 --> 00:56:39,640
But once the workload grows and the policy changes arrive, the governed approach stops

1090
00:56:39,640 --> 00:56:44,520
looking slow and starts looking stable and in this business, stable is what scales.

1091
00:56:44,520 --> 00:56:48,840
Where data verse enters without turning this into the next episode, this is the point where

1092
00:56:48,840 --> 00:56:50,800
data verse starts to matter.

1093
00:56:50,800 --> 00:56:55,840
Even if we aren't going to turn this entire episode into a deep dive on data platforms.

1094
00:56:55,840 --> 00:57:00,040
When we move from quick fixes to connected solutions, the fundamental question changes

1095
00:57:00,040 --> 00:57:03,880
because we aren't just asking what an app should do or what a flow should automate, we are

1096
00:57:03,880 --> 00:57:08,000
asking what should hold the operational truth of the process so the whole solution behaves

1097
00:57:08,000 --> 00:57:12,680
consistently over time and that is exactly where data verse enters the conversation.

1098
00:57:12,680 --> 00:57:17,520
The simplest way to frame it is that data verse acts as the managed operational data layer

1099
00:57:17,520 --> 00:57:18,880
inside the power platform.

1100
00:57:18,880 --> 00:57:23,040
It provides structured tables, relationships, security controls and business logic in a common

1101
00:57:23,040 --> 00:57:27,520
place where your apps, automations and reporting layers can all work from the same underlying

1102
00:57:27,520 --> 00:57:28,520
shape.

1103
00:57:28,520 --> 00:57:33,880
This matters because once a solution spans multiple tools, a weak data choice stops being a local

1104
00:57:33,880 --> 00:57:36,840
mistake and becomes a shared constraint for the entire system.

1105
00:57:36,840 --> 00:57:40,680
If your app reads one structure while your flow updates another and your reporting depends

1106
00:57:40,680 --> 00:57:44,320
on a third version exported somewhere else, you don't actually have a connected platform

1107
00:57:44,320 --> 00:57:45,320
solution.

1108
00:57:45,320 --> 00:57:49,760
What you have is coordinated fragmentation that might function for a while, but it will

1109
00:57:49,760 --> 00:57:53,760
never hold up cleanly under growth, change or the pressure of real governance.

1110
00:57:53,760 --> 00:57:57,960
Now I want to keep this grounded in reality because data verse is not a mandatory requirement

1111
00:57:57,960 --> 00:58:00,600
for every single power platform build you start.

1112
00:58:00,600 --> 00:58:04,380
Sometimes a share point list is enough for the task at hand or perhaps sequel needs to

1113
00:58:04,380 --> 00:58:06,920
stay the system of record for a specific reason.

1114
00:58:06,920 --> 00:58:10,720
There are also times when an existing line of business system should remain authoritative,

1115
00:58:10,720 --> 00:58:14,080
which means the platform should orchestrate around that system rather than trying to replace

1116
00:58:14,080 --> 00:58:15,240
it entirely.

1117
00:58:15,240 --> 00:58:18,680
This isn't a sermon claiming every solution must end in data verse, but it is a design

1118
00:58:18,680 --> 00:58:22,720
question about when a process starts asking for a stronger operational core.

1119
00:58:22,720 --> 00:58:25,200
There are specific signals that point you in that direction.

1120
00:58:25,200 --> 00:58:29,440
If the process needs consistent relationships between records or if multiple tools need

1121
00:58:29,440 --> 00:58:33,960
to work from the same structure without constant translation, data verse starts to look

1122
00:58:33,960 --> 00:58:35,520
much more attractive.

1123
00:58:35,520 --> 00:58:40,400
When security, role behavior, reusable logic and long term life cycle control become priorities,

1124
00:58:40,400 --> 00:58:42,960
the platform's native data layer becomes very hard to ignore.

1125
00:58:42,960 --> 00:58:47,240
In other words, when a process begins to behave less like a simple list and more like a true

1126
00:58:47,240 --> 00:58:51,960
application capability, the structural benefits of data verse outweigh the setup.

1127
00:58:51,960 --> 00:58:55,880
People often confuse this with sequel, so let me keep the distinction clean and simple for

1128
00:58:55,880 --> 00:58:56,880
you.

1129
00:58:56,880 --> 00:59:00,680
SQL gives you deep database control for high volume or specialized workloads, while SharePoint

1130
00:59:00,680 --> 00:59:05,080
offers accessible, collaboration oriented storage for much lighter scenarios.

1131
00:59:05,080 --> 00:59:08,440
Data verse sits in a different position because it isn't trying to be a general answer to

1132
00:59:08,440 --> 00:59:13,560
every enterprise data problem, but rather a managed operational backbone for business solutions.

1133
00:59:13,560 --> 00:59:17,440
That difference is vital because the value isn't just about where the data sits.

1134
00:59:17,440 --> 00:59:21,440
The real value is in what the platform can assume once the data is there, meaning

1135
00:59:21,440 --> 00:59:26,920
relationships are clearer, security is native and logic can be reused across the board.

1136
00:59:26,920 --> 00:59:31,040
When apps, flows and reporting operate with less structural friction, the solution becomes

1137
00:59:31,040 --> 00:59:35,000
easier to scale without needing humans to compensate for system gaps.

1138
00:59:35,000 --> 00:59:39,480
Back at Contoso, data verse becomes relevant, the moment the leaf process stops being a quick

1139
00:59:39,480 --> 00:59:42,400
form and starts becoming a governed business capability.

1140
00:59:42,400 --> 00:59:46,440
If requests, balances, approvals and reporting all need to stay coherent across different

1141
00:59:46,440 --> 00:59:49,200
tools, then the data layer is no longer a background decision.

1142
00:59:49,200 --> 00:59:53,040
It is the thing shaping every later decision you make, which is why I didn't start this

1143
00:59:53,040 --> 00:59:55,600
episode with a product lecture on data verse.

1144
00:59:55,600 --> 00:59:59,280
If we arrive here through process design and governance, the role of the data layer becomes

1145
00:59:59,280 --> 01:00:00,760
obvious to everyone involved.

1146
01:00:00,760 --> 01:00:04,600
The data choice shapes the app choice, the automation choice, the reporting quality and

1147
01:00:04,600 --> 01:00:06,680
the access model for every user.

1148
01:00:06,680 --> 01:00:10,360
Most importantly, it absolutely shapes how expensive the system becomes to operate later

1149
01:00:10,360 --> 01:00:11,360
on.

1150
01:00:11,360 --> 01:00:14,440
We are going to go deeper on data verse in the next episode because it deserves that focus,

1151
01:00:14,440 --> 01:00:16,240
but for now, the point is much simpler.

1152
01:00:16,240 --> 01:00:20,600
If you choose the wrong data foundation, every tool decision you make above it gets weaker.

1153
01:00:20,600 --> 01:00:24,400
And because architecture is never separate from money, we need to talk about cost.

1154
01:00:24,400 --> 01:00:26,200
Tool choice is also a cost model.

1155
01:00:26,200 --> 01:00:30,040
Now we need to talk about cost in the way most architecture discussions try to avoid.

1156
01:00:30,040 --> 01:00:33,400
We aren't starting with license tables or product pricing pages, but with the actual

1157
01:00:33,400 --> 01:00:37,520
operating cost of the system, a lot of bad platform decisions look cheap the moment

1158
01:00:37,520 --> 01:00:40,920
they are approved, but they turn into expensive operating models.

1159
01:00:40,920 --> 01:00:44,040
Once the process starts carrying real load and exceptions.

1160
01:00:44,040 --> 01:00:48,480
That contoso the most obvious cost is labor because HR spends time fixing records and

1161
01:00:48,480 --> 01:00:50,800
manages spend their day chasing context.

1162
01:00:50,800 --> 01:00:54,760
Employees lose time asking for status updates, but that is only the visible layer of the

1163
01:00:54,760 --> 01:00:55,760
problem.

1164
01:00:55,760 --> 01:00:59,240
The deeper cost sits in rework, exception handling and the friction of trying to change

1165
01:00:59,240 --> 01:01:02,160
a week design after the entire company already depends on it.

1166
01:01:02,160 --> 01:01:06,360
That is your cost to serve and if you ignore it, you might save money on day one only to lose

1167
01:01:06,360 --> 01:01:08,280
much more over the next 12 months.

1168
01:01:08,280 --> 01:01:11,200
Think about the common pattern where a team starts with a share point list and a few

1169
01:01:11,200 --> 01:01:12,200
quick flows.

1170
01:01:12,200 --> 01:01:16,080
The build appears inexpensive because the entry point feels familiar and the first release

1171
01:01:16,080 --> 01:01:20,640
arrives quickly, but the business starts paying a hidden tax every time categories drift

1172
01:01:20,640 --> 01:01:22,760
or records need manual correction.

1173
01:01:22,760 --> 01:01:27,040
This tax matters more than the kickoff budget because software isn't just something you buy,

1174
01:01:27,040 --> 01:01:30,240
it is something you have to maintain through human coordination.

1175
01:01:30,240 --> 01:01:34,000
When I look at a tool choice, I am asking a financial question just as much as a technical

1176
01:01:34,000 --> 01:01:35,000
one.

1177
01:01:35,000 --> 01:01:39,360
I want to know if a decision reduces long term coordination costs or if it just postpones

1178
01:01:39,360 --> 01:01:41,280
those costs for a later date.

1179
01:01:41,280 --> 01:01:45,880
This is where architecture and licensing finally meet in a useful way because while premium

1180
01:01:45,880 --> 01:01:50,280
connectors and data vers capacity have real price tags, they aren't the whole story.

1181
01:01:50,280 --> 01:01:55,040
A cheaper storage choice can easily create a more expensive support model and a faster

1182
01:01:55,040 --> 01:01:59,520
launch can actually create a slower organization if people are still repairing every exception

1183
01:01:59,520 --> 01:02:00,520
by hand.

1184
01:02:00,520 --> 01:02:04,080
When leaders ask for the cheapest way to do something, I usually translate that into a

1185
01:02:04,080 --> 01:02:05,240
better question.

1186
01:02:05,240 --> 01:02:09,040
What is the least expensive model to operate once adoption becomes real?

1187
01:02:09,040 --> 01:02:12,720
That question changes the conversation fast because it allows us to compare choices more

1188
01:02:12,720 --> 01:02:13,720
honestly.

1189
01:02:13,720 --> 01:02:17,480
A lighter solution on SharePoint might be perfectly reasonable for a low-criticality workflow

1190
01:02:17,480 --> 01:02:21,680
but a governed dataverse approach might be the better economic choice if it reduces rework

1191
01:02:21,680 --> 01:02:23,600
across several connected tools.

1192
01:02:23,600 --> 01:02:27,320
The same logic applies to hybrid patterns and sometimes operational records belong in

1193
01:02:27,320 --> 01:02:31,440
dataverse because the platform needs secure relationships and consistent logic close to

1194
01:02:31,440 --> 01:02:32,440
the process.

1195
01:02:32,440 --> 01:02:36,360
At the same time, bulk history or heavy analytics might belong somewhere else because

1196
01:02:36,360 --> 01:02:40,560
forcing everything into one store can inflate costs without actually improving your control

1197
01:02:40,560 --> 01:02:42,680
that isn't architectural in decision.

1198
01:02:42,680 --> 01:02:47,200
It is cost-aware design that uses expensive control only where it creates clear business

1199
01:02:47,200 --> 01:02:48,200
value.

1200
01:02:48,200 --> 01:02:51,240
This becomes even more important once AI enters the picture because assistant layers and

1201
01:02:51,240 --> 01:02:53,200
agents don't remove weak economics.

1202
01:02:53,200 --> 01:02:57,800
They actually expose them faster if the underlying process is fragmented and AI layer just increases

1203
01:02:57,800 --> 01:03:02,400
the number of interactions touching that fragmentation which grows your risk surface.

1204
01:03:02,400 --> 01:03:06,960
A platform decision is ultimately a spending decision on future coordination and the companies

1205
01:03:06,960 --> 01:03:09,800
that handle this well don't just chase the cheapest start.

1206
01:03:09,800 --> 01:03:13,400
They choose the operating model that lowers friction and keeps the business from paying

1207
01:03:13,400 --> 01:03:16,080
the same uncertainty bill every single week.

1208
01:03:16,080 --> 01:03:19,600
2026, shift one, agents as an acceleration layer.

1209
01:03:19,600 --> 01:03:24,080
We aren't looking at a total platform replacement here but rather a massive increase in speed

1210
01:03:24,080 --> 01:03:27,880
for what the platform already does when the underlying design is coherent.

1211
01:03:27,880 --> 01:03:31,960
I want you to think about agents as an acceleration layer because that is the most accurate

1212
01:03:31,960 --> 01:03:33,960
way to view them in a professional system.

1213
01:03:33,960 --> 01:03:37,680
They aren't replacing your apps, they aren't replacing your power automate flows and

1214
01:03:37,680 --> 01:03:40,600
they certainly aren't replacing your data structure.

1215
01:03:40,600 --> 01:03:44,360
Instead an agent sits across those existing pieces to give your people a faster and more

1216
01:03:44,360 --> 01:03:47,520
flexible way to reach the capabilities you've already built.

1217
01:03:47,520 --> 01:03:50,960
And why is that distinction so important for leaders to understand right now?

1218
01:03:50,960 --> 01:03:54,640
The problem is that most market language around AI still pushes people toward the wrong

1219
01:03:54,640 --> 01:03:58,960
expectations by suggesting that an intelligent layer removes the need for architecture.

1220
01:03:58,960 --> 01:04:02,960
There is this myth that an agent will somehow reason its way through fragmented records,

1221
01:04:02,960 --> 01:04:05,440
weak permissions and half defined process logic.

1222
01:04:05,440 --> 01:04:08,560
But if you look closely that isn't how systems actually behave.

1223
01:04:08,560 --> 01:04:12,440
And an agent only becomes useful when the surrounding business capability is shaped

1224
01:04:12,440 --> 01:04:15,800
clearly enough for it to act inside known boundaries.

1225
01:04:15,800 --> 01:04:20,480
At a company like Contoso this means an agent helps in very practical, structural ways.

1226
01:04:20,480 --> 01:04:25,120
It can triage common questions or answer policy inquiries from a govern source and it can

1227
01:04:25,120 --> 01:04:28,680
even retrieve request statuses or root a user to the right action.

1228
01:04:28,680 --> 01:04:32,960
When user intent is clear and permissions allow it, the agent can trigger a downstream flow

1229
01:04:32,960 --> 01:04:36,120
and summarize exactly what is waiting for a manager's approval.

1230
01:04:36,120 --> 01:04:39,560
That is where the real value lives for a busy professional.

1231
01:04:39,560 --> 01:04:43,680
Repetitive interactions are the primary target here because nobody wants to hunt through menus,

1232
01:04:43,680 --> 01:04:47,880
search three different databases or ask HR a question that the business already knows

1233
01:04:47,880 --> 01:04:49,160
how to answer.

1234
01:04:49,160 --> 01:04:52,760
Now map that reality to how we work today and you'll see that most process friction

1235
01:04:52,760 --> 01:04:54,800
isn't actually caused by deep complexity.

1236
01:04:54,800 --> 01:04:59,120
It is driven by access friction where people simply don't know where to go, what rules apply

1237
01:04:59,120 --> 01:05:02,200
to them or what step comes next in the sequence.

1238
01:05:02,200 --> 01:05:05,480
Agents are perfectly suited for this work because they reduce the cost of navigation by

1239
01:05:05,480 --> 01:05:09,840
collapsing multiple clicks and handoffs into a single, simple interaction path.

1240
01:05:09,840 --> 01:05:14,200
But here is the thing that gain only holds up when your foundations are already coherent.

1241
01:05:14,200 --> 01:05:18,280
If your status field is updated late, the agent's answer will be late and if your policy

1242
01:05:18,280 --> 01:05:22,520
source is inconsistent, the agent will provide inconsistent information to your team.

1243
01:05:22,520 --> 01:05:25,000
The pattern you need to understand is actually very simple.

1244
01:05:25,000 --> 01:05:29,360
Agents amplify clarity but they also amplify ambiguity, which is why I don't treat them

1245
01:05:29,360 --> 01:05:30,680
as a separate strategy.

1246
01:05:30,680 --> 01:05:34,440
I treat them as a multiplier applied to your existing design quality.

1247
01:05:34,440 --> 01:05:37,840
And this is exactly where many leadership teams need a hard reset.

1248
01:05:37,840 --> 01:05:41,920
The excitement around agents often creates a kind of architectural impatience where leaders

1249
01:05:41,920 --> 01:05:46,600
see a demo of natural language and autonomous behavior and assume they can skip the hard work.

1250
01:05:46,600 --> 01:05:50,440
They think a smarter interface removes the need for a stable operating model, but the

1251
01:05:50,440 --> 01:05:51,440
opposite is true.

1252
01:05:51,440 --> 01:05:55,060
A smart interface actually increases the need for stability because more work can now

1253
01:05:55,060 --> 01:05:59,320
happen faster and with far less human verification in the loop.

1254
01:05:59,320 --> 01:06:02,520
That shift in speed completely changes your risk profile.

1255
01:06:02,520 --> 01:06:06,560
While a broken digital form might annoy one user at a time, an agent can touch hundreds

1256
01:06:06,560 --> 01:06:08,640
of interactions quickly and confidently.

1257
01:06:08,640 --> 01:06:13,000
This means that weak grounding or poor logic spreads much faster when the architecture underneath

1258
01:06:13,000 --> 01:06:16,040
is soft, turning a small mistake into a systemic failure.

1259
01:06:16,040 --> 01:06:20,040
When we look at where the platform is headed, the mature view is that agents will eventually

1260
01:06:20,040 --> 01:06:23,080
become a normal part of the user experience layer.

1261
01:06:23,080 --> 01:06:27,040
They will sit across internal support approvals, triage and task routing just like dashboards

1262
01:06:27,040 --> 01:06:28,320
and automations do today.

1263
01:06:28,320 --> 01:06:31,080
But none of that removes the design discipline required underneath.

1264
01:06:31,080 --> 01:06:34,160
It actually makes that discipline the most important factor in your success.

1265
01:06:34,160 --> 01:06:38,880
The platform is becoming more agentic and the interaction model is becoming more conversational,

1266
01:06:38,880 --> 01:06:42,440
which means the boundary between asking and acting is getting thinner every day.

1267
01:06:42,440 --> 01:06:46,080
But the business outcome will still be decided by whether your processes and permissions

1268
01:06:46,080 --> 01:06:48,920
work coherent before the agent arrived.

1269
01:06:48,920 --> 01:06:52,880
Working without control is just a faster way to create new failure modes at scale and that

1270
01:06:52,880 --> 01:06:56,160
brings us to the second major shift we need to address.

1271
01:06:56,160 --> 01:06:59,880
2026 shift 2 identity and managed control.

1272
01:06:59,880 --> 01:07:04,600
This second shift is entirely about control and it's a place where many organizations are

1273
01:07:04,600 --> 01:07:09,320
still operating with a 2022 mindset inside a 2026 platform.

1274
01:07:09,320 --> 01:07:13,720
They are still thinking about apps and flows as things that people build, rather than thinking

1275
01:07:13,720 --> 01:07:19,160
about agents as independent actors with their own access paths and operational scopes.

1276
01:07:19,160 --> 01:07:23,840
This is why identity is starting to matter in a fundamentally different way for the enterprise.

1277
01:07:23,840 --> 01:07:27,640
We aren't just talking about user identity anymore but rather agent identity and how these

1278
01:07:27,640 --> 01:07:29,520
entities move through your system.

1279
01:07:29,520 --> 01:07:33,360
At a high level this is where Entra agent ID becomes relevant to the conversation and

1280
01:07:33,360 --> 01:07:36,760
the structural implication is actually very easy to understand.

1281
01:07:36,760 --> 01:07:41,200
If agents are going to retrieve information and work across systems with any level of autonomy,

1282
01:07:41,200 --> 01:07:44,720
they cannot be treated like abstract features floating above your tenant.

1283
01:07:44,720 --> 01:07:49,120
They need governable boundaries, clear ownership and specific policies that dictate what they

1284
01:07:49,120 --> 01:07:50,360
can and cannot do.

1285
01:07:50,360 --> 01:07:54,320
Once an agent has a formal identity we can stop talking about it like magic and start talking

1286
01:07:54,320 --> 01:07:57,480
about it like something the business is actually accountable for.

1287
01:07:57,480 --> 01:07:59,800
You have to ask the adult platform questions.

1288
01:07:59,800 --> 01:08:01,240
Who sponsored this agent?

1289
01:08:01,240 --> 01:08:02,320
What can it trigger?

1290
01:08:02,320 --> 01:08:04,200
And who is responsible for disabling it?

1291
01:08:04,200 --> 01:08:05,480
If something goes wrong.

1292
01:08:05,480 --> 01:08:09,560
If your organization cannot answer those questions then you aren't experimenting with intelligence.

1293
01:08:09,560 --> 01:08:12,600
You are simply distributing risk without a control model.

1294
01:08:12,600 --> 01:08:16,240
Now map that back to the power platform more broadly and you'll see why managed environments

1295
01:08:16,240 --> 01:08:17,240
matter so much.

1296
01:08:17,240 --> 01:08:20,920
A lot of teams treat governance as something they will sort out later once they see adoption

1297
01:08:20,920 --> 01:08:22,400
and prove the value of the tools.

1298
01:08:22,400 --> 01:08:27,520
They let the ideas spread and the apps multiply but that sequence always produces the same messy

1299
01:08:27,520 --> 01:08:30,520
result of duplicate tools and unclear ownership.

1300
01:08:30,520 --> 01:08:32,160
That isn't freedom for your makers.

1301
01:08:32,160 --> 01:08:35,880
It is just deferred structure that eventually turns into operating drag.

1302
01:08:35,880 --> 01:08:40,640
I care about managed control early in the process because good control actually reduces long term

1303
01:08:40,640 --> 01:08:42,240
friction for everyone involved.

1304
01:08:42,240 --> 01:08:45,800
When people know where to build and who approves what it lowers confusion for the makers

1305
01:08:45,800 --> 01:08:49,800
and lowers the recovery cost for the business when something eventually breaks.

1306
01:08:49,800 --> 01:08:54,400
If we apply this logic to Contoso the real question isn't whether an employee can ask

1307
01:08:54,400 --> 01:08:56,200
an agent about a leave policy.

1308
01:08:56,200 --> 01:08:59,920
The question is whether the environment can support that interaction safely with the agent

1309
01:08:59,920 --> 01:09:03,360
grounded on governed sources and permissions scoped correctly to the user.

1310
01:09:03,360 --> 01:09:07,000
If the process isn't in a managed environment with a clear life cycle the business isn't

1311
01:09:07,000 --> 01:09:08,160
scaling innovation.

1312
01:09:08,160 --> 01:09:10,040
It is just scaling ambiguity.

1313
01:09:10,040 --> 01:09:13,960
The broader lesson here is that autonomy without governance is just another single point

1314
01:09:13,960 --> 01:09:14,960
of failure.

1315
01:09:14,960 --> 01:09:18,680
It might look modern and sound intelligent in a demo but if one overpermissioned connection

1316
01:09:18,680 --> 01:09:22,160
can expose the wrong data the platform is still structurally fragile.

1317
01:09:22,160 --> 01:09:25,600
In 2026 I don't see governance and innovation as opposites.

1318
01:09:25,600 --> 01:09:30,080
I see managed control as the essential condition that lets innovation survive its first contact

1319
01:09:30,080 --> 01:09:31,480
with business reality.

1320
01:09:31,480 --> 01:09:34,240
The agents are going to spread more makers are going to build and workflows will become

1321
01:09:34,240 --> 01:09:36,680
increasingly automated and cross system.

1322
01:09:36,680 --> 01:09:40,360
The only real question left is whether you will build the control plane early enough that

1323
01:09:40,360 --> 01:09:42,400
this new layer becomes a true asset.

1324
01:09:42,400 --> 01:09:46,840
If you audit your managed control the same way you audit your infrastructure.

1325
01:09:46,840 --> 01:09:47,840
What would you find?

1326
01:09:47,840 --> 01:09:51,720
Is your system designed to support this new level of acceleration or is it just waiting

1327
01:09:51,720 --> 01:09:53,800
for the first high speed failure to happen?

1328
01:09:53,800 --> 01:09:56,560
A practical selection sequence leaders can reuse.

1329
01:09:56,560 --> 01:10:00,520
When we step back from the technical noise the confusion starts to clear because the platform

1330
01:10:00,520 --> 01:10:04,480
stops looking like five overlapping products and starts looking like a selection problem

1331
01:10:04,480 --> 01:10:06,280
with a repeatable order.

1332
01:10:06,280 --> 01:10:10,720
That order matters because most bad power platform decisions do not begin with bad intent.

1333
01:10:10,720 --> 01:10:14,320
They begin with premature solution shaping where someone reaches for the tool they know

1334
01:10:14,320 --> 01:10:16,280
or the license they already have.

1335
01:10:16,280 --> 01:10:20,320
The architecture then forms around familiarity instead of business need which is exactly how

1336
01:10:20,320 --> 01:10:22,160
technical debt begins to accumulate.

1337
01:10:22,160 --> 01:10:23,640
So let me make this practical.

1338
01:10:23,640 --> 01:10:28,360
If you are leading a team sponsoring a build or reviewing a request that sounds like we

1339
01:10:28,360 --> 01:10:29,480
need a power app.

1340
01:10:29,480 --> 01:10:32,200
This is the sequence I would use before approving anything.

1341
01:10:32,200 --> 01:10:34,880
Step one, define the operating problem in business terms.

1342
01:10:34,880 --> 01:10:38,480
You have to avoid tool terms and interface terms entirely and focus on what is actually

1343
01:10:38,480 --> 01:10:39,640
happening in the business.

1344
01:10:39,640 --> 01:10:42,000
What is happening today that should not be happening?

1345
01:10:42,000 --> 01:10:43,600
Where is time being lost?

1346
01:10:43,600 --> 01:10:44,800
And where is trust load?

1347
01:10:44,800 --> 01:10:48,480
You need to identify where people are compensating manually for something the process should

1348
01:10:48,480 --> 01:10:49,840
carry structurally.

1349
01:10:49,840 --> 01:10:53,880
At Contoso the right opening is not we need a leave app but rather that leave requests move

1350
01:10:53,880 --> 01:10:56,480
too slowly and records are inconsistent.

1351
01:10:56,480 --> 01:11:00,680
When you frame it by saying HR is absorbing repair work that the process should prevent,

1352
01:11:00,680 --> 01:11:04,320
you are no longer just buying software, you are targeting operating drag.

1353
01:11:04,320 --> 01:11:06,880
Step two, choose the metric that must move first.

1354
01:11:06,880 --> 01:11:10,440
Pick one metric or maybe two if they are tightly linked.

1355
01:11:10,440 --> 01:11:13,000
But you must force a decision on what success looks like.

1356
01:11:13,000 --> 01:11:17,000
If cycle time is the urgent problem then the solution has to make rooting and approvals

1357
01:11:17,000 --> 01:11:19,080
more executable for everyone involved.

1358
01:11:19,080 --> 01:11:24,000
If error rate is the main pain then data structure and validation move forward in the order.

1359
01:11:24,000 --> 01:11:28,080
And if cost to service out of control we focus on where manual coordination is compensating

1360
01:11:28,080 --> 01:11:29,560
for weak design.

1361
01:11:29,560 --> 01:11:33,320
This step matters because it stops teams from chasing vague improvement.

1362
01:11:33,320 --> 01:11:37,480
Better experience is too soft to be useful but moving approval time from five days to the

1363
01:11:37,480 --> 01:11:40,600
same day is a target you can actually hit.

1364
01:11:40,600 --> 01:11:42,920
Matrix turn architecture into a management decision.

1365
01:11:42,920 --> 01:11:44,640
Step three, assess the three forces.

1366
01:11:44,640 --> 01:11:48,880
We need to look at data gravity, process criticality and identity and governance.

1367
01:11:48,880 --> 01:11:52,920
We already walked through these concepts but now we use them as a gate to decide if a

1368
01:11:52,920 --> 01:11:54,800
project is ready to move forward.

1369
01:11:54,800 --> 01:11:57,000
Where does the data live and can we trust it?

1370
01:11:57,000 --> 01:11:59,760
How often does the process run and what breaks when it fails?

1371
01:11:59,760 --> 01:12:03,400
Who needs access and what control model must exist before the scales?

1372
01:12:03,400 --> 01:12:07,160
This is the part most team skip because it feels slower than building but it is also the

1373
01:12:07,160 --> 01:12:09,680
part that prevents the expensive wrong build.

1374
01:12:09,680 --> 01:12:13,080
Step four, assign tool roles instead of searching for one hero product.

1375
01:12:13,080 --> 01:12:16,880
This is where leaders usually relax because once the problem and the forces are clear the

1376
01:12:16,880 --> 01:12:18,800
tools become much easier to place.

1377
01:12:18,800 --> 01:12:23,800
Power apps owns guided interaction, power automate, own execution and handoffs and power bi-owns

1378
01:12:23,800 --> 01:12:25,760
visibility and management signal.

1379
01:12:25,760 --> 01:12:30,520
Power pages owns external access where that boundary is real, while co-pilot studio owns

1380
01:12:30,520 --> 01:12:35,120
conversational access and assistant behavior where the underlying process is stable enough

1381
01:12:35,120 --> 01:12:36,120
to support it.

1382
01:12:36,120 --> 01:12:39,480
That is a much better conversation than asking which one tool can solve everything.

1383
01:12:39,480 --> 01:12:42,520
None of them should be carrying the full burden alone.

1384
01:12:42,520 --> 01:12:45,840
Step five, decide build order, ownership and review points.

1385
01:12:45,840 --> 01:12:47,960
Notice I did not say decide features first.

1386
01:12:47,960 --> 01:12:52,000
You need to decide the build order, the ownership and the review points before you ever worry

1387
01:12:52,000 --> 01:12:53,640
about the buttons on the screen.

1388
01:12:53,640 --> 01:12:55,400
What becomes stable before anything else?

1389
01:12:55,400 --> 01:12:56,680
Who owns the record model?

1390
01:12:56,680 --> 01:12:58,240
Who owns the automation behavior?

1391
01:12:58,240 --> 01:13:00,040
And who owns the support after launch?

1392
01:13:00,040 --> 01:13:03,520
If you cannot answer those questions, you do not have a delivery plan yet.

1393
01:13:03,520 --> 01:13:04,880
You just have enthusiasm.

1394
01:13:04,880 --> 01:13:06,320
An enthusiasm is not governance.

1395
01:13:06,320 --> 01:13:07,920
So that is the sequence I would reuse.

1396
01:13:07,920 --> 01:13:11,740
Define the business problem, choose the metric, assess the forces, assign the tool roles

1397
01:13:11,740 --> 01:13:13,520
and set the order and the owners.

1398
01:13:13,520 --> 01:13:16,480
It sounds simple on paper but remains demanding in practice.

1399
01:13:16,480 --> 01:13:22,120
It works because it keeps the platform tied to business reality instead of product excitement.

1400
01:13:22,120 --> 01:13:25,960
Once you start seeing the platform this way, another pattern becomes obvious.

1401
01:13:25,960 --> 01:13:29,680
Each tool gets blamed most often when it was asked to do a job that never belonged

1402
01:13:29,680 --> 01:13:31,480
to it in the first place.

1403
01:13:31,480 --> 01:13:33,600
What each tool should never be asked to do.

1404
01:13:33,600 --> 01:13:37,760
Once the selection sequence is clear, the next step is just as useful because it removes

1405
01:13:37,760 --> 01:13:41,040
a lot of bad expectations before they turn into bad builds.

1406
01:13:41,040 --> 01:13:44,320
We need to be clear about what each tool should never be asked to do.

1407
01:13:44,320 --> 01:13:47,880
This isn't because the tools are weak but because misuse is expensive.

1408
01:13:47,880 --> 01:13:52,200
A lot of frustration inside the power platform comes from assigning one product a job that

1409
01:13:52,200 --> 01:13:55,640
belongs to structure, governance or another layer entirely.

1410
01:13:55,640 --> 01:13:56,920
Start with power apps.

1411
01:13:56,920 --> 01:13:59,880
Do not ask power apps to become your process governance model.

1412
01:13:59,880 --> 01:14:01,760
An app is where people interact.

1413
01:14:01,760 --> 01:14:06,680
And while it can guide input and simplify choices, it cannot rescue a process where the approval

1414
01:14:06,680 --> 01:14:08,240
logic is unclear.

1415
01:14:08,240 --> 01:14:12,400
If ownership is undefined or the process has no stable state model, the app only gives

1416
01:14:12,400 --> 01:14:14,400
the confusion a cleaner screen.

1417
01:14:14,400 --> 01:14:18,720
That is why we need an app is so often only half-right because the app is not the policy

1418
01:14:18,720 --> 01:14:20,520
model or the operating model.

1419
01:14:20,520 --> 01:14:21,800
Now power automate.

1420
01:14:21,800 --> 01:14:25,320
Do not ask power automate to compensate for bad data structure.

1421
01:14:25,320 --> 01:14:29,280
A flow can root, notify and update work from one state to another.

1422
01:14:29,280 --> 01:14:31,760
But it depends entirely on clarity to function.

1423
01:14:31,760 --> 01:14:35,680
If the leaf type means different things in different places or records are duplicated,

1424
01:14:35,680 --> 01:14:36,840
automation does not solve the problem.

1425
01:14:36,840 --> 01:14:37,840
It multiplies it.

1426
01:14:37,840 --> 01:14:40,760
Fast automation on weak data is just fast disorder.

1427
01:14:40,760 --> 01:14:44,960
That is why so many flows look technically correct and still produce business pain because

1428
01:14:44,960 --> 01:14:48,120
the logic runs, but the structure underneath it does not hold.

1429
01:14:48,120 --> 01:14:49,120
Now power BI.

1430
01:14:49,120 --> 01:14:53,880
Do not ask power BI to clean up operational inconsistency after the fact.

1431
01:14:53,880 --> 01:14:57,720
Reporting is a visibility layer that helps us see patterns and gaps, but if the categories

1432
01:14:57,720 --> 01:15:00,560
are drifting or source records are incomplete.

1433
01:15:00,560 --> 01:15:04,840
The dashboard becomes a polished argument instead of a trusted signal.

1434
01:15:04,840 --> 01:15:09,000
Power BI can expose inconsistency beautifully, but it cannot remove it retroactively.

1435
01:15:09,000 --> 01:15:13,440
An executive's complaint that reporting is unreliable, the problem often started much

1436
01:15:13,440 --> 01:15:16,680
earlier inside process design and record discipline.

1437
01:15:16,680 --> 01:15:17,880
Now power pages.

1438
01:15:17,880 --> 01:15:21,920
Do not ask power pages to solve identity strategy by itself.

1439
01:15:21,920 --> 01:15:26,080
Pages gives you a front door for external access, letting suppliers or partners interact

1440
01:15:26,080 --> 01:15:29,120
with the business process without dragging them through internal tooling.

1441
01:15:29,120 --> 01:15:33,840
However, the portal itself should not be carrying the entire burden of who gets access

1442
01:15:33,840 --> 01:15:36,600
and how that control stays governable over time.

1443
01:15:36,600 --> 01:15:38,760
Those are identity and governance questions first.

1444
01:15:38,760 --> 01:15:41,920
If those decisions are weak, power pages does not remove the risk.

1445
01:15:41,920 --> 01:15:45,920
It exposes it at the company boundary where mistakes usually cost more.

1446
01:15:45,920 --> 01:15:47,960
And then co-pilot studio.

1447
01:15:47,960 --> 01:15:51,640
Do not ask co-pilot studio to become a shortcut around architecture.

1448
01:15:51,640 --> 01:15:55,480
This one matters now because the pressure is rising fast and people assume they can skip

1449
01:15:55,480 --> 01:15:58,240
boring steps by using a conversational layer.

1450
01:15:58,240 --> 01:16:02,240
An assistant is still sitting on top of data, permissions and logic and if those are unclear,

1451
01:16:02,240 --> 01:16:04,040
the agent does not become magical.

1452
01:16:04,040 --> 01:16:05,040
It becomes unpredictable.

1453
01:16:05,040 --> 01:16:07,000
The assistant is not the architecture.

1454
01:16:07,000 --> 01:16:08,400
It is an interaction layer.

1455
01:16:08,400 --> 01:16:11,200
It is a very powerful one, yes, but it is still just a layer.

1456
01:16:11,200 --> 01:16:15,520
When all of that is visible, a final pattern emerges where the platform usually gets blamed

1457
01:16:15,520 --> 01:16:19,040
when a tool is forced to compensate for a design failure that should have been solved

1458
01:16:19,040 --> 01:16:20,120
somewhere else.

1459
01:16:20,120 --> 01:16:23,160
The platform itself usually is not what failed.

1460
01:16:23,160 --> 01:16:26,200
Final reframing, the platform doesn't fail, the starting point does.

1461
01:16:26,200 --> 01:16:29,240
So this is the final reframing I want to leave you with today.

1462
01:16:29,240 --> 01:16:33,200
Most power platform disappointment gets diagnosed at the tool layer because that is the visible

1463
01:16:33,200 --> 01:16:35,000
layer where we feel the friction.

1464
01:16:35,000 --> 01:16:38,800
The app feels clunky, the flow breaks or the dashboard doesn't match what leadership

1465
01:16:38,800 --> 01:16:40,160
expected to see.

1466
01:16:40,160 --> 01:16:44,200
When the portal never gets adopted or the assistant gives weak answers, people start talking

1467
01:16:44,200 --> 01:16:46,360
as if the platform itself let them down.

1468
01:16:46,360 --> 01:16:50,160
But if you trace most of those failures back far enough, the break rarely starts in the

1469
01:16:50,160 --> 01:16:51,160
product.

1470
01:16:51,160 --> 01:16:52,800
It starts in the starting point.

1471
01:16:52,800 --> 01:16:57,120
Back at Contoso, I want you to imagine the connected future state we have been building

1472
01:16:57,120 --> 01:17:01,280
toward throughout this entire episode and employee opens a clean request experience

1473
01:17:01,280 --> 01:17:05,720
and submits leave through a structured form which ensures the request lands as a trusted operational

1474
01:17:05,720 --> 01:17:09,120
record rather than a vague message that someone has to interpret.

1475
01:17:09,120 --> 01:17:13,080
Approval routing starts immediately because ownership and escalation logic were decided

1476
01:17:13,080 --> 01:17:17,320
before launch, allowing managers to act quickly since the decision path is clear.

1477
01:17:17,320 --> 01:17:21,800
HR sees exceptions instead of every preventable mistake while leadership gets visibility into

1478
01:17:21,800 --> 01:17:26,160
lag, volume and staffing impact through reporting that reflects a stable process.

1479
01:17:26,160 --> 01:17:31,200
If a conversational layer adds value, an agent can answer policy questions and check request

1480
01:17:31,200 --> 01:17:36,000
status without improvising across broken foundations, that future state does not come from one

1481
01:17:36,000 --> 01:17:37,120
hero product.

1482
01:17:37,120 --> 01:17:39,720
It comes from connected decisions made in the right order.

1483
01:17:39,720 --> 01:17:43,360
And once you see that, the outcome metrics stop feeling abstract.

1484
01:17:43,360 --> 01:17:47,440
Cycle time drops because the path is executable, and error rates fall because the structure

1485
01:17:47,440 --> 01:17:50,320
reduces bad input before it has a chance to spread.

1486
01:17:50,320 --> 01:17:54,320
Cost to serve drops because the people inside the process stop acting as manual glue between

1487
01:17:54,320 --> 01:17:58,480
disconnected parts which means they can finally focus on higher value work.

1488
01:17:58,480 --> 01:18:00,480
Those are not side benefits, that is the whole point.

1489
01:18:00,480 --> 01:18:04,000
So when a team says they need a power app or they should automate something, I want us

1490
01:18:04,000 --> 01:18:06,040
to hear the sentence underneath the sentence.

1491
01:18:06,040 --> 01:18:07,800
Usually it sounds more like this.

1492
01:18:07,800 --> 01:18:11,400
We are feeling pain somewhere in the operating model and we are about to name a tool before

1493
01:18:11,400 --> 01:18:12,760
we name the constraint.

1494
01:18:12,760 --> 01:18:17,280
That move is understandable, but it is also incredibly expensive because once the build

1495
01:18:17,280 --> 01:18:21,760
starts from the visible layer, everything underneath gets forced into structural compensation.

1496
01:18:21,760 --> 01:18:26,160
The data model gets patched later, governance gets added later, and reporting gets repaired

1497
01:18:26,160 --> 01:18:31,840
later, which means identity and support ownership only get clarified once things start to break.

1498
01:18:31,840 --> 01:18:34,920
Later is where a lot of digital projects quietly become fragile.

1499
01:18:34,920 --> 01:18:37,920
So the platform does not fail in the way people think it does.

1500
01:18:37,920 --> 01:18:40,600
The platform often does exactly what we asked it to do.

1501
01:18:40,600 --> 01:18:46,440
Power apps gives us a front end, power automate, executes logic, and power BI reveals patterns.

1502
01:18:46,440 --> 01:18:50,480
Power pages opens an external channel while co-pilot studio gives us an assistant layer,

1503
01:18:50,480 --> 01:18:54,080
but the system only behaves according to the decisions wrapped around it.

1504
01:18:54,080 --> 01:18:56,240
If those decisions are weak, the outcome is weak.

1505
01:18:56,240 --> 01:18:59,680
If those decisions are coherent, the platform starts looking far more capable than many

1506
01:18:59,680 --> 01:19:03,080
people first assumed, which brings me back to the line we started building through this

1507
01:19:03,080 --> 01:19:04,080
episode.

1508
01:19:04,080 --> 01:19:06,160
The sequence matters more than the enthusiasm.

1509
01:19:06,160 --> 01:19:07,160
And why is that?

1510
01:19:07,160 --> 01:19:11,040
Because enthusiasm loves visible progress, but architecture cares about durable progress

1511
01:19:11,040 --> 01:19:13,280
that can actually stand the test of time.

1512
01:19:13,280 --> 01:19:17,480
One gets applause in the demo while the other survives policy changes, scale audits, and

1513
01:19:17,480 --> 01:19:20,560
the boring reality of operating a process month after month.

1514
01:19:20,560 --> 01:19:22,040
That is business reality.

1515
01:19:22,040 --> 01:19:25,920
So if you want to move from isolated tools to connected solutions, do not start by asking

1516
01:19:25,920 --> 01:19:28,720
which power platform product should win the argument.

1517
01:19:28,720 --> 01:19:30,200
Start by asking the better first question.

1518
01:19:30,200 --> 01:19:34,160
What is failing structurally in the business process and what must become stable before anything

1519
01:19:34,160 --> 01:19:35,160
else can work?

1520
01:19:35,160 --> 01:19:39,320
That question is quieter and less exciting, but it is much more useful for long term success.

1521
01:19:39,320 --> 01:19:42,880
Because once the first question is right, the platform starts making sense and the tools

1522
01:19:42,880 --> 01:19:44,120
stop competing in your mind.

1523
01:19:44,120 --> 01:19:48,600
They start taking their proper roles as the architecture emerges in sequence and you realize

1524
01:19:48,600 --> 01:19:52,600
that a lot of confusion that looked technical was actually just a diagnostic failure at the

1525
01:19:52,600 --> 01:19:54,080
start.

1526
01:19:54,080 --> 01:19:57,800
So no, I do not think the power platform is confusing because Microsoft gave us too many

1527
01:19:57,800 --> 01:19:58,800
tools.

1528
01:19:58,800 --> 01:20:02,000
I think it becomes confusing when we ask a tool to tell us what the business problem actually

1529
01:20:02,000 --> 01:20:03,000
is.

1530
01:20:03,000 --> 01:20:04,000
That is not its job.

1531
01:20:04,000 --> 01:20:07,960
Our job is to define the operating problem clearly enough that each layer can do its

1532
01:20:07,960 --> 01:20:08,960
part.

1533
01:20:08,960 --> 01:20:10,560
Then the platform stops looking messy.

1534
01:20:10,560 --> 01:20:12,560
It starts looking honest.

1535
01:20:12,560 --> 01:20:17,200
It shows us whether we are solving for interface, execution, visibility, external access or

1536
01:20:17,200 --> 01:20:18,680
assisted interaction.

1537
01:20:18,680 --> 01:20:21,920
And once that is clear, better outcomes stop being accidental.

1538
01:20:21,920 --> 01:20:24,040
They become much easier to design.

1539
01:20:24,040 --> 01:20:27,560
If you have ever built something that looked right and still failed, the foundation was probably

1540
01:20:27,560 --> 01:20:28,560
wrong.

1541
01:20:28,560 --> 01:20:30,760
And the next foundation question is always your data.

1542
01:20:30,760 --> 01:20:34,320
If this episode helped you pressure test how you choose tools, leave a review for the

1543
01:20:34,320 --> 01:20:37,200
podcast and connect with me, Mirko Peters on LinkedIn.

1544
01:20:37,200 --> 01:20:40,280
Tell me which process or platform question I should tackle next because next time we

1545
01:20:40,280 --> 01:20:45,040
go straight into Dataverse to talk about where your data lives, who owns it and why everything

1546
01:20:45,040 --> 01:20:46,520
breaks when that layer is weak.