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

2
00:00:05,000 --> 00:00:10,220
Contoso now has clean dataverse tables, structured employee records, vacation requests, approval

3
00:00:10,220 --> 00:00:14,280
states and country rules, but none of that fixes the real problem yet because people still

4
00:00:14,280 --> 00:00:17,320
can't work through the process in a way that changes behavior.

5
00:00:17,320 --> 00:00:20,520
Data on its own is only stored in tent, it's not execution.

6
00:00:20,520 --> 00:00:24,320
And this is where most first power platform projects either create momentum or quietly

7
00:00:24,320 --> 00:00:25,320
stall.

8
00:00:25,320 --> 00:00:28,880
In this episode, we move from structure to interaction and I'll show you how one decision

9
00:00:28,880 --> 00:00:35,000
canvas or model driven shapes adoption, licensing, governance and how fast a vacation request

10
00:00:35,000 --> 00:00:38,880
moves from someone's head into an actual business outcome.

11
00:00:38,880 --> 00:00:42,640
The moment data stops being enough, so let's step into Contoso for a second.

12
00:00:42,640 --> 00:00:46,240
Up to this point, they've done something a lot of organizations never do properly.

13
00:00:46,240 --> 00:00:48,040
They created structure first.

14
00:00:48,040 --> 00:00:51,280
Employee data is in dataverse, vacation requests have a place to live.

15
00:00:51,280 --> 00:00:55,120
Approval status is no longer a vague phrase inside someone's inbox.

16
00:00:55,120 --> 00:00:58,000
Country rules exist as data instead of tribal memory.

17
00:00:58,000 --> 00:01:01,200
On paper, that sounds like progress and it is.

18
00:01:01,200 --> 00:01:05,520
But only in the same way a well-organized warehouse is progress before the delivery trucks start

19
00:01:05,520 --> 00:01:06,520
moving.

20
00:01:06,520 --> 00:01:09,200
Because if you look closely, the operating pain is still there.

21
00:01:09,200 --> 00:01:12,840
An employee still wants time off and still starts with the easiest available path, which

22
00:01:12,840 --> 00:01:17,040
is usually an email, a team's message or some half-verbal agreement with a manager.

23
00:01:17,040 --> 00:01:19,080
The manager still has to remember what was agreed.

24
00:01:19,080 --> 00:01:23,440
HR still ends up checking spreadsheets, inbox threads and local policy notes to work out

25
00:01:23,440 --> 00:01:24,640
what is actually true.

26
00:01:24,640 --> 00:01:26,440
So yes, the data model is cleaner.

27
00:01:26,440 --> 00:01:31,060
But the day-to-day business reality has not changed yet because the people inside the process

28
00:01:31,060 --> 00:01:33,160
are still interacting with the old front door.

29
00:01:33,160 --> 00:01:34,160
And why is that?

30
00:01:34,160 --> 00:01:37,200
Because stored data and enacted process are not the same thing.

31
00:01:37,200 --> 00:01:38,560
We mix those up all the time.

32
00:01:38,560 --> 00:01:42,360
We think that once a table exists, the business is somehow more mature.

33
00:01:42,360 --> 00:01:44,240
But maturity does not come from storage.

34
00:01:44,240 --> 00:01:46,160
It comes from repeatable behavior.

35
00:01:46,160 --> 00:01:49,320
It comes from making the right action easier than the wrong one.

36
00:01:49,320 --> 00:01:51,120
That is the gap most teams miss.

37
00:01:51,120 --> 00:01:55,560
They celebrate that they now have the data, but what they really have is an inventory of

38
00:01:55,560 --> 00:01:57,360
decisions not yet taken.

39
00:01:57,360 --> 00:02:00,360
The employee has not submitted the request through a governed path.

40
00:02:00,360 --> 00:02:03,280
The manager has not approved anything through a visible mechanism.

41
00:02:03,280 --> 00:02:07,880
HR has not gained operational clarity just because a dataverse table is ready.

42
00:02:07,880 --> 00:02:12,040
Until someone can enter, review and move work through a usable interface, the system is

43
00:02:12,040 --> 00:02:13,040
structurally incomplete.

44
00:02:13,040 --> 00:02:14,520
It's not a people problem.

45
00:02:14,520 --> 00:02:15,520
It's a system outcome.

46
00:02:15,520 --> 00:02:19,560
The people are using email because email still behaves like the path of least resistance.

47
00:02:19,560 --> 00:02:22,240
And the system is doing exactly what it was shaped to do.

48
00:02:22,240 --> 00:02:26,360
That captures data well enough for architects and admins to feel progress, but it does not

49
00:02:26,360 --> 00:02:30,120
yet change the human experience at the point where the request enters the business.

50
00:02:30,120 --> 00:02:34,080
This clicked for me years ago when I watched teams proudly present a new data model and

51
00:02:34,080 --> 00:02:36,440
then act surprised that adoption stayed flat.

52
00:02:36,440 --> 00:02:38,080
They had solved storage but not interaction.

53
00:02:38,080 --> 00:02:40,240
In technical terms, they had a back end.

54
00:02:40,240 --> 00:02:42,240
In business terms, they still had friction.

55
00:02:42,240 --> 00:02:43,760
And friction always finds a workaround.

56
00:02:43,760 --> 00:02:45,440
Now map that to vacation requests.

57
00:02:45,440 --> 00:02:46,760
The employee's real job is simple.

58
00:02:46,760 --> 00:02:47,760
I need time off.

59
00:02:47,760 --> 00:02:48,800
I need to know who sees this.

60
00:02:48,800 --> 00:02:52,480
I need confidence that it won't disappear into someone's calendar chaos.

61
00:02:52,480 --> 00:02:53,920
The manager's job is also simple.

62
00:02:53,920 --> 00:02:54,920
Is this valid?

63
00:02:54,920 --> 00:02:55,920
Does it fit the team context?

64
00:02:55,920 --> 00:02:57,400
And who covers if I'm away?

65
00:02:57,400 --> 00:02:58,880
HR needs something else again.

66
00:02:58,880 --> 00:03:02,600
Consistency, visibility, a clean record, less chasing.

67
00:03:02,600 --> 00:03:05,040
None of those jobs are solved by tables alone.

68
00:03:05,040 --> 00:03:09,080
Tables matter because they give us structure, status, relationships and future reporting.

69
00:03:09,080 --> 00:03:11,920
They are the backbone, but nobody experiences a backbone directly.

70
00:03:11,920 --> 00:03:13,600
What they experience is the front door.

71
00:03:13,600 --> 00:03:18,200
They experience whether the process feels clear, fast and trustworthy or vague, slow and

72
00:03:18,200 --> 00:03:19,200
social.

73
00:03:19,200 --> 00:03:20,680
That is why the first app matters so much.

74
00:03:20,680 --> 00:03:23,640
Not because it proves power apps can render screens.

75
00:03:23,640 --> 00:03:26,280
Not because it gives leadership something shiny to demo.

76
00:03:26,280 --> 00:03:29,840
It matters because it is the first moment where the business stops asking, do we have the

77
00:03:29,840 --> 00:03:30,840
data?

78
00:03:30,840 --> 00:03:34,000
And starts asking, can people actually work through this in a better way?

79
00:03:34,000 --> 00:03:35,880
Once you see that gap, the next question changes.

80
00:03:35,880 --> 00:03:37,520
It is no longer, can we build an app?

81
00:03:37,520 --> 00:03:38,520
Of course we can.

82
00:03:38,520 --> 00:03:42,280
The real question is, what kind of app are we actually building and what operating behavior

83
00:03:42,280 --> 00:03:44,000
are we trying to create?

84
00:03:44,000 --> 00:03:45,720
The real job of a first app.

85
00:03:45,720 --> 00:03:49,920
So before we talk about screens, controls or whether canvas feels easier than model driven,

86
00:03:49,920 --> 00:03:51,480
we need one clean reframing.

87
00:03:51,480 --> 00:03:52,960
The first app is not a feature demo.

88
00:03:52,960 --> 00:03:54,600
It is a business interface.

89
00:03:54,600 --> 00:03:58,520
And that difference changes almost every decision that comes after it because when teams

90
00:03:58,520 --> 00:04:03,320
treat the first app like a demo, they optimize for what looks impressive in a workshop.

91
00:04:03,320 --> 00:04:07,600
When they treat it like a business interface, they optimize for what removes friction at

92
00:04:07,600 --> 00:04:11,200
the exact point where work enters the system and starts moving.

93
00:04:11,200 --> 00:04:12,520
That is the real job.

94
00:04:12,520 --> 00:04:15,040
In Contoso, nobody wakes up wanting a power app.

95
00:04:15,040 --> 00:04:16,040
That is not the need.

96
00:04:16,040 --> 00:04:18,760
The need is much simpler and much more operational.

97
00:04:18,760 --> 00:04:20,480
An employee wants to ask for time off.

98
00:04:20,480 --> 00:04:23,440
A manager wants to review that request without hunting for context.

99
00:04:23,440 --> 00:04:27,120
HR wants to know what is pending, what is approved and where the process is stuck.

100
00:04:27,120 --> 00:04:28,440
So the app is not the product.

101
00:04:28,440 --> 00:04:32,400
The app is the door through which that operational behavior becomes consistent.

102
00:04:32,400 --> 00:04:33,920
And why does that matter so much?

103
00:04:33,920 --> 00:04:36,880
Because first apps teach the organization what low code means.

104
00:04:36,880 --> 00:04:40,840
If the first app feels bloated, confusing or overbuilt, people conclude the platform is

105
00:04:40,840 --> 00:04:41,840
messy.

106
00:04:41,840 --> 00:04:44,840
If the first app is clear, fast and trustworthy, people conclude the platform can

107
00:04:44,840 --> 00:04:46,600
reduce friction in real work.

108
00:04:46,600 --> 00:04:49,320
Same technology, different lessons, different business outcome.

109
00:04:49,320 --> 00:04:54,320
This is where most people miss the split between the human job and the system job.

110
00:04:54,320 --> 00:04:57,280
The human job in a vacation request process is very small.

111
00:04:57,280 --> 00:04:59,000
Ask, review, approve, track.

112
00:04:59,000 --> 00:05:00,000
That is it.

113
00:05:00,000 --> 00:05:01,680
But the system job is not small at all.

114
00:05:01,680 --> 00:05:03,600
The system has to validate the submission.

115
00:05:03,600 --> 00:05:05,840
It has to root the request into the correct path.

116
00:05:05,840 --> 00:05:09,760
It has to record status changes in a way that stays visible and auditable.

117
00:05:09,760 --> 00:05:14,160
And it has to expose enough status back to the employee, manager and HR team.

118
00:05:14,160 --> 00:05:18,200
So nobody is forced back into site channel communication just to understand what is happening.

119
00:05:18,200 --> 00:05:22,800
So when we design the first app, we are not building around every system responsibility

120
00:05:22,800 --> 00:05:23,800
at once.

121
00:05:23,800 --> 00:05:27,800
We are deciding where the human interaction should be simple and where the underlying structure

122
00:05:27,800 --> 00:05:29,680
should carry the weight instead.

123
00:05:29,680 --> 00:05:31,400
That distinction protects us.

124
00:05:31,400 --> 00:05:35,240
Because the first release should narrow scope, not prove everything the platform can do.

125
00:05:35,240 --> 00:05:39,920
A lot of teams try to use the first app as a stage for every capability they have just

126
00:05:39,920 --> 00:05:40,920
learned.

127
00:05:40,920 --> 00:05:41,920
Tabs everywhere.

128
00:05:41,920 --> 00:05:43,520
Conditional logic everywhere.

129
00:05:43,520 --> 00:05:47,760
It feels because they might be useful later, but that approach creates structural drag

130
00:05:47,760 --> 00:05:49,480
before trust has even formed.

131
00:05:49,480 --> 00:05:53,000
A first app earns trust by being small enough to succeed.

132
00:05:53,000 --> 00:05:58,200
At Contoso, success does not mean we digitize leave management in some giant abstract sense.

133
00:05:58,200 --> 00:06:00,360
Success means something much more grounded.

134
00:06:00,360 --> 00:06:03,320
An employee can submit a request in one clear place.

135
00:06:03,320 --> 00:06:05,880
A manager can see it without inbox archaeology.

136
00:06:05,880 --> 00:06:08,640
HR can track status without chasing people.

137
00:06:08,640 --> 00:06:12,160
And the cycle time starts dropping because the request no longer enters the business as

138
00:06:12,160 --> 00:06:13,480
an unstructured message.

139
00:06:13,480 --> 00:06:14,480
That is the threshold.

140
00:06:14,480 --> 00:06:17,160
Once you nail that, everything else clicks.

141
00:06:17,160 --> 00:06:19,840
Because now the app is doing what a first app should do.

142
00:06:19,840 --> 00:06:22,960
It reduces friction at the point where decisions enter the system.

143
00:06:22,960 --> 00:06:25,640
It makes the process more visible than memory.

144
00:06:25,640 --> 00:06:29,040
And it starts replacing social guesswork with operational clarity.

145
00:06:29,040 --> 00:06:30,520
The reason this works is simple.

146
00:06:30,520 --> 00:06:32,080
People trust processes they can see.

147
00:06:32,080 --> 00:06:34,040
They avoid processes that feel ambiguous.

148
00:06:34,040 --> 00:06:36,160
So the first app should not try to look advanced.

149
00:06:36,160 --> 00:06:40,040
It should try to make the next action obvious and the current status legible.

150
00:06:40,040 --> 00:06:41,440
That is where the value comes from.

151
00:06:41,440 --> 00:06:47,200
Not from animation, not from complexity, not from showing the full future architecture on day one.

152
00:06:47,200 --> 00:06:49,640
From reducing the cost of doing the right thing.

153
00:06:49,640 --> 00:06:52,160
And once you understand that, another point becomes obvious.

154
00:06:52,160 --> 00:06:54,600
The wrong first app does not just fail quietly.

155
00:06:54,600 --> 00:06:56,520
It teaches the organization the wrong lesson.

156
00:06:56,520 --> 00:06:58,560
It tells people low code creates clutter.

157
00:06:58,560 --> 00:07:00,040
That forms create overhead.

158
00:07:00,040 --> 00:07:03,240
And that structured processes are slower than informal ones.

159
00:07:03,240 --> 00:07:06,000
From a system perspective, that is not just disappointing.

160
00:07:06,000 --> 00:07:09,160
It is expensive because now your next app starts from distrust.

161
00:07:09,160 --> 00:07:13,920
So before we choose canvas or model driven, we need one clean definition of the problem

162
00:07:13,920 --> 00:07:15,480
we are actually solving.

163
00:07:15,480 --> 00:07:18,200
Why first apps fail before anyone opens them?

164
00:07:18,200 --> 00:07:20,400
Why first apps fail before anyone opens them?

165
00:07:20,400 --> 00:07:24,760
Most first apps fail long before a user taps the icon because the failure usually starts

166
00:07:24,760 --> 00:07:28,000
in the design conversation, not in the release itself.

167
00:07:28,000 --> 00:07:29,760
The team begins with screens.

168
00:07:29,760 --> 00:07:31,080
Someone sketches a homepage.

169
00:07:31,080 --> 00:07:32,360
Someone else asks for tabs.

170
00:07:32,360 --> 00:07:36,200
A manager wants a dashboard and HR wants every exception visible from day one.

171
00:07:36,200 --> 00:07:38,920
The app starts taking shape as a collection of requests.

172
00:07:38,920 --> 00:07:41,720
But no one has yet defined what the system is supposed to change.

173
00:07:41,720 --> 00:07:42,960
That sequence sounds normal.

174
00:07:42,960 --> 00:07:45,000
It is also where the drag begins.

175
00:07:45,000 --> 00:07:49,000
Because if you start with screens, you usually copy the old process into a new interface.

176
00:07:49,000 --> 00:07:50,720
The email form becomes a digital form.

177
00:07:50,720 --> 00:07:52,640
The spreadsheet columns become fields.

178
00:07:52,640 --> 00:07:54,520
The approval confusion becomes a drop down.

179
00:07:54,520 --> 00:07:57,360
It looks more modern, but the operating behavior stays the same.

180
00:07:57,360 --> 00:07:59,440
People still carry interpretation in their heads.

181
00:07:59,440 --> 00:08:00,840
They still work around ambiguity.

182
00:08:00,840 --> 00:08:05,200
They still compensate for a weak process through extra messages inside conversations.

183
00:08:05,200 --> 00:08:07,880
So the app looks cleaner, but the business does not move faster.

184
00:08:07,880 --> 00:08:09,160
I see this all the time.

185
00:08:09,160 --> 00:08:13,320
Teams call it digitization when what they really built is a better looking version of the

186
00:08:13,320 --> 00:08:14,720
same structural problem.

187
00:08:14,720 --> 00:08:16,560
They rebuild friction in a nicer font.

188
00:08:16,560 --> 00:08:20,960
And then they wonder why adoption is hesitant, why support questions pile up, and why nobody

189
00:08:20,960 --> 00:08:24,640
trusts the status field enough to stop sending follow-up emails.

190
00:08:24,640 --> 00:08:25,640
The reason is simple.

191
00:08:25,640 --> 00:08:27,320
They never define system intent.

192
00:08:27,320 --> 00:08:29,880
System intent is the answer to a very plain question.

193
00:08:29,880 --> 00:08:33,440
What should happen for whom under what conditions and what should become visible the moment

194
00:08:33,440 --> 00:08:35,440
that action enters the business?

195
00:08:35,440 --> 00:08:38,080
If that is not clear, the app has no stable center.

196
00:08:38,080 --> 00:08:39,880
It becomes a surface for collecting wishes.

197
00:08:39,880 --> 00:08:42,280
And once that starts, overdesign takes over.

198
00:08:42,280 --> 00:08:47,760
A leader asks, what if the employee wants half days in one country and carry over in another?

199
00:08:47,760 --> 00:08:50,360
Someone else asks, what if the manager is absent for two weeks?

200
00:08:50,360 --> 00:08:55,480
HR asks for attachments, comments, override paths, custom notices, and maybe a special branch

201
00:08:55,480 --> 00:08:57,200
for senior executives.

202
00:08:57,200 --> 00:08:59,280
None of those questions are unreasonable on their own.

203
00:08:59,280 --> 00:09:02,240
But if you answer all of them in release one, you no longer have a first app.

204
00:09:02,240 --> 00:09:05,040
You have a fragile negotiation between edge cases.

205
00:09:05,040 --> 00:09:07,120
From a system perspective, that is not maturity.

206
00:09:07,120 --> 00:09:09,160
It is early stage complexity debt.

207
00:09:09,160 --> 00:09:13,240
Because the thing most people miss is that exceptions are real, but they are not equally important

208
00:09:13,240 --> 00:09:14,240
at the beginning.

209
00:09:14,240 --> 00:09:18,240
If you build around them too early, the main path gets buried under conditional logic,

210
00:09:18,240 --> 00:09:20,440
extra fields, and unclear navigation.

211
00:09:20,440 --> 00:09:25,040
The employee who just wants to request five days off now enters a process that feels

212
00:09:25,040 --> 00:09:26,680
heavier than the old email.

213
00:09:26,680 --> 00:09:31,400
So the new system loses before it even has a chance to teach a better habit.

214
00:09:31,400 --> 00:09:34,280
There is another failure point that sits underneath all this.

215
00:09:34,280 --> 00:09:37,080
And beginners usually do not see it until later.

216
00:09:37,080 --> 00:09:38,560
Hidden licensing choices.

217
00:09:38,560 --> 00:09:42,520
A team adds data verse, which may be the right architectural choice, but they do not stop

218
00:09:42,520 --> 00:09:45,000
to ask what that means for licensing.

219
00:09:45,000 --> 00:09:48,600
Then someone suggests a custom connector to some external HR endpoint because it sounds

220
00:09:48,600 --> 00:09:49,800
small and elegant.

221
00:09:49,800 --> 00:09:54,560
But a small integration choice can change the cost model fast because custom connectors and

222
00:09:54,560 --> 00:09:57,000
premium capabilities are not just technical options.

223
00:09:57,000 --> 00:09:59,280
They reshape the operating cost of the solution.

224
00:09:59,280 --> 00:10:03,120
Now the app carries financial weight, the business never expected.

225
00:10:03,120 --> 00:10:07,000
If that surprise lands after enthusiasm is already high, trust drops.

226
00:10:07,000 --> 00:10:08,880
The same is true for environment shortcuts.

227
00:10:08,880 --> 00:10:11,040
Building in the default environment feels fast.

228
00:10:11,040 --> 00:10:14,760
It removes friction in the moment, but speed without boundaries usually creates cleanup

229
00:10:14,760 --> 00:10:15,760
later.

230
00:10:15,760 --> 00:10:20,240
What looked like convenience was actually governance debt waiting for a production conversation.

231
00:10:20,240 --> 00:10:23,160
So first apps do not fail because power apps is weak.

232
00:10:23,160 --> 00:10:26,680
They fail because teams confuse visible progress with structural clarity.

233
00:10:26,680 --> 00:10:29,720
A good first app is not the one that answers every future question.

234
00:10:29,720 --> 00:10:34,040
It is the one that proves the main path can become simpler, faster and more visible without

235
00:10:34,040 --> 00:10:35,800
creating new fragility underneath.

236
00:10:35,800 --> 00:10:37,880
That means we need to resist fake completeness.

237
00:10:37,880 --> 00:10:39,520
We do not need every exception now.

238
00:10:39,520 --> 00:10:41,960
We do not need the whole future architecture now.

239
00:10:41,960 --> 00:10:46,280
We do need one clean definition of the problem, one clean entry point and one design choice

240
00:10:46,280 --> 00:10:49,160
that improves business behavior immediately.

241
00:10:49,160 --> 00:10:52,920
So before we choose canvas or model driven, we need to define the problem in operating terms

242
00:10:52,920 --> 00:10:54,400
not screen terms.

243
00:10:54,400 --> 00:10:56,840
Define the business problem in operating terms.

244
00:10:56,840 --> 00:11:01,240
So let's define the problem the way the business actually feels it, not we need an app,

245
00:11:01,240 --> 00:11:05,320
not we should modernize HR, not even we want to use power platform better.

246
00:11:05,320 --> 00:11:08,840
Those are all directionally fine, but none of them are operationally useful because they

247
00:11:08,840 --> 00:11:11,840
describe intention, not the work that is breaking.

248
00:11:11,840 --> 00:11:14,080
At Contoso, the real problem is this.

249
00:11:14,080 --> 00:11:18,400
Vacation requests enter the organization through too many paths, move with too little visibility

250
00:11:18,400 --> 00:11:22,600
and depend too heavily on inbox behavior instead of a governed process.

251
00:11:22,600 --> 00:11:26,280
That is the problem and once you say it that way, a lot of noise falls away.

252
00:11:26,280 --> 00:11:29,600
Because now we are not trying to solve leave management in the abstract.

253
00:11:29,600 --> 00:11:33,840
We are trying to solve request entry, decision clarity and status visibility.

254
00:11:33,840 --> 00:11:37,560
That matters because if a problem statement is too broad, the app gets broad.

255
00:11:37,560 --> 00:11:41,560
If the app gets broad, release one gets heavy and heavy first releases usually fail not

256
00:11:41,560 --> 00:11:45,440
because the team lacks skill, but because they are trying to solve a category instead of

257
00:11:45,440 --> 00:11:46,440
a bottleneck.

258
00:11:46,440 --> 00:11:50,560
The current state inside Contoso is familiar and employee needs time off and starts with

259
00:11:50,560 --> 00:11:52,480
whatever path feels fastest.

260
00:11:52,480 --> 00:11:56,480
Sometimes that is email, sometimes it is teams, sometimes it is a local spreadsheet or

261
00:11:56,480 --> 00:12:00,680
a manager saying yes, that should be fine with no formal record created at all.

262
00:12:00,680 --> 00:12:05,120
Then HR gets involved later often after the fact trying to reconstruct what was requested,

263
00:12:05,120 --> 00:12:08,240
what was approved and what policy should have applied in that country.

264
00:12:08,240 --> 00:12:11,200
So the process exists but the operating model is fragmented.

265
00:12:11,200 --> 00:12:13,200
And what does fragmentation create?

266
00:12:13,200 --> 00:12:15,520
Delay, interpretation, inbox dependency.

267
00:12:15,520 --> 00:12:19,480
A manager becomes a routing engine, HR becomes a reconciliation layer, the employee becomes

268
00:12:19,480 --> 00:12:20,840
a follow-up mechanism.

269
00:12:20,840 --> 00:12:22,120
That is not process maturity.

270
00:12:22,120 --> 00:12:23,120
That is manual compensation.

271
00:12:23,120 --> 00:12:27,040
Now, define the desired state just as clearly one request path.

272
00:12:27,040 --> 00:12:31,280
One status model, one visible record of truth that does not mean every edge case is solved

273
00:12:31,280 --> 00:12:32,280
on day one.

274
00:12:32,280 --> 00:12:36,040
It means every normal request enters the business through a common door, carries a shared

275
00:12:36,040 --> 00:12:41,120
set of status values and stays visible enough that nobody needs to rebuild the story from scattered

276
00:12:41,120 --> 00:12:42,120
messages.

277
00:12:42,120 --> 00:12:43,520
That is the operating shift.

278
00:12:43,520 --> 00:12:47,360
And once you define it that way, the KPI becomes obvious, we want to reduce cycle time

279
00:12:47,360 --> 00:12:51,040
from days to hours in some cases with later automation even minutes.

280
00:12:51,040 --> 00:12:54,440
But for this episode, hours is already enough to prove the point.

281
00:12:54,440 --> 00:12:58,640
Because if the request enters the business cleanly, the time lost to clarification, forwarding

282
00:12:58,640 --> 00:13:01,520
and status chasing starts collapsing immediately.

283
00:13:01,520 --> 00:13:03,160
There are supporting outcomes as well.

284
00:13:03,160 --> 00:13:07,800
Approval SLA adherence improves because the request becomes visible and structured.

285
00:13:07,800 --> 00:13:12,720
HR follow-up drops because the system now carries status instead of hiding it in mailboxes.

286
00:13:12,720 --> 00:13:16,600
Absence planning gets cleaner because approved requests become easier to trust and report

287
00:13:16,600 --> 00:13:17,600
on.

288
00:13:17,600 --> 00:13:18,600
But those are supporting outcomes.

289
00:13:18,600 --> 00:13:23,400
The main operating promise stays simple, shorten the time between employee intent and organizational

290
00:13:23,400 --> 00:13:24,400
response.

291
00:13:24,400 --> 00:13:27,800
Now you might be thinking, what about country rules, delegation and all the real world

292
00:13:27,800 --> 00:13:29,600
variation, fair question?

293
00:13:29,600 --> 00:13:30,720
Those are real constraints.

294
00:13:30,720 --> 00:13:32,600
They are not reasons to delay problem definition.

295
00:13:32,600 --> 00:13:35,240
In fact, they make good definition more important.

296
00:13:35,240 --> 00:13:38,600
Because country policy complexity does not change the nature of the problem.

297
00:13:38,600 --> 00:13:41,160
It changes the structure behind the process.

298
00:13:41,160 --> 00:13:43,520
Delegation does not change the need for one request path.

299
00:13:43,520 --> 00:13:46,440
It changes who can act when the manager is unavailable.

300
00:13:46,440 --> 00:13:48,680
Those are design constraints inside the system.

301
00:13:48,680 --> 00:13:51,000
They are not excuses to keep the front door vague.

302
00:13:51,000 --> 00:13:53,520
This is where good app design starts getting more disciplined.

303
00:13:53,520 --> 00:13:56,760
Not with pages, with three things, event decision status.

304
00:13:56,760 --> 00:13:59,200
The event is the employee asking for time off.

305
00:13:59,200 --> 00:14:02,360
The decision is whether that request fits policy and team reality.

306
00:14:02,360 --> 00:14:05,880
The status is the visible state that tells everyone where the request now sits.

307
00:14:05,880 --> 00:14:08,560
If you get those three right, the architecture starts to stabilize.

308
00:14:08,560 --> 00:14:10,480
If you skip them, the app becomes decorative.

309
00:14:10,480 --> 00:14:14,480
It may look useful, but underneath it is still asking people to carry too much meaning

310
00:14:14,480 --> 00:14:15,480
in their heads.

311
00:14:15,480 --> 00:14:18,960
Before we draw anything, we define the business problem in operating terms.

312
00:14:18,960 --> 00:14:23,680
A request enters through inconsistent channels, moves through invisible decisions, and produces

313
00:14:23,680 --> 00:14:25,160
unnecessary delay.

314
00:14:25,160 --> 00:14:28,800
The solution, at least in release one, is not digital transformation.

315
00:14:28,800 --> 00:14:34,520
It is a controlled entry point, a shared status model, and a faster path from request to response.

316
00:14:34,520 --> 00:14:39,440
Now map that to how Contoso actually works today, and the architecture starts to reveal itself.

317
00:14:39,440 --> 00:14:42,040
The process map behind a simple vacation request.

318
00:14:42,040 --> 00:14:46,680
So now we move from problem definition into process shape, because once you know the bottleneck,

319
00:14:46,680 --> 00:14:48,320
the next question is very practical.

320
00:14:48,320 --> 00:14:52,840
What actually happens in order when a vacation request enters the business?

321
00:14:52,840 --> 00:14:56,440
At first glance, this looks almost too simple to map, someone wants time off.

322
00:14:56,440 --> 00:14:59,200
They ask, someone approves, done.

323
00:14:59,200 --> 00:15:03,280
But simple processes often create the most hidden friction, because people assume shared

324
00:15:03,280 --> 00:15:05,640
understanding when none really exists.

325
00:15:05,640 --> 00:15:09,640
And when understanding stays implicit, the work gets pushed into memory, inboxes, and follow

326
00:15:09,640 --> 00:15:10,640
up behavior.

327
00:15:10,640 --> 00:15:12,080
So let's make the path visible.

328
00:15:12,080 --> 00:15:16,320
The event is the employee submitting a request, that is the trigger, not a conversation,

329
00:15:16,320 --> 00:15:20,160
not a draft in someone's notes, not an email chain with five replies and a sounds good to

330
00:15:20,160 --> 00:15:21,160
me.

331
00:15:21,160 --> 00:15:24,800
The actual process starts when the request becomes a record in the system.

332
00:15:24,800 --> 00:15:28,120
Before that you only have intention, after that you have something the business can act

333
00:15:28,120 --> 00:15:29,120
on.

334
00:15:29,120 --> 00:15:33,080
That distinction matters more than it sounds, because if the event is vague, everything

335
00:15:33,080 --> 00:15:35,120
downstream becomes unstable.

336
00:15:35,120 --> 00:15:38,960
Managers respond inconsistently, HR reacts late.

337
00:15:38,960 --> 00:15:41,440
These assume approval when none was formally recorded.

338
00:15:41,440 --> 00:15:45,520
So the first architectural move is to define one clear event boundary.

339
00:15:45,520 --> 00:15:46,880
Submission creates the request.

340
00:15:46,880 --> 00:15:48,960
Then the process enters its first decision layer.

341
00:15:48,960 --> 00:15:51,040
Does the request fit the basic policy structure?

342
00:15:51,040 --> 00:15:54,880
Now for release one, we do not need to automate every policy nuance.

343
00:15:54,880 --> 00:15:57,280
But we do need to know what the decision is trying to answer.

344
00:15:57,280 --> 00:16:01,440
Other dates complete is the employee identified, is the manager relationship available, is

345
00:16:01,440 --> 00:16:04,360
the country context known if policy differs by geography?

346
00:16:04,360 --> 00:16:05,840
These are not advanced rules.

347
00:16:05,840 --> 00:16:07,000
They are entry conditions.

348
00:16:07,000 --> 00:16:11,480
And if the app captures them clearly, the next person in the chain does not need to reconstruct

349
00:16:11,480 --> 00:16:13,680
basic context before making a decision.

350
00:16:13,680 --> 00:16:15,640
Then comes the approval decision itself.

351
00:16:15,640 --> 00:16:19,640
Can the manager approve this request or is delegation needed because that manager is absent?

352
00:16:19,640 --> 00:16:22,880
This is where a lot of teams rush into automation too early.

353
00:16:22,880 --> 00:16:28,520
They want escalation parts, substitutes, reminders, maybe even exception routing on day one.

354
00:16:28,520 --> 00:16:30,560
But the cleaner way to think about it is this.

355
00:16:30,560 --> 00:16:34,520
The request needs to move to the next accountable decision maker without the employee having to

356
00:16:34,520 --> 00:16:35,520
guess who that is.

357
00:16:35,520 --> 00:16:36,760
That is the structural job.

358
00:16:36,760 --> 00:16:41,440
Whether that routing is fully automated now or just made ready in the data model is a maturity

359
00:16:41,440 --> 00:16:43,720
decision, not a reason to muddy the first app.

360
00:16:43,720 --> 00:16:46,360
Once a decision happens, the request changes state.

361
00:16:46,360 --> 00:16:48,600
And state is where process design becomes visible.

362
00:16:48,600 --> 00:16:52,840
For Contoso, we do not need 20 statuses that only creates interpretation that we need

363
00:16:52,840 --> 00:16:58,600
a status model that reflects real movement, submitted, pending approval, approved, rejected,

364
00:16:58,600 --> 00:16:59,600
cancelled.

365
00:16:59,600 --> 00:17:02,800
That is enough for the first operating layer because each state tells the employee, the

366
00:17:02,800 --> 00:17:05,720
manager and HR something materially useful.

367
00:17:05,720 --> 00:17:10,360
It means the request exists, pending approval means ownership, sites with a decision maker,

368
00:17:10,360 --> 00:17:12,600
approved and rejected, closed the decision.

369
00:17:12,600 --> 00:17:16,080
Canceled Reflex change after submission without destroying the audit trail.

370
00:17:16,080 --> 00:17:18,240
This is the thing most people miss.

371
00:17:18,240 --> 00:17:21,040
Status is not decoration, it is shared operational language.

372
00:17:21,040 --> 00:17:23,320
Without it, every participant starts asking side questions.

373
00:17:23,320 --> 00:17:24,320
Did you see it?

374
00:17:24,320 --> 00:17:25,320
Is it still waiting?

375
00:17:25,320 --> 00:17:26,320
Was it declined?

376
00:17:26,320 --> 00:17:27,320
Should I follow up?

377
00:17:27,320 --> 00:17:29,320
Good status design removes those questions before they become behavior.

378
00:17:29,320 --> 00:17:31,720
Now look at the data captured at each point.

379
00:17:31,720 --> 00:17:34,840
At request time, we only need the data required for the next decision.

380
00:17:34,840 --> 00:17:35,680
Start date.

381
00:17:35,680 --> 00:17:36,680
And date.

382
00:17:36,680 --> 00:17:37,680
Reason.

383
00:17:37,680 --> 00:17:38,680
If the business wants it.

384
00:17:38,680 --> 00:17:39,680
Employee identity.

385
00:17:39,680 --> 00:17:40,680
Manager relationship.

386
00:17:40,680 --> 00:17:41,680
Country context.

387
00:17:41,680 --> 00:17:42,680
We're policy differs.

388
00:17:42,680 --> 00:17:44,440
That is enough to create a valid request.

389
00:17:44,440 --> 00:17:47,160
We do not need back office handling fields exposed to the employee.

390
00:17:47,160 --> 00:17:49,440
We do not need every exception input on screen one.

391
00:17:49,440 --> 00:17:52,600
We do not need the app to collect data just in case.

392
00:17:52,600 --> 00:17:55,840
Because every extra field is the process admitting it does not trust its own downstream

393
00:17:55,840 --> 00:17:56,840
structure.

394
00:17:56,840 --> 00:17:58,120
So the cleaner pattern is this.

395
00:17:58,120 --> 00:18:02,000
Capture what the next decision requires and let later automation or operations add

396
00:18:02,000 --> 00:18:04,000
what only becomes relevant after that.

397
00:18:04,000 --> 00:18:07,200
The employee should not carry policy interpretation that belongs in the system.

398
00:18:07,200 --> 00:18:10,320
The manager should not carry routing logic that belongs in structure.

399
00:18:10,320 --> 00:18:14,080
HR should not carry reconstruction work that belongs in status history.

400
00:18:14,080 --> 00:18:18,120
Once the process map is clear at that level, the app decision gets easier because now we

401
00:18:18,120 --> 00:18:21,480
are no longer debating interface style in the abstract.

402
00:18:21,480 --> 00:18:25,560
We are deciding what kind of application best supports this exact operating behavior.

403
00:18:25,560 --> 00:18:26,880
The architectural fork.

404
00:18:26,880 --> 00:18:28,600
Canvas or model driven.

405
00:18:28,600 --> 00:18:30,840
So now we reach the first real fork in the road.

406
00:18:30,840 --> 00:18:33,800
And this is where a lot of teams make a decision far too casually.

407
00:18:33,800 --> 00:18:37,800
They ask which app type is easier or which one looks better or which one they personally

408
00:18:37,800 --> 00:18:39,160
prefer building in.

409
00:18:39,160 --> 00:18:42,480
But that is not the real question because this is not a design-taste issue.

410
00:18:42,480 --> 00:18:44,120
It is an operating model decision.

411
00:18:44,120 --> 00:18:48,320
We are choosing how the business will interact with the structure we just defined and each

412
00:18:48,320 --> 00:18:51,320
app type pushes behavior in a different direction.

413
00:18:51,320 --> 00:18:53,080
Canvas is interaction first.

414
00:18:53,080 --> 00:18:54,600
Model driven is structure first.

415
00:18:54,600 --> 00:18:56,440
That is the cleanest way to hold it in your head.

416
00:18:56,440 --> 00:18:59,160
A canvas app gives us tight control over the experience.

417
00:18:59,160 --> 00:19:01,280
We decide what the employee sees first.

418
00:19:01,280 --> 00:19:06,200
It stays hidden, what action feels obvious, how much context appears on a small mobile screen,

419
00:19:06,200 --> 00:19:08,240
and how narrow we keep the path.

420
00:19:08,240 --> 00:19:12,240
From a business perspective, Canvas is useful when the job is focused, repeated, and simple

421
00:19:12,240 --> 00:19:15,480
enough that adoption rises when friction falls.

422
00:19:15,480 --> 00:19:17,920
A model driven app starts somewhere else entirely.

423
00:19:17,920 --> 00:19:21,720
It assumes the strength of the solution comes from the data model, the relationships, the

424
00:19:21,720 --> 00:19:25,400
forms, the views, and the navigation that dataverse can generate around them.

425
00:19:25,400 --> 00:19:29,120
It is less about shaping every pixel and more about giving people a governed workspace

426
00:19:29,120 --> 00:19:33,040
where records, states, and relationships are visible in a consistent way.

427
00:19:33,040 --> 00:19:36,560
From a business perspective, that matters when users are working across many records, many

428
00:19:36,560 --> 00:19:41,640
filters, many statuses, and need operational oversight more than a tailored front door.

429
00:19:41,640 --> 00:19:43,600
So neither is better in any universal sense.

430
00:19:43,600 --> 00:19:45,720
Each one is optimized for a different job.

431
00:19:45,720 --> 00:19:49,680
That point matters because beginners often choose canvas because it feels friendlier and

432
00:19:49,680 --> 00:19:54,000
experience platform teams often lean toward model driven because it feels more governed.

433
00:19:54,000 --> 00:19:56,960
Both instincts can be right, but both can also miss the structural question.

434
00:19:56,960 --> 00:20:00,160
The decision should come from usage pattern, not familiarity.

435
00:20:00,160 --> 00:20:01,280
Ask three things.

436
00:20:01,280 --> 00:20:02,360
Who is using the app?

437
00:20:02,360 --> 00:20:03,760
How often are they using it?

438
00:20:03,760 --> 00:20:06,960
And how deep is the work they need to do once they are inside?

439
00:20:06,960 --> 00:20:09,760
At Contoso, that changes the conversation immediately.

440
00:20:09,760 --> 00:20:13,720
The employee requesting time off does not need a record management workspace.

441
00:20:13,720 --> 00:20:18,200
They need a clear path, one action, minimal fields, fast confirmation, maybe mobile access

442
00:20:18,200 --> 00:20:22,640
while away from a desk that leans toward canvas because the job is narrow and the value

443
00:20:22,640 --> 00:20:25,720
comes from reducing hesitation at the moment of submission.

444
00:20:25,720 --> 00:20:26,720
But now look at HR.

445
00:20:26,720 --> 00:20:29,000
HR does not just need to submit a request.

446
00:20:29,000 --> 00:20:33,680
HR needs to see patterns across requests filter by status review what is pending, understand

447
00:20:33,680 --> 00:20:37,600
who approved what and eventually manage exceptions and operational follow-up.

448
00:20:37,600 --> 00:20:41,960
That work starts leaning toward model driven because the value comes from visibility across

449
00:20:41,960 --> 00:20:44,880
the data, not from a custom front end moment.

450
00:20:44,880 --> 00:20:48,320
And then there is the manager role, which sits somewhere between the two.

451
00:20:48,320 --> 00:20:52,280
A manager might only need a lightweight approval experience at first, which could live

452
00:20:52,280 --> 00:20:55,360
comfortably in a canvas pattern or later in automation.

453
00:20:55,360 --> 00:20:59,360
But if the manager role expands into broader oversight, team absence planning or delegated

454
00:20:59,360 --> 00:21:04,880
approvals across multiple records, the logic starts shifting toward a more structured workspace.

455
00:21:04,880 --> 00:21:08,000
This is why I would not frame the decision as application type alone.

456
00:21:08,000 --> 00:21:10,000
I would frame it as behavioral fit.

457
00:21:10,000 --> 00:21:13,680
Canvas fits best when you want to shape one path very intentionally.

458
00:21:13,680 --> 00:21:18,120
Model driven fits best when you want dataverse relationships and process visibility to do more

459
00:21:18,120 --> 00:21:19,120
of the work.

460
00:21:19,120 --> 00:21:21,920
There is also a hidden architectural consequence here.

461
00:21:21,920 --> 00:21:25,560
Canvas gives you more freedom, but freedom moves responsibility onto the maker.

462
00:21:25,560 --> 00:21:29,400
You own the screen design, the interaction patterns, the consistency, the responsiveness,

463
00:21:29,400 --> 00:21:31,240
and much more of the logic expression.

464
00:21:31,240 --> 00:21:35,040
That can be exactly right for a strong front door, but it also means inconsistency shows

465
00:21:35,040 --> 00:21:37,560
up faster if scope begins to sprawl.

466
00:21:37,560 --> 00:21:42,400
Model driven gives you less expressive freedom, but in return it gives you more governed scale.

467
00:21:42,400 --> 00:21:46,440
Navigation, views, forms and security alignment come more naturally because the application

468
00:21:46,440 --> 00:21:48,120
grows out of the model itself.

469
00:21:48,120 --> 00:21:51,920
That is powerful when the process is larger than one moment of entry, so if you remember

470
00:21:51,920 --> 00:21:53,960
nothing else, remember this.

471
00:21:53,960 --> 00:21:57,720
Canvas is usually the stronger choice when experience design drives adoption.

472
00:21:57,720 --> 00:22:02,040
Model driven is usually the stronger choice when data relationships drive operational work.

473
00:22:02,040 --> 00:22:04,880
Once you see that, the Contoso path starts to clarify.

474
00:22:04,880 --> 00:22:07,560
They are not really choosing one app for one audience.

475
00:22:07,560 --> 00:22:11,960
They are deciding which kind of experience belongs at the employee front door and which

476
00:22:11,960 --> 00:22:15,080
kind of workspace may later belong behind it.

477
00:22:15,080 --> 00:22:17,000
What canvas changes in the business?

478
00:22:17,000 --> 00:22:20,640
So let's stay with that employee front door because this is where canvas starts to matter

479
00:22:20,640 --> 00:22:21,960
in a very practical way.

480
00:22:21,960 --> 00:22:26,360
A canvas app changes the business by reducing the amount of interpretation the employee has

481
00:22:26,360 --> 00:22:27,680
to do before they act.

482
00:22:27,680 --> 00:22:29,520
That sounds small, but it is not.

483
00:22:29,520 --> 00:22:33,680
In most organizations, the hidden cost of internal processes sits in hesitation.

484
00:22:33,680 --> 00:22:35,240
People are not always blocked by policy.

485
00:22:35,240 --> 00:22:36,680
They are blocked by uncertainty.

486
00:22:36,680 --> 00:22:37,680
Where do I go?

487
00:22:37,680 --> 00:22:38,680
What do I fill in?

488
00:22:38,680 --> 00:22:39,680
Who will see this?

489
00:22:39,680 --> 00:22:42,000
And will this actually move if I submitted here?

490
00:22:42,000 --> 00:22:46,000
A good canvas app removes those questions at the point where they normally slow everything

491
00:22:46,000 --> 00:22:47,000
down.

492
00:22:47,000 --> 00:22:49,760
Why canvas fits the employee side of Contoso so well?

493
00:22:49,760 --> 00:22:53,320
The employee does not need to understand the full leave management architecture.

494
00:22:53,320 --> 00:22:55,240
They do not need relational navigation.

495
00:22:55,240 --> 00:22:58,360
They do not need views across all requests in the organization.

496
00:22:58,360 --> 00:23:02,600
They need one clear action on a screen that feels obvious, fast and low effort.

497
00:23:02,600 --> 00:23:04,680
Canvas lets us shape exactly that experience.

498
00:23:04,680 --> 00:23:07,160
We can make the primary action visible immediately.

499
00:23:07,160 --> 00:23:08,680
We can keep the field set narrow.

500
00:23:08,680 --> 00:23:12,560
We can decide what stays hidden because it belongs to the system and not to the user.

501
00:23:12,560 --> 00:23:14,320
And that changes behavior.

502
00:23:14,320 --> 00:23:19,080
Because once requesting vacation becomes easier than writing the email, people stop improvising.

503
00:23:19,080 --> 00:23:21,920
They stop creating side channels just to avoid friction.

504
00:23:21,920 --> 00:23:25,240
They use the path that gives them the least resistance and now the least resistance is

505
00:23:25,240 --> 00:23:26,520
finally the governed one.

506
00:23:26,520 --> 00:23:27,680
That is the business shift.

507
00:23:27,680 --> 00:23:30,600
Adoption no longer depends on training people into discipline.

508
00:23:30,600 --> 00:23:32,560
It depends on giving them a better route.

509
00:23:32,560 --> 00:23:36,040
This is also why canvas tends to work well in mobile first situations.

510
00:23:36,040 --> 00:23:40,560
If someone is not sitting at a desk all day, the process cannot assume patience for clutter.

511
00:23:40,560 --> 00:23:44,120
They cannot assume the employee will navigate a dense workspace just to ask for time

512
00:23:44,120 --> 00:23:45,440
off next month.

513
00:23:45,440 --> 00:23:48,200
The canvas app can be shaped around short interactions.

514
00:23:48,200 --> 00:23:51,800
Open, enter dates, add reasons, submit, check status, done.

515
00:23:51,800 --> 00:23:55,680
From a system perspective, that reduction in interaction cost improves data quality because

516
00:23:55,680 --> 00:23:59,840
people are more likely to complete the request properly when the path feels contained.

517
00:23:59,840 --> 00:24:03,120
But canvas does something else that leaders often underestimate.

518
00:24:03,120 --> 00:24:04,640
It lowers the training burden.

519
00:24:04,640 --> 00:24:06,880
That matters a lot in first releases.

520
00:24:06,880 --> 00:24:11,000
Because every extra explanation you need before someone can complete a basic request is

521
00:24:11,000 --> 00:24:14,840
evidence that the interface is carrying too much complexity.

522
00:24:14,840 --> 00:24:17,840
A canvas app lets us design for familiarity instead.

523
00:24:17,840 --> 00:24:21,280
One obvious button, plain labels, direct feedback after submission.

524
00:24:21,280 --> 00:24:24,120
The employee should not need a walkthrough for something this routine.

525
00:24:24,120 --> 00:24:27,400
If they do, the business has hidden complexity in the wrong place.

526
00:24:27,400 --> 00:24:30,080
Now there is a trade-off and it is worth saying clearly.

527
00:24:30,080 --> 00:24:33,000
Canvas gives us control but control creates responsibility.

528
00:24:33,000 --> 00:24:37,600
The platform will not save us from inconsistent screens, unclear navigation, weak responsiveness

529
00:24:37,600 --> 00:24:41,120
or bloated logic if we start stuffing too much into the app.

530
00:24:41,120 --> 00:24:43,600
That freedom is useful when the scope stays narrow.

531
00:24:43,600 --> 00:24:46,800
It becomes dangerous when the app starts absorbing every future idea.

532
00:24:46,800 --> 00:24:51,360
Then the clean front door turns into a custom-built maze and maintenance gets heavier with every

533
00:24:51,360 --> 00:24:52,360
addition.

534
00:24:52,360 --> 00:24:55,040
So the strength of canvas at Contoso is not that it can do anything.

535
00:24:55,040 --> 00:24:58,320
The strength is that we should ask it to do one thing very well.

536
00:24:58,320 --> 00:25:01,080
Create the best possible request experience for employees.

537
00:25:01,080 --> 00:25:04,240
That means the app should focus on speed, clarity and trust.

538
00:25:04,240 --> 00:25:09,120
It should help the employee enter valid information without carrying policy complexity in their head.

539
00:25:09,120 --> 00:25:11,520
It should confirm that the request exists.

540
00:25:11,520 --> 00:25:15,880
And it should expose status in a way that stops people from falling back into inbox chasing.

541
00:25:15,880 --> 00:25:17,600
That is what canvas changes in the business.

542
00:25:17,600 --> 00:25:19,360
It does not just create a nicer form.

543
00:25:19,360 --> 00:25:22,160
It changes the entry behavior of the organization.

544
00:25:22,160 --> 00:25:23,560
Request start clean.

545
00:25:23,560 --> 00:25:24,560
Status starts visible.

546
00:25:24,560 --> 00:25:27,800
Adoption rises because the process feels simpler than the workaround.

547
00:25:27,800 --> 00:25:32,120
But once you move from front door to operational workspace, a different logic starts to matter.

548
00:25:32,120 --> 00:25:34,200
What model driven changes in the business?

549
00:25:34,200 --> 00:25:38,520
So now let's move to the other side of the architecture because once the request is inside the system,

550
00:25:38,520 --> 00:25:40,360
the business needs starts changing.

551
00:25:40,360 --> 00:25:41,960
The employee needed a front door.

552
00:25:41,960 --> 00:25:44,000
HR and operations need a workspace.

553
00:25:44,000 --> 00:25:46,360
And this is where model driven starts to make much more sense.

554
00:25:46,360 --> 00:25:51,040
A model driven app changes the business by making the data model itself operationally useful.

555
00:25:51,040 --> 00:25:54,880
Instead of shaping every screen by hand, we let dataverse relationships, views, forms

556
00:25:54,880 --> 00:25:57,400
and security do more of the heavy lifting.

557
00:25:57,400 --> 00:26:01,920
That matters when the real job is no longer help one person submit one request but help

558
00:26:01,920 --> 00:26:07,160
a role work across many requests, many states and many decision points without losing visibility.

559
00:26:07,160 --> 00:26:08,880
That is a different class of work.

560
00:26:08,880 --> 00:26:10,200
Think about HR at Contoso.

561
00:26:10,200 --> 00:26:13,400
HR is not interacting with one record at a time in isolation.

562
00:26:13,400 --> 00:26:17,640
HR needs to filter pending requests, review approvals by country, understand where delegation

563
00:26:17,640 --> 00:26:20,640
applies and eventually spot where work is starting to stall.

564
00:26:20,640 --> 00:26:22,520
That is not a single interaction moment.

565
00:26:22,520 --> 00:26:24,000
That is an operational surface.

566
00:26:24,000 --> 00:26:28,720
And model driven is strong precisely because it turns structured data into a governed environment

567
00:26:28,720 --> 00:26:29,960
for that kind of oversight.

568
00:26:29,960 --> 00:26:34,240
The benefit shows up fast, you get consistent navigation across related records, you get views

569
00:26:34,240 --> 00:26:37,480
that let teams work by status, owner or geography.

570
00:26:37,480 --> 00:26:41,040
You get forms generated from the model instead of custom building every path.

571
00:26:41,040 --> 00:26:44,840
And you get security that sits naturally inside the dataverse structure instead of being

572
00:26:44,840 --> 00:26:47,560
expressed mainly through interface design.

573
00:26:47,560 --> 00:26:51,760
From a business perspective, that means scale arrives with less improvisation.

574
00:26:51,760 --> 00:26:55,400
Now that does not mean model driven is automatically better for everyone.

575
00:26:55,400 --> 00:27:00,560
It means it is better when the process extends beyond one form and into ongoing operational

576
00:27:00,560 --> 00:27:01,560
work.

577
00:27:01,560 --> 00:27:06,240
The people inside HR do not just need simplicity, they need control, visibility and repeatability.

578
00:27:06,240 --> 00:27:10,000
They need to know that two people looking at the same request are seeing the same governed

579
00:27:10,000 --> 00:27:14,840
record, not two slightly different interpretations of a custom app experience that consistency

580
00:27:14,840 --> 00:27:16,680
matters more than people realize.

581
00:27:16,680 --> 00:27:20,440
Because once the number of requests grows, trust starts depending on whether the process

582
00:27:20,440 --> 00:27:22,200
behaves the same way for every record.

583
00:27:22,200 --> 00:27:25,920
A manager may tolerate some interface variation in a lightweight employee app.

584
00:27:25,920 --> 00:27:29,800
HR will not tolerate variation in the operational workspace for long.

585
00:27:29,800 --> 00:27:34,440
They need stable views, predictable fields and filters that let them move from what happened

586
00:27:34,440 --> 00:27:39,560
here to show me every request pending approval in Germany with a manager currently absent.

587
00:27:39,560 --> 00:27:42,360
That is exactly where model driven begins to earn its place.

588
00:27:42,360 --> 00:27:46,800
There is also a structural advantage that becomes more important as the process matures.

589
00:27:46,800 --> 00:27:50,560
Model driven apps are naturally closer to governance, not in some abstract compliance

590
00:27:50,560 --> 00:27:55,080
sense, but in the everyday reality of who can see what, who can update which records and

591
00:27:55,080 --> 00:27:59,160
how process behavior stays aligned to dataverse roles and relationships.

592
00:27:59,160 --> 00:28:03,480
That makes auditability feel less like an add-on and more like a byproduct of the architecture,

593
00:28:03,480 --> 00:28:05,480
and that is a big deal for business operations.

594
00:28:05,480 --> 00:28:09,720
Because once leave data becomes part of planning, staffing and accountability, visibility

595
00:28:09,720 --> 00:28:11,280
is no longer a convenience.

596
00:28:11,280 --> 00:28:12,880
It becomes a management requirement.

597
00:28:12,880 --> 00:28:15,440
Leaders want to know if approvals are sitting too long.

598
00:28:15,440 --> 00:28:19,640
HR wants to see whether one country is handling requests differently from another.

599
00:28:19,640 --> 00:28:23,760
Modulation needs to be visible enough that absence does not create a silent bottleneck.

600
00:28:23,760 --> 00:28:28,480
A model driven app supports that kind of operating reality much more naturally than a highly custom

601
00:28:28,480 --> 00:28:30,400
front and trying to do everything itself.

602
00:28:30,400 --> 00:28:31,760
There is a trade-off here too.

603
00:28:31,760 --> 00:28:35,880
Model driven gives you strength through structure, but it gives you less freedom in how the experience

604
00:28:35,880 --> 00:28:36,880
feels.

605
00:28:36,880 --> 00:28:41,080
You are accepting a more standardized interaction pattern in exchange for a more governed

606
00:28:41,080 --> 00:28:42,480
and scalable workspace.

607
00:28:42,480 --> 00:28:46,960
For employees that can feel heavier than necessary, for operations that heaviness is often exactly

608
00:28:46,960 --> 00:28:48,920
what keeps the process coherent.

609
00:28:48,920 --> 00:28:53,000
So if Canvas helps the business by making entry easier, model driven helps the business by

610
00:28:53,000 --> 00:28:54,600
making oversight stronger.

611
00:28:54,600 --> 00:28:58,360
It turns the dataverse model into something people can actually work through at scale, and

612
00:28:58,360 --> 00:29:02,800
it does that without asking the maker to custom build every piece of operational logic into

613
00:29:02,800 --> 00:29:03,800
the interface.

614
00:29:03,800 --> 00:29:06,400
So Contoso does not really have one user group.

615
00:29:06,400 --> 00:29:10,360
It has one process with different depths of work, which means the app answer may not be

616
00:29:10,360 --> 00:29:11,960
singular at all.

617
00:29:11,960 --> 00:29:15,200
The Contoso decision, one problem, two experiences.

618
00:29:15,200 --> 00:29:18,000
So this is the point where Contoso stops asking the wrong question.

619
00:29:18,000 --> 00:29:20,280
The wrong question is which app type should we pick?

620
00:29:20,280 --> 00:29:24,640
The better question is which experience belongs to which kind of work, because once we separate

621
00:29:24,640 --> 00:29:28,480
the employee moment from the operational moment, the architecture stops feeling like

622
00:29:28,480 --> 00:29:32,040
a platform debate and starts feeling like a business design choice.

623
00:29:32,040 --> 00:29:36,800
At Contoso, the employee experience needs three things above all else, simplicity, speed,

624
00:29:36,800 --> 00:29:37,800
and confidence.

625
00:29:37,800 --> 00:29:41,640
The employee should be able to open the app, understand the action immediately, enter only

626
00:29:41,640 --> 00:29:45,560
what the next decision requires and submit without wondering whether they use the right

627
00:29:45,560 --> 00:29:46,560
process.

628
00:29:46,560 --> 00:29:48,120
That is the front door problem.

629
00:29:48,120 --> 00:29:52,080
And Canvas is usually the cleaner answer there because it lets us strip the experience

630
00:29:52,080 --> 00:29:56,800
down to one focused task without dragging the user through the full shape of the underlying

631
00:29:56,800 --> 00:29:57,800
model.

632
00:29:57,800 --> 00:29:59,760
But that is only half of the picture.

633
00:29:59,760 --> 00:30:01,680
Managers in HR are not just entering data.

634
00:30:01,680 --> 00:30:03,040
They are working across requests.

635
00:30:03,040 --> 00:30:07,080
They meet visibility, filtering, context, and the ability to operate on records with some

636
00:30:07,080 --> 00:30:08,080
consistency.

637
00:30:08,080 --> 00:30:12,600
HR especially needs a surface where status, employee relationships, country context, and

638
00:30:12,600 --> 00:30:17,320
approval history can be reviewed without custom building every operational behavior into a separate

639
00:30:17,320 --> 00:30:18,320
screen.

640
00:30:18,320 --> 00:30:20,760
That is where model driven starts to make more sense.

641
00:30:20,760 --> 00:30:24,320
Not because it is more advanced, but because it is better aligned to the depth of work those

642
00:30:24,320 --> 00:30:25,320
roles are doing.

643
00:30:25,320 --> 00:30:29,000
So, the Contoso answer is not one app trying to be everything for everyone.

644
00:30:29,000 --> 00:30:32,280
It is one problem expressed through two different experiences.

645
00:30:32,280 --> 00:30:36,320
That distinction matters because when teams force all roles into one interface, they usually

646
00:30:36,320 --> 00:30:37,520
compromise both ends.

647
00:30:37,520 --> 00:30:41,520
The employee app becomes too heavy because it carries operational complexity.

648
00:30:41,520 --> 00:30:45,280
The HR workspace becomes too shallow because it was simplified for casual users.

649
00:30:45,280 --> 00:30:49,720
The result is a single artifact that satisfies nobody particularly well, and the business

650
00:30:49,720 --> 00:30:54,440
then concludes the process itself is awkward when the real issue was architectural blending.

651
00:30:54,440 --> 00:30:57,520
From a system perspective, this is a separation of concerns problem.

652
00:30:57,520 --> 00:31:00,000
The employee interaction is optimized for low friction.

653
00:31:00,000 --> 00:31:02,760
The operational interaction is optimized for control and visibility.

654
00:31:02,760 --> 00:31:06,040
Those are not the same design goals and they should not be forced into the same shape

655
00:31:06,040 --> 00:31:07,040
too early.

656
00:31:07,040 --> 00:31:10,800
So, for release one, I would recommend a clear front door decision.

657
00:31:10,800 --> 00:31:15,440
Canvas for the employee request experience, that gives Contoso the fastest path to the

658
00:31:15,440 --> 00:31:19,040
first value moment, which is not full leave management maturity.

659
00:31:19,040 --> 00:31:21,000
It is much simpler than that.

660
00:31:21,000 --> 00:31:25,160
An employee can submit a valid request through a governed path and then see that the request

661
00:31:25,160 --> 00:31:30,000
exists, has a status and is now inside a process the organization can trust.

662
00:31:30,000 --> 00:31:31,000
That is the breakthrough.

663
00:31:31,000 --> 00:31:34,800
Once that happens, cycle time starts dropping because the request no longer enters through

664
00:31:34,800 --> 00:31:36,800
scattered messages and private memory.

665
00:31:36,800 --> 00:31:39,240
Now, does that mean model driven disappears from the story?

666
00:31:39,240 --> 00:31:40,240
Not at all.

667
00:31:40,240 --> 00:31:44,400
And model driven is more likely the operational layer that grows with maturity rather than

668
00:31:44,400 --> 00:31:47,400
the first experience we push in front of every employee.

669
00:31:47,400 --> 00:31:52,600
As Contoso expands the process as HR needs stronger oversight, as delegation reporting and broader

670
00:31:52,600 --> 00:31:55,000
exception handling become more active concerns.

671
00:31:55,000 --> 00:31:57,200
The structured workspace becomes more relevant.

672
00:31:57,200 --> 00:32:00,840
And because the data model already lives in dataverse, that path stays open.

673
00:32:00,840 --> 00:32:02,560
That is the quiet strength of this decision.

674
00:32:02,560 --> 00:32:05,040
We are not choosing canvas instead of architecture.

675
00:32:05,040 --> 00:32:10,120
We are choosing canvas as the right first expression of architecture for the employee side.

676
00:32:10,120 --> 00:32:13,960
And that should calm a lot of unnecessary anxiety because some teams here hybrid and immediately

677
00:32:13,960 --> 00:32:15,200
start over building.

678
00:32:15,200 --> 00:32:20,280
They imagine they need two complete apps, full automation, all approval branches and future

679
00:32:20,280 --> 00:32:21,480
reporting in version one.

680
00:32:21,480 --> 00:32:22,480
They do not.

681
00:32:22,480 --> 00:32:25,200
What they need is the first point of value clearly defined.

682
00:32:25,200 --> 00:32:28,360
For Contoso, that point is request submission and status visibility.

683
00:32:28,360 --> 00:32:30,040
Everything else can mature in sequence.

684
00:32:30,040 --> 00:32:33,320
So the real decision is not canvas or model driven in isolation.

685
00:32:33,320 --> 00:32:34,320
It is this.

686
00:32:34,320 --> 00:32:38,120
Use canvas, where adoption depends on a better front door and leave room for model driven

687
00:32:38,120 --> 00:32:41,360
where the business later needs a stronger operational workspace.

688
00:32:41,360 --> 00:32:44,960
That is a very different mindset and it keeps version one honest.

689
00:32:44,960 --> 00:32:47,000
Scope the first release like an architect.

690
00:32:47,000 --> 00:32:50,000
So now we do the part that separates momentum from mess.

691
00:32:50,000 --> 00:32:51,720
We cut scope.

692
00:32:51,720 --> 00:32:56,040
Not because we lack ambition and not because the platform cannot do more, but because version

693
00:32:56,040 --> 00:32:57,600
one has one job.

694
00:32:57,600 --> 00:33:01,440
Prove the process can move faster through a controlled path without creating hidden cost

695
00:33:01,440 --> 00:33:02,920
underneath.

696
00:33:02,920 --> 00:33:07,040
If we forget that, the first release turns into a dumping ground for future ideas and

697
00:33:07,040 --> 00:33:10,280
the architecture loses its center before the business trusts it.

698
00:33:10,280 --> 00:33:14,560
At Contoso, release one should include only what the first value moment depends on.

699
00:33:14,560 --> 00:33:16,560
The employee can create a vacation request.

700
00:33:16,560 --> 00:33:19,240
The request is written to dataverse with the right core fields.

701
00:33:19,240 --> 00:33:20,920
The request has a visible status.

702
00:33:20,920 --> 00:33:23,400
The manager relationship is captured.

703
00:33:23,400 --> 00:33:25,240
And the data model is ready for delegation.

704
00:33:25,240 --> 00:33:29,640
Even if delegation handling is not fully automated yet, that last point matters.

705
00:33:29,640 --> 00:33:32,920
Being ready for delegation is not the same as building the entire delegation engine

706
00:33:32,920 --> 00:33:33,920
now.

707
00:33:33,920 --> 00:33:38,040
In the other relationship, we can make the structure aware that a manager may have a delegate,

708
00:33:38,040 --> 00:33:42,880
but we do not need to build every routing branch, notification path or fallback rule into

709
00:33:42,880 --> 00:33:43,880
release one.

710
00:33:43,880 --> 00:33:46,880
That would be future capability pretending to be current necessity.

711
00:33:46,880 --> 00:33:48,920
The same logic applies to country policy.

712
00:33:48,920 --> 00:33:50,600
Contoso has multiple countries.

713
00:33:50,600 --> 00:33:51,600
Policies differ.

714
00:33:51,600 --> 00:33:52,600
Everyone knows that.

715
00:33:52,600 --> 00:33:56,400
But version one does not need to automate every country rule at the point of submission.

716
00:33:56,400 --> 00:33:59,480
What it does need is structured country context in the data.

717
00:33:59,480 --> 00:34:03,280
So later decisions reporting and automation have something reliable to work with.

718
00:34:03,280 --> 00:34:04,680
What is how architects think?

719
00:34:04,680 --> 00:34:05,960
We do not ignore complexity.

720
00:34:05,960 --> 00:34:07,800
We place it where it belongs in sequence.

721
00:34:07,800 --> 00:34:09,480
So what stays out of release one?

722
00:34:09,480 --> 00:34:11,200
Advanced routing stays out.

723
00:34:11,200 --> 00:34:12,480
Escalation stay out.

724
00:34:12,480 --> 00:34:14,240
Reminder logic stays out.

725
00:34:14,240 --> 00:34:15,840
Complex exception workflows stay out.

726
00:34:15,840 --> 00:34:17,320
Heavy notifications stay out.

727
00:34:17,320 --> 00:34:19,240
Full policy automation stays out.

728
00:34:19,240 --> 00:34:20,240
And why is that?

729
00:34:20,240 --> 00:34:22,760
Because those things do create value, but they create secondary value.

730
00:34:22,760 --> 00:34:25,960
The primary value is clean entry, clean status and visible ownership.

731
00:34:25,960 --> 00:34:29,000
If we win their first, the organization feels the change immediately.

732
00:34:29,000 --> 00:34:33,120
If we chase completeness first, the team spends energy on branches before the main path

733
00:34:33,120 --> 00:34:34,120
has even earned trust.

734
00:34:34,120 --> 00:34:36,280
This is the part many teams resist.

735
00:34:36,280 --> 00:34:38,640
Because scoping small can feel like underbuilding.

736
00:34:38,640 --> 00:34:41,720
It can feel as if we are leaving obvious opportunities on the table.

737
00:34:41,720 --> 00:34:45,920
But that feeling usually comes from confusing architectural readiness with feature volume.

738
00:34:45,920 --> 00:34:48,640
A good first release is not the one with the most moving parts.

739
00:34:48,640 --> 00:34:53,080
It is the one that creates the clearest shift in operating behavior with the fewest assumptions.

740
00:34:53,080 --> 00:34:55,520
That also protects us from licensing surprises.

741
00:34:55,520 --> 00:35:00,680
The more integrations, connectors and orchestration ideas we drag into version one, the more

742
00:35:00,680 --> 00:35:04,980
likely we turn the straightforward app into a more expensive service pattern than the business

743
00:35:04,980 --> 00:35:05,980
expected.

744
00:35:05,980 --> 00:35:09,320
The first release should buy options, not consume them recklessly.

745
00:35:09,320 --> 00:35:11,200
Keep the architecture clean now.

746
00:35:11,200 --> 00:35:15,720
And you preserve room to automate later, without discovering that a small design flourish

747
00:35:15,720 --> 00:35:17,880
quietly change the cost model.

748
00:35:17,880 --> 00:35:19,200
It also protects governance.

749
00:35:19,200 --> 00:35:24,080
A tightly scoped first release is easier to place in the right environment, easier to test,

750
00:35:24,080 --> 00:35:26,040
easier to secure and easier to explain.

751
00:35:26,040 --> 00:35:28,520
The people inside the system know what it does.

752
00:35:28,520 --> 00:35:29,840
Support knows what to expect.

753
00:35:29,840 --> 00:35:34,220
You can see the point of the release, without needing a maturity map and a three layer process

754
00:35:34,220 --> 00:35:36,780
diagram just to understand what shipped.

755
00:35:36,780 --> 00:35:40,880
So if I were scoping Contoso's first release as an architect, I would state it plainly.

756
00:35:40,880 --> 00:35:46,160
One employee entry path, one request record, one shared status model, one visible owner

757
00:35:46,160 --> 00:35:51,760
for the next decision, delegation readiness in the data, country context, captured structurally.

758
00:35:51,760 --> 00:35:55,960
Everything else waits until the first behavior change is real because maturity does not come

759
00:35:55,960 --> 00:35:57,800
from stuffing the future into version one.

760
00:35:57,800 --> 00:35:59,180
It comes from sequence.

761
00:35:59,180 --> 00:36:04,680
And once scope is under control, we can finally design the employee experience from first principles.

762
00:36:04,680 --> 00:36:07,320
Design the employee experience from first principles.

763
00:36:07,320 --> 00:36:11,320
So now we design the part people actually feel, not the table, not the relationship map,

764
00:36:11,320 --> 00:36:15,000
not the future approval engine, the employee experience.

765
00:36:15,000 --> 00:36:17,520
And the cleanest place to start is not with controls.

766
00:36:17,520 --> 00:36:20,000
It is with the human moment that triggers the process.

767
00:36:20,000 --> 00:36:22,160
At Contoso, that moment is very ordinary.

768
00:36:22,160 --> 00:36:26,440
Someone needs time off, maybe for family, travel, recovery or just a break and they want

769
00:36:26,440 --> 00:36:27,440
two things immediately.

770
00:36:27,440 --> 00:36:29,240
Clarity and confidence.

771
00:36:29,240 --> 00:36:30,560
Clarity about what to do.

772
00:36:30,560 --> 00:36:34,280
Confidence that the request will not vanish into informal manager memory.

773
00:36:34,280 --> 00:36:38,280
If we keep that moment in view, the app becomes much easier to design because now we are not

774
00:36:38,280 --> 00:36:39,760
asking what can the platform show?

775
00:36:39,760 --> 00:36:43,800
We are asking, what does this person need to do with the least friction and the lowest

776
00:36:43,800 --> 00:36:44,800
chance of error?

777
00:36:44,800 --> 00:36:46,320
That question strips away a lot of noise.

778
00:36:46,320 --> 00:36:49,600
It tells us the screen should not feel like HR software.

779
00:36:49,600 --> 00:36:53,120
It should feel like a simple act of intent entering a reliable system.

780
00:36:53,120 --> 00:36:56,160
That means the field set stays minimal, start date, end date.

781
00:36:56,160 --> 00:37:00,160
And the reason if Contoso wants a short explanation and country context only where it is truly

782
00:37:00,160 --> 00:37:01,640
needed or already known.

783
00:37:01,640 --> 00:37:03,440
That is enough for the next decision.

784
00:37:03,440 --> 00:37:05,640
Everything else needs to justify its existence.

785
00:37:05,640 --> 00:37:10,520
If a field does not help validate the request now or move it to the next accountable person,

786
00:37:10,520 --> 00:37:12,920
it probably does not belong in front of the employee.

787
00:37:12,920 --> 00:37:17,400
This is where many apps start carrying back office uncertainty on the user's back.

788
00:37:17,400 --> 00:37:21,960
Teams add extra inputs because someone downstream might want them later, but every extra field

789
00:37:21,960 --> 00:37:24,760
is usually structural compensation for a week process.

790
00:37:24,760 --> 00:37:28,640
If the system is well-shaped, the employee should not have to fill gaps that the architecture

791
00:37:28,640 --> 00:37:29,640
should already know.

792
00:37:29,640 --> 00:37:32,400
The manager relationship should come from the data model.

793
00:37:32,400 --> 00:37:34,560
Basic employee identity should already be known.

794
00:37:34,560 --> 00:37:36,320
Country should be inferred where possible.

795
00:37:36,320 --> 00:37:40,200
Status should be created by the process, not typed by the request that is how you reduce

796
00:37:40,200 --> 00:37:41,200
cognitive load.

797
00:37:41,200 --> 00:37:44,320
And cognitive load matters more than people think because internal business apps fail

798
00:37:44,320 --> 00:37:45,320
quietly.

799
00:37:45,320 --> 00:37:46,320
The employee may not complain.

800
00:37:46,320 --> 00:37:50,920
They just delay using it, ask a manager in chat instead or submit incomplete information

801
00:37:50,920 --> 00:37:54,520
because the interface asks them to think harder than the old workaround.

802
00:37:54,520 --> 00:37:57,960
The good design is not about visual polish, it is about lowering the cost of doing the

803
00:37:57,960 --> 00:37:58,960
right thing.

804
00:37:58,960 --> 00:38:02,920
There is another part that belongs in the first principles view and that is immediate feedback.

805
00:38:02,920 --> 00:38:06,560
The moment a request is submitted, the employee should know three things.

806
00:38:06,560 --> 00:38:11,520
The request was captured, its current status, and who owns the next decision that tiny loop

807
00:38:11,520 --> 00:38:15,840
changes trust fast because once people can see that the process has accepted their intent

808
00:38:15,840 --> 00:38:20,000
and attached visible ownership to it, they stop treating the request like a social favor

809
00:38:20,000 --> 00:38:22,920
and start treating it like a real operating flow.

810
00:38:22,920 --> 00:38:27,120
This is where the app begins to shift culture without announcing that it is doing so.

811
00:38:27,120 --> 00:38:29,520
Now what should stay out of the employee experience?

812
00:38:29,520 --> 00:38:31,320
Anything that belongs to back office handling?

813
00:38:31,320 --> 00:38:35,440
Approval routing details stays out, operational comments stay out, exception management stays

814
00:38:35,440 --> 00:38:36,440
out.

815
00:38:36,440 --> 00:38:37,720
Administrative override logic stays out.

816
00:38:37,720 --> 00:38:40,920
Not because those things are unimportant, but because they belong to other roles and

817
00:38:40,920 --> 00:38:42,400
later moments in the process.

818
00:38:42,400 --> 00:38:47,640
If we expose them too early, the employee interface starts leaking internal complexity.

819
00:38:47,640 --> 00:38:51,440
Then the front door stops being a front door and starts becoming a badly compressed view

820
00:38:51,440 --> 00:38:55,520
of the entire system and that is exactly what we are trying to avoid.

821
00:38:55,520 --> 00:38:57,720
So the design principle is simple.

822
00:38:57,720 --> 00:39:01,360
Make the next action obvious, keep the mental load low and let the structure carry what

823
00:39:01,360 --> 00:39:02,880
the user should not have to carry.

824
00:39:02,880 --> 00:39:07,640
In practice that means short paths, plain language, few choices and visible confirmation.

825
00:39:07,640 --> 00:39:10,720
The app should feel almost boring and boring is good here.

826
00:39:10,720 --> 00:39:14,640
Boring means predictable, predictable means trusted, trusted means used.

827
00:39:14,640 --> 00:39:18,760
And once that happens, the request path stops depending on memory, email threads and good

828
00:39:18,760 --> 00:39:23,120
intentions because the system finally gives the employee a front door that feels easier

829
00:39:23,120 --> 00:39:25,000
than the workaround.

830
00:39:25,000 --> 00:39:27,400
Walk through the first screen in plain language.

831
00:39:27,400 --> 00:39:31,080
So because this is audio, let me describe the first screen the way a user would actually

832
00:39:31,080 --> 00:39:33,960
experience it, not the way makers usually talk about it.

833
00:39:33,960 --> 00:39:39,000
An employee opens the app and the first thing they see is one obvious action, request vacation,

834
00:39:39,000 --> 00:39:43,200
not five tiles, not a busy dashboard pretending every option matters equally.

835
00:39:43,200 --> 00:39:46,800
Just a clean front door with a clear primary action because the app should answer the user's

836
00:39:46,800 --> 00:39:48,560
first silent question immediately.

837
00:39:48,560 --> 00:39:50,440
Am I in the right place to do this?

838
00:39:50,440 --> 00:39:51,880
That matters more than people think.

839
00:39:51,880 --> 00:39:56,720
If the first screen asks the employee to interpret where to begin, the process has already

840
00:39:56,720 --> 00:39:58,560
reintroduced friction.

841
00:39:58,560 --> 00:40:02,640
We are trying to reduce decision cost, not relocated, so the page should feel calm.

842
00:40:02,640 --> 00:40:04,760
The title tells them what the app is for.

843
00:40:04,760 --> 00:40:07,600
The main button or form area tells them what to do next.

844
00:40:07,600 --> 00:40:12,840
And around that, only enough supporting context appears to build confidence, not clutter.

845
00:40:12,840 --> 00:40:16,040
Once they choose to request vacation, the interactions stay short.

846
00:40:16,040 --> 00:40:20,840
They enter a start date, they enter an end date, they add a reason if contoso wants one.

847
00:40:20,840 --> 00:40:24,760
And they can see without hunting, which manage a relationship the system is using for the

848
00:40:24,760 --> 00:40:25,760
request.

849
00:40:25,760 --> 00:40:29,160
That last point is useful because it removes a common hesitation.

850
00:40:29,160 --> 00:40:33,080
People often want quiet confirmation that the request is going to the right person.

851
00:40:33,080 --> 00:40:35,920
They should not have to remember who sits where in the approval chain.

852
00:40:35,920 --> 00:40:38,480
The app should already know enough to make that visible.

853
00:40:38,480 --> 00:40:40,040
Now notice what is not happening.

854
00:40:40,040 --> 00:40:42,360
The employee is not picking workflow branches.

855
00:40:42,360 --> 00:40:44,080
They are not deciding policy logic.

856
00:40:44,080 --> 00:40:46,720
They are not filling in operational metadata for HR.

857
00:40:46,720 --> 00:40:49,280
They are not choosing from fields that only matter later.

858
00:40:49,280 --> 00:40:53,000
The screen is intentionally narrow because every unnecessary choice introduces the chance

859
00:40:53,000 --> 00:40:54,920
of pause, error or abandonment.

860
00:40:54,920 --> 00:40:58,520
Then for a first app, that is the risk we are actively designing against.

861
00:40:58,520 --> 00:41:02,360
Then comes the submit moment and this is where the experience has to feel concrete.

862
00:41:02,360 --> 00:41:06,680
When the employee taps submit, the system writes the request to dataverse immediately.

863
00:41:06,680 --> 00:41:09,320
No attachment chain starts, no one needs to forward an email.

864
00:41:09,320 --> 00:41:13,280
No hidden mailbox rule catches the message and dumps it somewhere opaque.

865
00:41:13,280 --> 00:41:16,080
A structured record is created in the system of record.

866
00:41:16,080 --> 00:41:17,760
The moment intent becomes formal.

867
00:41:17,760 --> 00:41:20,680
That is a very different operating event from sending an email.

868
00:41:20,680 --> 00:41:23,120
With email, the employee hopes the process begins.

869
00:41:23,120 --> 00:41:24,880
With the app, the process begins.

870
00:41:24,880 --> 00:41:28,960
And because the process begins at record creation, the next screen or confirmation state

871
00:41:28,960 --> 00:41:31,560
should show that back to the user in plain language.

872
00:41:31,560 --> 00:41:32,560
Something simple.

873
00:41:32,560 --> 00:41:33,880
Request submitted.

874
00:41:33,880 --> 00:41:34,880
Status.

875
00:41:34,880 --> 00:41:36,320
Submitted or pending approval.

876
00:41:36,320 --> 00:41:38,920
Depending on how contoso labels the first visible state.

877
00:41:38,920 --> 00:41:39,920
Next decision owner.

878
00:41:39,920 --> 00:41:40,920
Manager name.

879
00:41:40,920 --> 00:41:42,120
If that is appropriate to expose.

880
00:41:42,120 --> 00:41:43,920
The point is not decorative feedback.

881
00:41:43,920 --> 00:41:47,120
The point is to show that the request now exists inside a governed flow.

882
00:41:47,120 --> 00:41:49,200
That feedback loop changes trust fast.

883
00:41:49,200 --> 00:41:52,200
The employee no longer wonders whether the request got lost.

884
00:41:52,200 --> 00:41:54,360
They no longer need to screenshot a team's message.

885
00:41:54,360 --> 00:41:58,520
They no longer need a second message that says, "Just checking if you saw my leave request."

886
00:41:58,520 --> 00:42:03,640
The app has reduced ambiguity at the exact point where ambiguity used to create extra work.

887
00:42:03,640 --> 00:42:07,040
And when they return to the home view, they should be able to see recent requests with

888
00:42:07,040 --> 00:42:08,440
their current statuses.

889
00:42:08,440 --> 00:42:10,600
Not a giant case management console.

890
00:42:10,600 --> 00:42:13,160
It's enough history to answer the natural follow-up question.

891
00:42:13,160 --> 00:42:14,520
What happened to my last request?

892
00:42:14,520 --> 00:42:16,080
And where does this one stand now?

893
00:42:16,080 --> 00:42:18,800
That simple visibility starts retraining behavior.

894
00:42:18,800 --> 00:42:22,280
Because the employee learns that status lives in the system, not in social memory.

895
00:42:22,280 --> 00:42:26,560
This is why I keep saying simple interface design is really process design made visible.

896
00:42:26,560 --> 00:42:30,920
What looks like a basic first screen is actually carrying several architectural decisions at once.

897
00:42:30,920 --> 00:42:32,200
One governed entry point.

898
00:42:32,200 --> 00:42:33,880
One immediate right to that averse.

899
00:42:33,880 --> 00:42:35,200
One visible status loop.

900
00:42:35,200 --> 00:42:37,440
One reduction in inbox dependency.

901
00:42:37,440 --> 00:42:41,160
From a business perspective, that is already a meaningful shift because the organization has

902
00:42:41,160 --> 00:42:45,880
moved from informal request handling to structured request intake without asking the employee

903
00:42:45,880 --> 00:42:48,400
to absorb the full complexity underneath.

904
00:42:48,400 --> 00:42:50,160
That is the mark of a good first screen.

905
00:42:50,160 --> 00:42:54,800
It feels light to the user because the architecture is carrying the weight for them.

906
00:42:54,800 --> 00:42:57,200
What dataverse is doing underneath the app.

907
00:42:57,200 --> 00:43:01,800
Now let's step below the screen because once the employee taps submit, the visible experience

908
00:43:01,800 --> 00:43:05,280
ends for them, but the structural work is only just beginning.

909
00:43:05,280 --> 00:43:06,880
And this is where dataverse matters.

910
00:43:06,880 --> 00:43:11,000
Underneath that simple request form, dataverse is creating a standardized record, not just

911
00:43:11,000 --> 00:43:13,800
storing a few loose values in a convenient place.

912
00:43:13,800 --> 00:43:17,240
That distinction matters because storage alone does not create order.

913
00:43:17,240 --> 00:43:20,800
Structure creates order, the app collects the request, but dataverse defines what that

914
00:43:20,800 --> 00:43:22,840
request actually is inside the business.

915
00:43:22,840 --> 00:43:27,240
So when the employee submits vacation dates, reason, and manager context, dataverse writes

916
00:43:27,240 --> 00:43:30,840
that into a request table with controlled fields and controlled states.

917
00:43:30,840 --> 00:43:32,600
Start date means the same thing every time.

918
00:43:32,600 --> 00:43:34,360
And date means the same thing every time.

919
00:43:34,360 --> 00:43:35,560
Status is not free text.

920
00:43:35,560 --> 00:43:37,680
It is a known value inside a shared model.

921
00:43:37,680 --> 00:43:41,360
That is what protects the process from slowly dissolving back into interpretation.

922
00:43:41,360 --> 00:43:42,600
And why is that so important?

923
00:43:42,600 --> 00:43:46,680
Because if the app alone carries the logic, the solution becomes fragile fast.

924
00:43:46,680 --> 00:43:51,000
An ice-screen can guide behavior, but the moment someone builds a second app, adds reporting

925
00:43:51,000 --> 00:43:55,400
introduces automation or opens the data to HR operations.

926
00:43:55,400 --> 00:44:00,160
In consistency, start spreading unless the data layer is already enforcing the same structure

927
00:44:00,160 --> 00:44:01,160
underneath.

928
00:44:01,160 --> 00:44:02,600
So the app is not the source of truth.

929
00:44:02,600 --> 00:44:04,960
The app is the front door into the source of truth.

930
00:44:04,960 --> 00:44:06,880
That is a cleaner division of responsibility.

931
00:44:06,880 --> 00:44:08,960
The Canvas app handles interaction.

932
00:44:08,960 --> 00:44:10,800
Dataverse handles structure.

933
00:44:10,800 --> 00:44:14,360
The app helps the employee do the right thing with the least friction.

934
00:44:14,360 --> 00:44:17,240
Dataverse makes sure the thing they entered becomes a reliable business record.

935
00:44:17,240 --> 00:44:18,960
The rest of the organization can trust.

936
00:44:18,960 --> 00:44:22,920
And once you hold that split clearly, the architecture stops feeling mysterious.

937
00:44:22,920 --> 00:44:25,840
Now inside Contoso, this request record does not sit alone.

938
00:44:25,840 --> 00:44:27,760
It connects to other records that give it meaning.

939
00:44:27,760 --> 00:44:30,080
The vacation request links back to the employee.

940
00:44:30,080 --> 00:44:31,760
It links to the manager relationship.

941
00:44:31,760 --> 00:44:35,000
It can link to country context where policy differs.

942
00:44:35,000 --> 00:44:38,520
And it can be shaped so delegation becomes possible later without rebuilding the model

943
00:44:38,520 --> 00:44:39,520
from scratch.

944
00:44:39,520 --> 00:44:43,400
That is where dataverse starts earning its place because relationships are not just

945
00:44:43,400 --> 00:44:44,760
nice technical features.

946
00:44:44,760 --> 00:44:48,640
They are how the business stops asking the same questions over and over again.

947
00:44:48,640 --> 00:44:49,640
Who requested this?

948
00:44:49,640 --> 00:44:50,640
Who is supposed to approve it?

949
00:44:50,640 --> 00:44:51,880
Which country rules may apply?

950
00:44:51,880 --> 00:44:53,160
What state is it in right now?

951
00:44:53,160 --> 00:44:57,440
A weak data layer forces people to answer those questions repeatedly through memory and

952
00:44:57,440 --> 00:44:58,440
messages.

953
00:44:58,440 --> 00:45:02,280
Strong data layer stores the answers in a form the whole process can use.

954
00:45:02,280 --> 00:45:03,920
This also protects future reporting.

955
00:45:03,920 --> 00:45:07,920
If every request enters with standardized fields and status values, leadership can later

956
00:45:07,920 --> 00:45:11,880
look across the process without cleaning up a hundred local interpretations first.

957
00:45:11,880 --> 00:45:13,200
HR can group by country.

958
00:45:13,200 --> 00:45:15,680
Teams can review pending approvals.

959
00:45:15,680 --> 00:45:18,440
Operations can start seeing whether delays are random or structural.

960
00:45:18,440 --> 00:45:21,880
None of that works well if the first app writes messy records into the back end.

961
00:45:21,880 --> 00:45:25,840
So even a small first build needs discipline in the model because later visibility depends

962
00:45:25,840 --> 00:45:27,160
on decisions made now.

963
00:45:27,160 --> 00:45:29,400
There is another benefit people often miss.

964
00:45:29,400 --> 00:45:33,560
Dataverse lets the model carry readiness for future automation without forcing automation

965
00:45:33,560 --> 00:45:34,720
into release one.

966
00:45:34,720 --> 00:45:37,040
That is exactly the position Contoso needs.

967
00:45:37,040 --> 00:45:40,240
We are not yet building the full approval engine in this episode.

968
00:45:40,240 --> 00:45:44,240
But if the request record already contains the right relationships, the right status values

969
00:45:44,240 --> 00:45:48,520
and the right ownership signals, then power automate can later move that record through

970
00:45:48,520 --> 00:45:51,360
the business without us redesigning the foundations.

971
00:45:51,360 --> 00:45:53,880
That is what good architecture feels like, not overbuilt.

972
00:45:53,880 --> 00:45:54,880
Just ready.

973
00:45:54,880 --> 00:45:58,720
So when I say the app writes to dataverse immediately, I am really saying something bigger.

974
00:45:58,720 --> 00:46:02,120
The request stops being a message and becomes a governed object in the business.

975
00:46:02,120 --> 00:46:03,280
That object can be queried.

976
00:46:03,280 --> 00:46:04,280
It can be secured.

977
00:46:04,280 --> 00:46:05,280
It can be reported on.

978
00:46:05,280 --> 00:46:06,640
It can be rooted later.

979
00:46:06,640 --> 00:46:09,880
And it can stay visible long after the original submission moment is gone.

980
00:46:09,880 --> 00:46:11,240
That is the structural handoff.

981
00:46:11,240 --> 00:46:12,640
The employee sees a simple form.

982
00:46:12,640 --> 00:46:17,240
The organization receives a standardized record with relationships, status and future process

983
00:46:17,240 --> 00:46:18,920
value already intact.

984
00:46:18,920 --> 00:46:22,880
Once you understand that split, the build feels less like magic and more like architecture

985
00:46:22,880 --> 00:46:24,800
because the screen is only one layer.

986
00:46:24,800 --> 00:46:29,800
The real strength sits underneath where dataverse keeps the process coherent even as the solution

987
00:46:29,800 --> 00:46:30,800
grows.

988
00:46:30,800 --> 00:46:33,640
Why this small build has outsized business impact.

989
00:46:33,640 --> 00:46:37,320
So now we can answer the question that usually sits in the room once a first app is described

990
00:46:37,320 --> 00:46:38,320
this simply.

991
00:46:38,320 --> 00:46:40,520
Can something this small really matter that much?

992
00:46:40,520 --> 00:46:44,280
Yes, because business drag often does not come from missing giant systems.

993
00:46:44,280 --> 00:46:46,120
It comes from weak entry points.

994
00:46:46,120 --> 00:46:49,240
And when you repair the entry point, you change everything that used to pile up behind

995
00:46:49,240 --> 00:46:50,240
it.

996
00:46:50,240 --> 00:46:51,240
That is exactly what happens at Contoso.

997
00:46:51,240 --> 00:46:52,960
Cycle time drops first.

998
00:46:52,960 --> 00:46:56,800
Not because the approval logic suddenly became brilliant and not because low code performed

999
00:46:56,800 --> 00:47:01,280
some miracle, but because the request no longer begins life as an unstructured message.

1000
00:47:01,280 --> 00:47:04,040
That one change removes a surprising amount of delay.

1001
00:47:04,040 --> 00:47:05,320
Nobody has to decode an email.

1002
00:47:05,320 --> 00:47:08,520
Nobody has to ask for missing dates that should have been captured up front.

1003
00:47:08,520 --> 00:47:12,360
Nobody has to forward the request manually just to get it into the right line of sight.

1004
00:47:12,360 --> 00:47:16,040
A structured request starts cleaner and clean starts move faster.

1005
00:47:16,040 --> 00:47:17,560
Managers feel this quickly.

1006
00:47:17,560 --> 00:47:21,080
Before the app, a manager had to function like a personal routing layer.

1007
00:47:21,080 --> 00:47:24,880
Most arrived in different channels at different times with different levels of detail.

1008
00:47:24,880 --> 00:47:28,480
Some lived in outlook, some sat in teams, some existed only in a conversation that everyone

1009
00:47:28,480 --> 00:47:30,440
assumed would be remembered later.

1010
00:47:30,440 --> 00:47:33,640
That creates overhead even before a decision gets made.

1011
00:47:33,640 --> 00:47:37,680
With the app, the manager no longer spends energy reconstructing what the employee meant.

1012
00:47:37,680 --> 00:47:41,400
The request already exists in a known state with enough context to act on it.

1013
00:47:41,400 --> 00:47:43,160
HR feels a different kind of gain.

1014
00:47:43,160 --> 00:47:46,640
HR does less follow up because every request now enters the same path.

1015
00:47:46,640 --> 00:47:48,240
That does not eliminate HR work.

1016
00:47:48,240 --> 00:47:49,800
It removes reconciliation work.

1017
00:47:49,800 --> 00:47:51,040
And those are not the same thing.

1018
00:47:51,040 --> 00:47:52,720
HR work adds value.

1019
00:47:52,720 --> 00:47:55,160
Reconciliation work just patches inconsistency.

1020
00:47:55,160 --> 00:47:59,160
When every vacation request enters through one governed front door, HR stops burning time

1021
00:47:59,160 --> 00:48:03,440
on preventable ambiguity and starts working with records that carry their own structure.

1022
00:48:03,440 --> 00:48:05,120
Employees feel something even more important.

1023
00:48:05,120 --> 00:48:06,760
They begin to trust the process.

1024
00:48:06,760 --> 00:48:11,160
That trust matters because in weak internal processes, people often create their own safety

1025
00:48:11,160 --> 00:48:12,160
nets.

1026
00:48:12,160 --> 00:48:14,880
They send a request, then they message the manager, then they save a copy.

1027
00:48:14,880 --> 00:48:17,760
Then they ask HR a few days later if anything was recorded.

1028
00:48:17,760 --> 00:48:20,440
That behavior looks personal, but it is a system outcome.

1029
00:48:20,440 --> 00:48:24,040
People build backup behavior when the formal path does not feel reliable.

1030
00:48:24,040 --> 00:48:27,760
Once the app gives them visible status and visible ownership, a lot of that compensating

1031
00:48:27,760 --> 00:48:29,200
behavior starts to disappear.

1032
00:48:29,200 --> 00:48:31,360
And that is why one form can change throughput.

1033
00:48:31,360 --> 00:48:32,680
It is not just collecting data.

1034
00:48:32,680 --> 00:48:36,640
It is removing ambiguity at the point where ambiguity used to multiply.

1035
00:48:36,640 --> 00:48:37,800
A request is now a record.

1036
00:48:37,800 --> 00:48:39,320
A record has status.

1037
00:48:39,320 --> 00:48:40,480
Status has meaning.

1038
00:48:40,480 --> 00:48:41,680
Meaning reduces chasing.

1039
00:48:41,680 --> 00:48:44,000
Chasing was where a lot of the wasted time lived.

1040
00:48:44,000 --> 00:48:46,920
This is also where structural resilience starts becoming visible.

1041
00:48:46,920 --> 00:48:51,120
Before the app, the process depended on memory, responsiveness and goodwill across scattered

1042
00:48:51,120 --> 00:48:52,120
tools.

1043
00:48:52,120 --> 00:48:53,120
That is fragile.

1044
00:48:53,120 --> 00:48:55,320
It creates hidden single points of failure everywhere.

1045
00:48:55,320 --> 00:48:57,120
One busy manager delays the process.

1046
00:48:57,120 --> 00:48:59,000
One missed email breaks continuity.

1047
00:48:59,000 --> 00:49:02,920
One absent HR colleague turns the whole thing into detective work.

1048
00:49:02,920 --> 00:49:06,720
After the app, the process does not become perfect, but it becomes more resilient because

1049
00:49:06,720 --> 00:49:10,960
the request exists independently of any one person's inbox habits.

1050
00:49:10,960 --> 00:49:13,080
That distinction is big.

1051
00:49:13,080 --> 00:49:14,920
Convenience helps individuals.

1052
00:49:14,920 --> 00:49:16,520
Visual resilience helps the business.

1053
00:49:16,520 --> 00:49:18,560
And this first build does the second one.

1054
00:49:18,560 --> 00:49:22,160
It creates a more reliable operating path for a common internal request.

1055
00:49:22,160 --> 00:49:26,180
And because vacation requests happen repeatedly, every small reduction in friction compounds

1056
00:49:26,180 --> 00:49:27,180
over time.

1057
00:49:27,180 --> 00:49:32,560
What looks like a modest app is actually changing, request quality, visibility, accountability

1058
00:49:32,560 --> 00:49:33,920
and trust all at once.

1059
00:49:33,920 --> 00:49:37,960
So when someone asks whether this is too small to matter, I would turn the question around.

1060
00:49:37,960 --> 00:49:42,360
If a process happens every week across countries, across managers, across HR, and it still

1061
00:49:42,360 --> 00:49:44,840
begins in scattered messages.

1062
00:49:44,840 --> 00:49:48,780
How expensive do you think that fragmentation already is?

1063
00:49:48,780 --> 00:49:50,320
The value did not come from low code.

1064
00:49:50,320 --> 00:49:51,680
It came from design.

1065
00:49:51,680 --> 00:49:54,720
And this is usually the moment where the platform gets too much credit.

1066
00:49:54,720 --> 00:49:56,320
People see the first app working.

1067
00:49:56,320 --> 00:49:57,640
They see the request captured.

1068
00:49:57,640 --> 00:49:59,280
They see status becoming visible.

1069
00:49:59,280 --> 00:50:02,160
And they conclude that low code itself created the value.

1070
00:50:02,160 --> 00:50:06,360
But that is not quite right because tools do not create operating clarity on their own.

1071
00:50:06,360 --> 00:50:09,480
They accelerate whatever design logic we bring into them.

1072
00:50:09,480 --> 00:50:12,680
If the thinking is clean, low code helps us express it faster.

1073
00:50:12,680 --> 00:50:16,480
If the thinking is weak, low code helps us spread that weakness faster too.

1074
00:50:16,480 --> 00:50:19,760
That distinction matters, especially for first time teams because power apps can make it

1075
00:50:19,760 --> 00:50:21,640
feel as if speed equals correctness.

1076
00:50:21,640 --> 00:50:24,280
You drag controls onto a screen, connect the table.

1077
00:50:24,280 --> 00:50:27,000
And in a very short time, you have something that looks like software.

1078
00:50:27,000 --> 00:50:28,080
That is powerful.

1079
00:50:28,080 --> 00:50:30,160
But appearance is not architecture.

1080
00:50:30,160 --> 00:50:32,960
A working screen is not proof of a good operating model.

1081
00:50:32,960 --> 00:50:37,000
It is only proof that the platform can express what we asked it to express.

1082
00:50:37,000 --> 00:50:41,180
So if Contoso gets cycle time reduction from this first app, that value did not come from

1083
00:50:41,180 --> 00:50:43,620
the fact that the app was built with low code.

1084
00:50:43,620 --> 00:50:45,500
It came from a set of design decisions.

1085
00:50:45,500 --> 00:50:50,020
One clear event boundary, one governed record, one shared status model, one cleaner entry

1086
00:50:50,020 --> 00:50:53,420
path, one separation between user experience and data structure.

1087
00:50:53,420 --> 00:50:55,420
That is where the business outcome came from.

1088
00:50:55,420 --> 00:50:57,220
The platform helped us move faster, yes.

1089
00:50:57,220 --> 00:50:58,580
It reduced the build friction.

1090
00:50:58,580 --> 00:51:01,100
It shortened the time between idea and usable interface.

1091
00:51:01,100 --> 00:51:05,220
But if we had taken the old email mess and simply wrapped it in a nice looking screen,

1092
00:51:05,220 --> 00:51:06,700
the result would still be messy.

1093
00:51:06,700 --> 00:51:08,580
It would just be messy in a more modern wrapper.

1094
00:51:08,580 --> 00:51:09,900
That happens all the time.

1095
00:51:09,900 --> 00:51:13,740
Sometimes digitize a bad process and then wonder why the business still feels slow because

1096
00:51:13,740 --> 00:51:15,460
the process did not change.

1097
00:51:15,460 --> 00:51:16,540
Only the container changed.

1098
00:51:16,540 --> 00:51:19,860
This is the thing most people miss when they first get excited about power platform.

1099
00:51:19,860 --> 00:51:22,700
They think low code removes the need for design discipline.

1100
00:51:22,700 --> 00:51:26,500
Actually, it increases the need for it because the speed of building means poor assumptions

1101
00:51:26,500 --> 00:51:29,460
can move into production before anyone has really challenged them.

1102
00:51:29,460 --> 00:51:32,020
The system is doing exactly what we told it to do.

1103
00:51:32,020 --> 00:51:34,420
It is just not doing what the business actually needs.

1104
00:51:34,420 --> 00:51:38,380
So when I say the value came from design, I mean design in the operational sense, what

1105
00:51:38,380 --> 00:51:39,700
event starts the process?

1106
00:51:39,700 --> 00:51:41,180
What data belongs at that moment?

1107
00:51:41,180 --> 00:51:42,500
What decision comes next?

1108
00:51:42,500 --> 00:51:44,700
What status language reduces ambiguity?

1109
00:51:44,700 --> 00:51:45,980
What belongs in the interface?

1110
00:51:45,980 --> 00:51:47,300
And what belongs in the model?

1111
00:51:47,300 --> 00:51:48,620
Those are design questions.

1112
00:51:48,620 --> 00:51:51,980
And once you answer them well, the platform becomes a force multiplier.

1113
00:51:51,980 --> 00:51:55,020
That is where low code becomes genuinely useful for leaders.

1114
00:51:55,020 --> 00:51:59,700
Not because it replaces architecture, but because it shortens the distance between architectural

1115
00:51:59,700 --> 00:52:01,580
clarity and business execution.

1116
00:52:01,580 --> 00:52:05,820
If we know what kind of process behavior we want, power apps and data verse, let us implement

1117
00:52:05,820 --> 00:52:09,460
that intent much faster than a traditional development path would for something of this

1118
00:52:09,460 --> 00:52:10,460
size.

1119
00:52:10,460 --> 00:52:12,180
But speed only helps when direction is right.

1120
00:52:12,180 --> 00:52:14,140
Otherwise you get a faster route to confusion.

1121
00:52:14,140 --> 00:52:16,980
A bad process in a polished screen stays a bad process.

1122
00:52:16,980 --> 00:52:21,500
A good structure in a clear interface changes behavior quickly because the user no longer

1123
00:52:21,500 --> 00:52:26,340
has to compensate for weak design with extra memory, extra messages and extra follow-up

1124
00:52:26,340 --> 00:52:27,340
work.

1125
00:52:27,340 --> 00:52:30,900
That is the actual leverage here, not low code as magic, low code as compression.

1126
00:52:30,900 --> 00:52:34,060
It compresses the distance between thought and system behavior.

1127
00:52:34,060 --> 00:52:36,100
So for Contoso, the lesson should be very clear.

1128
00:52:36,100 --> 00:52:39,900
Do not walk away thinking about power apps solved our vacation request problem.

1129
00:52:39,900 --> 00:52:43,900
The better conclusion is, once we design the process boundary properly, power apps gave

1130
00:52:43,900 --> 00:52:47,700
us a fast way to express that design in the business.

1131
00:52:47,700 --> 00:52:50,180
That is a much more useful lesson because it scales.

1132
00:52:50,180 --> 00:52:53,140
It means the next internal app should not begin with features.

1133
00:52:53,140 --> 00:52:54,740
It should begin with process shape.

1134
00:52:54,740 --> 00:52:58,300
It means leaders should not ask, what can the platform do?

1135
00:52:58,300 --> 00:53:01,100
Before asking, what operating behavior are we trying to create?

1136
00:53:01,100 --> 00:53:04,700
And it means makers should stop treating the tool like the source of value because tools

1137
00:53:04,700 --> 00:53:07,500
expose design quality more than they replace it.

1138
00:53:07,500 --> 00:53:10,460
Which brings me to one mistake almost every first time team makes.

1139
00:53:10,460 --> 00:53:13,220
The first trap, building in the default environment.

1140
00:53:13,220 --> 00:53:17,420
So now we get into the first trap and this one catches teams precisely because it feels

1141
00:53:17,420 --> 00:53:18,420
convenient.

1142
00:53:18,420 --> 00:53:20,260
The default environment is sitting there already.

1143
00:53:20,260 --> 00:53:21,260
It is available.

1144
00:53:21,260 --> 00:53:22,260
It feels close at hand.

1145
00:53:22,260 --> 00:53:26,100
You can open power apps, start building, connect the table, share something quickly and

1146
00:53:26,100 --> 00:53:29,500
for a small proof of concept that convenience can feel harmless.

1147
00:53:29,500 --> 00:53:34,060
But the moment you move from experiment to operating solution, that convenience starts

1148
00:53:34,060 --> 00:53:35,660
turning into structural drag.

1149
00:53:35,660 --> 00:53:36,660
And why is that?

1150
00:53:36,660 --> 00:53:39,300
Because the default environment is not a neutral place.

1151
00:53:39,300 --> 00:53:44,300
It is a shared space with broad ambient access patterns, mixed ownership and weaker boundaries

1152
00:53:44,300 --> 00:53:48,380
than you want for something that is supposed to become a real business process.

1153
00:53:48,380 --> 00:53:51,980
From a system perspective that is not just untidy, it is fragile.

1154
00:53:51,980 --> 00:53:55,860
You are building an operational front door on top of a space that was never meant to carry

1155
00:53:55,860 --> 00:53:57,500
clear production discipline.

1156
00:53:57,500 --> 00:53:59,420
At Contoso, that matters fast.

1157
00:53:59,420 --> 00:54:02,700
The vacation request app may look small but it is not low impact.

1158
00:54:02,700 --> 00:54:08,180
It affects employee records, manager accountability, process trust and eventually reporting.

1159
00:54:08,180 --> 00:54:13,100
So if we place that in the default environment simply because it is easy, we are teaching

1160
00:54:13,100 --> 00:54:15,180
the organization a bad lesson early.

1161
00:54:15,180 --> 00:54:19,660
We are saying the path from idea to production is just build where you happen to be standing.

1162
00:54:19,660 --> 00:54:20,980
That is how sprawl starts.

1163
00:54:20,980 --> 00:54:23,580
And once sprawl starts, several things happen at once.

1164
00:54:23,580 --> 00:54:28,420
Ownership gets blurry, support gets blurry, change control gets blurry, and security assumptions

1165
00:54:28,420 --> 00:54:32,660
start depending on who happened to create what rather than on intentional operating boundaries.

1166
00:54:32,660 --> 00:54:33,780
What is the real issue?

1167
00:54:33,780 --> 00:54:37,140
The default environment makes accidental architecture very easy.

1168
00:54:37,140 --> 00:54:38,660
Now I want to keep this proportional.

1169
00:54:38,660 --> 00:54:43,020
This episode is not a full governance deep dive and I do not want beginners thinking they

1170
00:54:43,020 --> 00:54:46,420
need a center of excellence before they can build one useful app.

1171
00:54:46,420 --> 00:54:47,420
You do not.

1172
00:54:47,420 --> 00:54:52,180
But you do need one simple habit very early, separate experimentation from operation.

1173
00:54:52,180 --> 00:54:54,540
If you are testing an idea fine, test quickly.

1174
00:54:54,540 --> 00:54:58,420
If you are creating something the business will rely on, move into an intentional environment

1175
00:54:58,420 --> 00:55:00,100
strategy as early as possible.

1176
00:55:00,100 --> 00:55:02,540
That shift changes behavior.

1177
00:55:02,540 --> 00:55:05,820
A dedicated environment says this solution has a life cycle.

1178
00:55:05,820 --> 00:55:09,540
It can be developed, tested, secured, and later supported with more discipline.

1179
00:55:09,540 --> 00:55:14,140
It creates a cleaner boundary for who builds, who accesses, and how changes move over time.

1180
00:55:14,140 --> 00:55:15,420
That is not bureaucracy.

1181
00:55:15,420 --> 00:55:17,060
That is structural resilience.

1182
00:55:17,060 --> 00:55:18,900
There is also a practical point here.

1183
00:55:18,900 --> 00:55:23,180
Governance and power platform has been moving toward more visibility, more managed environments,

1184
00:55:23,180 --> 00:55:26,500
and better tooling around app inventory and risk.

1185
00:55:26,500 --> 00:55:30,260
Organizations without governance see much higher rates of app sprawl and security issues

1186
00:55:30,260 --> 00:55:31,260
according to the research.

1187
00:55:31,260 --> 00:55:35,300
So even if this first app is modest, you want to build in a way that can mature cleanly

1188
00:55:35,300 --> 00:55:36,300
later.

1189
00:55:36,300 --> 00:55:39,500
Otherwise the first success becomes the first hidden liability.

1190
00:55:39,500 --> 00:55:43,300
The default environment is especially risky because it normalizes shortcuts.

1191
00:55:43,300 --> 00:55:47,500
Shortcuts around ownership, shortcuts around deployment, shortcuts around support expectations.

1192
00:55:47,500 --> 00:55:51,540
And once users begin depending on the app, every shortcut becomes more expensive to unwind.

1193
00:55:51,540 --> 00:55:55,420
That is why I would frame the default environment as a proof of concept zone, not an operating

1194
00:55:55,420 --> 00:55:56,420
home.

1195
00:55:56,420 --> 00:56:00,700
For early exploration, yes, a safe long term place for a governed leave request process.

1196
00:56:00,700 --> 00:56:04,700
No, the process may be simple, but the people inside it still deserve stable boundaries.

1197
00:56:04,700 --> 00:56:08,700
So if you are listening to this while planning your own first power app, take one practical

1198
00:56:08,700 --> 00:56:09,700
step.

1199
00:56:09,700 --> 00:56:13,220
Before you publish broadly, ask yourself, is this app still an experiment, or is it now

1200
00:56:13,220 --> 00:56:15,060
part of how work gets done?

1201
00:56:15,060 --> 00:56:20,020
If it is how work gets done, treat the environment choice like an architectural choice, because

1202
00:56:20,020 --> 00:56:21,020
it is one.

1203
00:56:21,020 --> 00:56:23,780
The wrong environment does not usually fail loudly on day one.

1204
00:56:23,780 --> 00:56:28,780
It quietly accumulates risk until support, visibility and control all start costing more than

1205
00:56:28,780 --> 00:56:30,100
the original speed save.

1206
00:56:30,100 --> 00:56:31,340
And that is the irony.

1207
00:56:31,340 --> 00:56:33,620
Teams choose the default environment to move faster.

1208
00:56:33,620 --> 00:56:37,220
But for operating solutions, it often slows maturity later because the system is doing

1209
00:56:37,220 --> 00:56:39,500
exactly what that convenience allowed.

1210
00:56:39,500 --> 00:56:42,100
Growing without boundaries.

1211
00:56:42,100 --> 00:56:44,540
The second trap accidental premium cost.

1212
00:56:44,540 --> 00:56:48,300
And the second trap sits right next to the first one because even when teams avoid environment

1213
00:56:48,300 --> 00:56:51,420
chaos, they can still create cost chaos without noticing.

1214
00:56:51,420 --> 00:56:53,580
This usually happens in a very ordinary way.

1215
00:56:53,580 --> 00:56:57,380
Someone says it would be nice if the app also connected to this other system.

1216
00:56:57,380 --> 00:56:59,100
And on the surface, that sounds harmless.

1217
00:56:59,100 --> 00:57:01,460
One more connector, one more convenience.

1218
00:57:01,460 --> 00:57:04,060
One little enhancement to make the process feel more complete.

1219
00:57:04,060 --> 00:57:07,500
But architecture has a habit of changing the business in places people are not looking

1220
00:57:07,500 --> 00:57:09,340
and licensing is one of those places.

1221
00:57:09,340 --> 00:57:10,540
So let me make this very plain.

1222
00:57:10,540 --> 00:57:13,860
The moment you build your first app, you are not only choosing an interface.

1223
00:57:13,860 --> 00:57:15,540
You are also choosing a cost shape.

1224
00:57:15,540 --> 00:57:19,580
That matters a lot in 2026 because power apps licensing has become less forgiving for

1225
00:57:19,580 --> 00:57:21,620
casual architectural drift.

1226
00:57:21,620 --> 00:57:24,700
Basic writes inside Microsoft 365 cover standard scenarios.

1227
00:57:24,700 --> 00:57:29,260
But the second you bring in data verse, premium connectors or custom connectors, the conversation

1228
00:57:29,260 --> 00:57:30,260
changes.

1229
00:57:30,260 --> 00:57:32,140
And not a little structurally.

1230
00:57:32,140 --> 00:57:36,300
For Contoso, we are already making one intentional decision that affects licensing.

1231
00:57:36,300 --> 00:57:37,420
We are using data verse.

1232
00:57:37,420 --> 00:57:38,420
That is fine.

1233
00:57:38,420 --> 00:57:42,460
It is justified because the process needs structured relationships, governed data and a

1234
00:57:42,460 --> 00:57:44,140
clean path to future automation.

1235
00:57:44,140 --> 00:57:46,420
So this is not a warning against data verse.

1236
00:57:46,420 --> 00:57:50,260
It is a warning against thoughtless expansion once you are already there.

1237
00:57:50,260 --> 00:57:55,380
Because if someone then says, let's also connect to a niche HR endpoint or let's pull manager

1238
00:57:55,380 --> 00:58:01,580
logic from a custom API or let's add one custom connector to enrich the request that small

1239
00:58:01,580 --> 00:58:06,780
design choice can shift the operating cost of the solution faster than the team expected.

1240
00:58:06,780 --> 00:58:07,780
And why is that?

1241
00:58:07,780 --> 00:58:11,900
Because custom connectors are premium, premium connectors change licensing requirements.

1242
00:58:11,900 --> 00:58:15,980
And one app can quietly drag a whole audience into a different cost model if the architecture

1243
00:58:15,980 --> 00:58:17,420
is not kept under control.

1244
00:58:17,420 --> 00:58:19,700
This is the part many first time teams miss.

1245
00:58:19,700 --> 00:58:22,220
They think licensing changes when the app gets bigger.

1246
00:58:22,220 --> 00:58:24,380
Often it changes when the connector list changes.

1247
00:58:24,380 --> 00:58:25,900
That is a very different risk pattern.

1248
00:58:25,900 --> 00:58:29,980
A simple vacation request app can look operationally modest while becoming commercially heavier

1249
00:58:29,980 --> 00:58:30,980
underneath.

1250
00:58:30,980 --> 00:58:34,820
Not because the business problem got more complex, but because the solution design wandered

1251
00:58:34,820 --> 00:58:37,660
into unnecessary integration, the screen still looks small.

1252
00:58:37,660 --> 00:58:38,980
The license footprint does not.

1253
00:58:38,980 --> 00:58:43,180
So for a first release, the discipline is simple, avoid external complexity unless it

1254
00:58:43,180 --> 00:58:46,140
is clearly required for the first value moment.

1255
00:58:46,140 --> 00:58:50,180
Do we need a custom connector to prove that employees can submit govern vacation requests

1256
00:58:50,180 --> 00:58:52,020
into dataverse with visible status?

1257
00:58:52,020 --> 00:58:56,020
No, do we need broad cross-system orchestration before the business has even validated the

1258
00:58:56,020 --> 00:58:57,020
new front door?

1259
00:58:57,020 --> 00:58:58,020
No.

1260
00:58:58,020 --> 00:59:01,260
Do we need to turn a clean first app into an integration project just because the platform

1261
00:59:01,260 --> 00:59:03,060
makes that technically possible?

1262
00:59:03,060 --> 00:59:04,180
Definitely not.

1263
00:59:04,180 --> 00:59:06,460
This is where architecture protects business reality.

1264
00:59:06,460 --> 00:59:09,300
A narrow design does not only reduce build effort.

1265
00:59:09,300 --> 00:59:13,940
It preserves optionality if Contoso keeps the first app focused on dataverse, the employee

1266
00:59:13,940 --> 00:59:18,660
experience and a clear status model, then later integration decisions stay available.

1267
00:59:18,660 --> 00:59:22,380
We can still add flows, we can still enrich routing, we can still connect other systems

1268
00:59:22,380 --> 00:59:25,140
when the business case is real enough to justify the cost.

1269
00:59:25,140 --> 00:59:29,420
But we do that from a position of intent, not because version one quietly accumulated expense

1270
00:59:29,420 --> 00:59:30,620
through enthusiasm.

1271
00:59:30,620 --> 00:59:32,900
And there is another reason to stay disciplined here.

1272
00:59:32,900 --> 00:59:34,940
Cost surprises, damage, trust.

1273
00:59:34,940 --> 00:59:40,140
If leadership hears low code and expects a lightweight first solution, then discovers that one small

1274
00:59:40,140 --> 00:59:44,780
design decision changed licensing expectations across a wider user group.

1275
00:59:44,780 --> 00:59:49,100
The platform gets blamed for something that was really an architecture choice.

1276
00:59:49,100 --> 00:59:50,220
That is avoidable.

1277
00:59:50,220 --> 00:59:52,900
We just need to say early what the solution is and what it is not.

1278
00:59:52,900 --> 00:59:55,500
So the rule I would apply in Contoso is very straightforward.

1279
00:59:55,500 --> 00:59:58,620
Use the minimum architecture that supports the first business outcome.

1280
00:59:58,620 --> 01:00:02,380
If standard capabilities and dataverse are enough to create the govern request path,

1281
01:00:02,380 --> 01:00:03,380
stop there for now.

1282
01:00:03,380 --> 01:00:07,260
We're not add premium complexity just to make the first release feel more impressive.

1283
01:00:07,260 --> 01:00:10,940
Impressive first releases often age badly clear first releases create options.

1284
01:00:10,940 --> 01:00:14,980
So yes, licensing matters more than many teams expect, but the answer is not fear.

1285
01:00:14,980 --> 01:00:16,340
It is intentional design.

1286
01:00:16,340 --> 01:00:20,140
Keep the first app clean, keep the connector story simple and let the business earn the right

1287
01:00:20,140 --> 01:00:22,060
to expand the cost model later.

1288
01:00:22,060 --> 01:00:26,340
Once the value is visible and the next architectural move is actually justified.

1289
01:00:26,340 --> 01:00:29,020
Handling real world complexity without bloating release one.

1290
01:00:29,020 --> 01:00:32,140
So now we get to the part that usually derails good first apps.

1291
01:00:32,140 --> 01:00:33,900
Real world complexity is real.

1292
01:00:33,900 --> 01:00:34,900
It is not imaginary.

1293
01:00:34,900 --> 01:00:37,140
It is not a lazy objection from the business.

1294
01:00:37,140 --> 01:00:40,260
Contoso really does have multiple countries policies really do differ.

1295
01:00:40,260 --> 01:00:42,460
Managers really are absent sometimes.

1296
01:00:42,460 --> 01:00:43,460
Delegation really does matter.

1297
01:00:43,460 --> 01:00:47,740
And because all of that is true, teams often jump to the wrong conclusion, which is if the

1298
01:00:47,740 --> 01:00:50,780
complexity is real, version one must contain all of it.

1299
01:00:50,780 --> 01:00:51,980
It should not.

1300
01:00:51,980 --> 01:00:54,620
What version one needs is not full behavioral coverage.

1301
01:00:54,620 --> 01:00:56,020
It needs structural readiness.

1302
01:00:56,020 --> 01:00:57,300
That is a very different standard.

1303
01:00:57,300 --> 01:01:00,740
And once you see the difference, the architecture becomes calmer.

1304
01:01:00,740 --> 01:01:03,020
We are not pretending complexity does not exist.

1305
01:01:03,020 --> 01:01:06,540
We are deciding where that complexity should live first so the business can grow into it

1306
01:01:06,540 --> 01:01:10,340
without dragging every future rule into the first employee experience.

1307
01:01:10,340 --> 01:01:12,740
Take multi-country policy as the first example.

1308
01:01:12,740 --> 01:01:17,500
If employees in Germany, the UK and the US follow different vacation rules, that matters.

1309
01:01:17,500 --> 01:01:21,700
But the first release does not need to expose every policy branch directly in the app.

1310
01:01:21,700 --> 01:01:25,700
What it does need is a clean way to associate a request with the right country context so

1311
01:01:25,700 --> 01:01:28,540
the system knows which policy frame may apply later.

1312
01:01:28,540 --> 01:01:30,940
That means country belongs in the data model first.

1313
01:01:30,940 --> 01:01:35,200
It becomes a structured attribute, not a guessing exercise and not a hidden assumption in

1314
01:01:35,200 --> 01:01:36,200
someone's head.

1315
01:01:36,200 --> 01:01:37,660
That one move does a lot of work.

1316
01:01:37,660 --> 01:01:39,140
It preserves reporting value.

1317
01:01:39,140 --> 01:01:41,220
It preserves future automation value.

1318
01:01:41,220 --> 01:01:45,500
And it keeps the app from turning into a policy encyclopedia on day one.

1319
01:01:45,500 --> 01:01:47,180
That is the pattern I want you to remember.

1320
01:01:47,180 --> 01:01:51,500
When complexity is real, put it into structure before you put it into behavior.

1321
01:01:51,500 --> 01:01:53,580
Now take delegation.

1322
01:01:53,580 --> 01:01:58,060
Manager absence is one of those small operational truths that can quietly break a process.

1323
01:01:58,060 --> 01:02:02,500
If the approval path depends on one person and that person is on leave, traveling or simply

1324
01:02:02,500 --> 01:02:04,180
unavailable, the process stalls.

1325
01:02:04,180 --> 01:02:05,660
That is a single point of failure.

1326
01:02:05,660 --> 01:02:07,140
So delegation matters early.

1327
01:02:07,140 --> 01:02:10,380
But again, readiness does not mean full automation.

1328
01:02:10,380 --> 01:02:14,060
In release one, Contoso can model the idea that a manager may have a delegate.

1329
01:02:14,060 --> 01:02:15,980
That relationship can exist in dataverse.

1330
01:02:15,980 --> 01:02:17,980
It can be visible to the architecture.

1331
01:02:17,980 --> 01:02:22,060
And it can be ready for later flow logic without forcing the employee app to care about

1332
01:02:22,060 --> 01:02:23,060
it yet.

1333
01:02:23,060 --> 01:02:24,540
That is a good example of future ready design.

1334
01:02:24,540 --> 01:02:25,820
We acknowledge the operating rule.

1335
01:02:25,820 --> 01:02:27,180
We capture it structurally.

1336
01:02:27,180 --> 01:02:30,660
We delay the heavier orchestration until the first path is proven.

1337
01:02:30,660 --> 01:02:34,620
Because if we try to build every delegation branch now, we immediately pull in more status

1338
01:02:34,620 --> 01:02:38,900
logic, more rooting logic, more exception logic and probably more notifications too.

1339
01:02:38,900 --> 01:02:40,420
The build expands fast.

1340
01:02:40,420 --> 01:02:41,420
Testing expands with it.

1341
01:02:41,420 --> 01:02:42,980
Support complexity expands with it.

1342
01:02:42,980 --> 01:02:47,020
And suddenly the first release is no longer about making request intake trustworthy.

1343
01:02:47,020 --> 01:02:51,660
It is about simulating every edge case the organization has ever experienced.

1344
01:02:51,660 --> 01:02:52,660
That is not maturity.

1345
01:02:52,660 --> 01:02:54,380
That is sequence collapse.

1346
01:02:54,380 --> 01:02:58,220
And this is where good architecture earns trust because it tells the business, yes, your

1347
01:02:58,220 --> 01:02:59,820
complexity is valid.

1348
01:02:59,820 --> 01:03:04,740
And no, we do not need to operationalize all of it at once to move forward responsibly.

1349
01:03:04,740 --> 01:03:07,820
There is a big difference between overbuilt and future ready.

1350
01:03:07,820 --> 01:03:11,940
Overbuilt means the solution carries behavior the business has not yet validated.

1351
01:03:11,940 --> 01:03:15,460
Future ready means the model carries enough structure that validated behavior can be added

1352
01:03:15,460 --> 01:03:17,500
later without tearing up the foundation.

1353
01:03:17,500 --> 01:03:18,820
Contoso needs the second one.

1354
01:03:18,820 --> 01:03:22,180
So if I were pressure testing release one, I would ask very simple questions.

1355
01:03:22,180 --> 01:03:23,780
Can the apps stay easy for the employee?

1356
01:03:23,780 --> 01:03:26,860
Can the request enter a dataverse with the right country context?

1357
01:03:26,860 --> 01:03:28,860
Can manage a relationship to be trusted?

1358
01:03:28,860 --> 01:03:30,980
Can delegation exist in the model?

1359
01:03:30,980 --> 01:03:31,980
Even if rooting weights?

1360
01:03:31,980 --> 01:03:35,260
Can we add automation later without redesigning the request object?

1361
01:03:35,260 --> 01:03:37,460
If the answer is yes, we are in a good place.

1362
01:03:37,460 --> 01:03:40,820
Because maturity does not come from stuffing everything into version one.

1363
01:03:40,820 --> 01:03:45,420
It comes from designing a path where each next layer has somewhere clean to land.

1364
01:03:45,420 --> 01:03:49,180
And once you understand that complexity stops feeling like a reason to stall.

1365
01:03:49,180 --> 01:03:52,020
It becomes a reason to sequence carefully.

1366
01:03:52,020 --> 01:03:54,380
Why this app should feel boring to the user?

1367
01:03:54,380 --> 01:03:58,620
So now we get to a word most teams hate when they are building internal apps.

1368
01:03:58,620 --> 01:03:59,620
Boring.

1369
01:03:59,620 --> 01:04:02,580
They want the app to feel modern, smart, polished, maybe even a little impressive.

1370
01:04:02,580 --> 01:04:04,860
But they want the first reaction to be wow, this looks great.

1371
01:04:04,860 --> 01:04:09,580
But for a process like vacation requests, that instinct usually points in the wrong direction

1372
01:04:09,580 --> 01:04:12,460
because the employee is not opening the app for an experience.

1373
01:04:12,460 --> 01:04:16,380
They are opening it to complete a simple task with as little uncertainty as possible.

1374
01:04:16,380 --> 01:04:18,180
That changes the design standard completely.

1375
01:04:18,180 --> 01:04:20,060
For the employee, boring is good.

1376
01:04:20,060 --> 01:04:21,580
Boring means the app is predictable.

1377
01:04:21,580 --> 01:04:24,020
Boring means nothing on the screen asks for interpretation.

1378
01:04:24,020 --> 01:04:27,020
Boring means the same action produces the same result every time.

1379
01:04:27,020 --> 01:04:29,660
And in business processes, predictability is a form of trust.

1380
01:04:29,660 --> 01:04:33,260
If an employee can ask for time off without training, without second guessing, the wording,

1381
01:04:33,260 --> 01:04:37,060
and without wondering whether they chose the wrong path, the app is doing its job.

1382
01:04:37,060 --> 01:04:38,460
It is not supposed to entertain.

1383
01:04:38,460 --> 01:04:40,180
It is supposed to remove ambiguity.

1384
01:04:40,180 --> 01:04:42,980
That is a very different goal from a showcase app.

1385
01:04:42,980 --> 01:04:47,460
And if we forget that, we start adding visual cleverness where operational clarity should

1386
01:04:47,460 --> 01:04:48,460
have been.

1387
01:04:48,460 --> 01:04:51,020
This is where many teams confuse sophistication with quality.

1388
01:04:51,020 --> 01:04:54,540
When they add extra navigation, they add more options than the user really needs.

1389
01:04:54,540 --> 01:04:58,660
They decorate the screen with status widgets, tiles, menus, and supporting information that

1390
01:04:58,660 --> 01:05:01,380
feels helpful in theory but creates noise in practice.

1391
01:05:01,380 --> 01:05:04,060
Then the employee opens the app and has to think before acting.

1392
01:05:04,060 --> 01:05:07,420
The process now looks more advanced, but structurally it has become slower.

1393
01:05:07,420 --> 01:05:08,580
And why is that?

1394
01:05:08,580 --> 01:05:12,060
Because every extra design choice increases the mental effort required to do something

1395
01:05:12,060 --> 01:05:13,700
that should have stayed obvious.

1396
01:05:13,700 --> 01:05:16,020
The business consequence is subtle but real.

1397
01:05:16,020 --> 01:05:17,020
Users hesitate.

1398
01:05:17,020 --> 01:05:18,020
They postpone.

1399
01:05:18,020 --> 01:05:22,340
They ask someone in chat just to confirm what the interface should already have made clear.

1400
01:05:22,340 --> 01:05:24,500
Support requests rise, work around survive.

1401
01:05:24,500 --> 01:05:26,500
None of that happens because people are resistant.

1402
01:05:26,500 --> 01:05:27,620
It is a system outcome.

1403
01:05:27,620 --> 01:05:31,620
The interface created interpretation cost where the process needed certainty.

1404
01:05:31,620 --> 01:05:33,380
So yes, this app should feel boring.

1405
01:05:33,380 --> 01:05:35,620
The employee should open it and immediately know where to begin.

1406
01:05:35,620 --> 01:05:37,220
They should see familiar language.

1407
01:05:37,220 --> 01:05:39,340
They should complete the request in a short path.

1408
01:05:39,340 --> 01:05:40,980
They should get a clear confirmation.

1409
01:05:40,980 --> 01:05:41,980
Then they should leave.

1410
01:05:41,980 --> 01:05:47,260
That is good design for this use case because the app is not trying to expand their engagement.

1411
01:05:47,260 --> 01:05:50,660
It is trying to minimize the cost of compliance with the process.

1412
01:05:50,660 --> 01:05:54,540
When people can do the right thing quickly, adoption goes up without campaigns because the

1413
01:05:54,540 --> 01:05:57,180
govern path becomes easier than the work around.

1414
01:05:57,180 --> 01:05:59,140
There is also a scale reason for this.

1415
01:05:59,140 --> 01:06:02,140
Contoso is not designing for one enthusiastic early adopter.

1416
01:06:02,140 --> 01:06:06,540
It is designing for many employees across countries with different habits, devices and tolerance

1417
01:06:06,540 --> 01:06:07,860
for internal tooling.

1418
01:06:07,860 --> 01:06:09,980
That means simplicity is not a lack of depth.

1419
01:06:09,980 --> 01:06:13,340
It is what allows the process to travel well across the organization.

1420
01:06:13,340 --> 01:06:17,180
The more ordinary the user experience feels, the less support the business needs to

1421
01:06:17,180 --> 01:06:18,380
carry later.

1422
01:06:18,380 --> 01:06:19,780
And support burden matters.

1423
01:06:19,780 --> 01:06:24,140
A flashy app that needs explanation is expensive in a way teams rarely model upfront.

1424
01:06:24,140 --> 01:06:28,420
A boring app that people understand instantly is cheaper to run easier to trust and less likely

1425
01:06:28,420 --> 01:06:30,340
to fragment into local workarounds.

1426
01:06:30,340 --> 01:06:35,580
That is what scale looks like in internal systems, not visual originality, operational consistency.

1427
01:06:35,580 --> 01:06:39,580
So if someone at Contoso says the first release feels too simple, I would take that as a positive

1428
01:06:39,580 --> 01:06:40,580
sign.

1429
01:06:40,580 --> 01:06:43,540
Simple means the employee does not have to understand the architecture.

1430
01:06:43,540 --> 01:06:46,260
Simple means the complexity state where it belongs.

1431
01:06:46,260 --> 01:06:48,220
Simple means the front door is doing its job.

1432
01:06:48,220 --> 01:06:50,780
And for a first app that is exactly what we want.

1433
01:06:50,780 --> 01:06:54,300
Because when the user experience becomes boring in the right way, the business gets something

1434
01:06:54,300 --> 01:06:56,420
much more valuable behind it.

1435
01:06:56,420 --> 01:06:58,020
Repeatable behavior.

1436
01:06:58,020 --> 01:07:00,220
The transformation moment inside the business.

1437
01:07:00,220 --> 01:07:04,020
And this is the point where the conversation inside Contoso starts to change.

1438
01:07:04,020 --> 01:07:07,700
Up to now, power platform may have lived in people's heads as a category, a promise, maybe

1439
01:07:07,700 --> 01:07:08,700
even a debate.

1440
01:07:08,700 --> 01:07:10,420
Useful for prototypes.

1441
01:07:10,420 --> 01:07:11,740
Interesting for makers.

1442
01:07:11,740 --> 01:07:15,340
Possibly relevant later, but once the first app is live and people can feel the process

1443
01:07:15,340 --> 01:07:18,260
moving differently, the discussion stops being theoretical.

1444
01:07:18,260 --> 01:07:19,740
It becomes operational.

1445
01:07:19,740 --> 01:07:21,380
That shift matters.

1446
01:07:21,380 --> 01:07:24,780
Because organizations rarely change their minds when you explain the platform better.

1447
01:07:24,780 --> 01:07:28,260
They change their minds when the business starts behaving differently in front of them.

1448
01:07:28,260 --> 01:07:32,100
One employee submits a request in seconds, a manager sees a real record instead of a vague

1449
01:07:32,100 --> 01:07:34,100
email, HR stops chasing context.

1450
01:07:34,100 --> 01:07:36,940
And suddenly the platform is no longer something we could use.

1451
01:07:36,940 --> 01:07:40,100
It is something that just changed a piece of business reality.

1452
01:07:40,100 --> 01:07:43,620
For leadership, this is often the first real signal, not that low code exists, not

1453
01:07:43,620 --> 01:07:45,100
that data versus structured.

1454
01:07:45,100 --> 01:07:49,260
Not that Canvas apps are flexible, those things matter, but they are still platform language.

1455
01:07:49,260 --> 01:07:51,620
What leadership notices is cycle time moving.

1456
01:07:51,620 --> 01:07:55,860
A request that used to sit in inbox drift now enters a governed path immediately.

1457
01:07:55,860 --> 01:07:57,220
Ownership becomes visible.

1458
01:07:57,220 --> 01:07:58,740
Delay becomes easier to see.

1459
01:07:58,740 --> 01:08:01,020
That turns process speed into something concrete.

1460
01:08:01,020 --> 01:08:04,980
And once leaders see process speed improve without a full custom development project, they

1461
01:08:04,980 --> 01:08:07,940
start understanding the platform in a different category.

1462
01:08:07,940 --> 01:08:08,940
Not as a side tool.

1463
01:08:08,940 --> 01:08:11,660
As an operating lever, I'd feel the different transformation.

1464
01:08:11,660 --> 01:08:15,340
For first, wind like this, internal requests often arrive as backlog pressure.

1465
01:08:15,340 --> 01:08:18,580
Every small process problem sounds like a software project.

1466
01:08:18,580 --> 01:08:21,860
Every improvement request competes with larger priorities.

1467
01:08:21,860 --> 01:08:25,780
That creates tension because the business experiences friction everywhere, but central

1468
01:08:25,780 --> 01:08:30,100
delivery capacity cannot absorb every operational fix.

1469
01:08:30,100 --> 01:08:32,580
A working first app changes that story a little.

1470
01:08:32,580 --> 01:08:37,140
It shows there is a controlled path between this process is inefficient and we need a major

1471
01:08:37,140 --> 01:08:38,140
build.

1472
01:08:38,140 --> 01:08:39,860
That does not remove the need for architecture.

1473
01:08:39,860 --> 01:08:45,500
It raises the importance of it because now IT can see a model where smaller process interventions

1474
01:08:45,500 --> 01:08:48,620
become possible without surrendering standards completely.

1475
01:08:48,620 --> 01:08:53,220
The platform becomes a way to absorb demand more intelligently provided the structure underneath

1476
01:08:53,220 --> 01:08:54,220
stays disciplined.

1477
01:08:54,220 --> 01:08:56,060
That is why early winds matter so much.

1478
01:08:56,060 --> 01:08:57,700
They do not just solve one use case.

1479
01:08:57,700 --> 01:09:00,740
They change what the organization believes is possible.

1480
01:09:00,740 --> 01:09:02,700
The business teams feel something else again.

1481
01:09:02,700 --> 01:09:04,860
They stop assuming that process pain is just normal.

1482
01:09:04,860 --> 01:09:06,740
That is a bigger shift than it sounds.

1483
01:09:06,740 --> 01:09:11,420
In many organizations people adapt to drag so completely that they stop questioning it.

1484
01:09:11,420 --> 01:09:15,540
Email chains, manual follow ups, invisible status and local workarounds become part of the

1485
01:09:15,540 --> 01:09:16,540
culture.

1486
01:09:16,540 --> 01:09:20,820
Then a small app comes in and removes one layer of that friction and suddenly people

1487
01:09:20,820 --> 01:09:23,460
can see that the old pain was never inevitable.

1488
01:09:23,460 --> 01:09:26,100
It was just embedded in the way the process had been shaped.

1489
01:09:26,100 --> 01:09:30,460
That is a powerful moment because it moves the conversation from complaint to redesign.

1490
01:09:30,460 --> 01:09:33,860
Instead of saying this process is annoying people start asking where else are we doing

1491
01:09:33,860 --> 01:09:35,020
this the hard way.

1492
01:09:35,020 --> 01:09:40,340
And that question is where maturity begins, not platform maturity, organizational maturity.

1493
01:09:40,340 --> 01:09:45,180
Because once one request path becomes cleaner other weak entry points become easier to recognize.

1494
01:09:45,180 --> 01:09:50,380
Expense approvals, equipment requests, internal service asks, HR changes.

1495
01:09:50,380 --> 01:09:55,580
The first app creates a pattern people can now see, event record status owner visibility.

1496
01:09:55,580 --> 01:09:57,100
That pattern becomes portable.

1497
01:09:57,100 --> 01:09:58,380
But there is a tension here too.

1498
01:09:58,380 --> 01:10:02,500
A first success creates appetite and appetite can be dangerous if the organization learns

1499
01:10:02,500 --> 01:10:03,660
the wrong lesson.

1500
01:10:03,660 --> 01:10:08,380
If contoso concludes that power platform means we can build everything quickly the next

1501
01:10:08,380 --> 01:10:09,900
wave will create chaos.

1502
01:10:09,900 --> 01:10:14,980
If contoso concludes that structured design plus the platform can improve specific operating

1503
01:10:14,980 --> 01:10:18,380
paths quickly then the first app has taught the right lesson.

1504
01:10:18,380 --> 01:10:22,100
That distinction is everything because the real transformation is not excitement.

1505
01:10:22,100 --> 01:10:23,220
It is seriousness.

1506
01:10:23,220 --> 01:10:27,260
The business starts taking process design more seriously because it has seen one example

1507
01:10:27,260 --> 01:10:29,180
of design turning into throughput.

1508
01:10:29,180 --> 01:10:33,260
IT starts taking low code more seriously because it has seen a controlled use case create

1509
01:10:33,260 --> 01:10:36,060
value without bypassing architecture.

1510
01:10:36,060 --> 01:10:39,820
Leadership starts taking internal process speed more seriously because it can now connect

1511
01:10:39,820 --> 01:10:43,860
software shape to business performance that is the transformation moment, not applause

1512
01:10:43,860 --> 01:10:44,860
for the app.

1513
01:10:44,860 --> 01:10:49,900
A new understanding that process friction is designable that cycle time can move without

1514
01:10:49,900 --> 01:10:53,460
giant programs and that technology does not only automate work.

1515
01:10:53,460 --> 01:10:56,020
It changes the conditions under which work happens.

1516
01:10:56,020 --> 01:10:58,220
Why the app only solves half the problem?

1517
01:10:58,220 --> 01:10:59,900
So this is where we need to stay honest.

1518
01:10:59,900 --> 01:11:03,380
The app solves a real problem but it does not solve the whole problem.

1519
01:11:03,380 --> 01:11:04,380
It fixes entry.

1520
01:11:04,380 --> 01:11:08,340
It does not yet fix movement and that difference matters more than people expect because once

1521
01:11:08,340 --> 01:11:13,060
a request enters data verse cleanly the organization often feels a sense of relief and starts

1522
01:11:13,060 --> 01:11:15,460
assuming the process is now handled.

1523
01:11:15,460 --> 01:11:19,060
But a record sitting neatly in a table is not the same thing as work progressing through

1524
01:11:19,060 --> 01:11:20,060
the business.

1525
01:11:20,060 --> 01:11:21,700
A good front door improves intake.

1526
01:11:21,700 --> 01:11:25,900
It does not guarantee flow at contoso the employee can now submit vacation properly.

1527
01:11:25,900 --> 01:11:30,540
That is a meaningful shift the request exists the data is structured ownership is visible

1528
01:11:30,540 --> 01:11:34,860
at the starting point status begins from a govern baseline all of that is good.

1529
01:11:34,860 --> 01:11:38,100
But after submission something still has to happen someone has to be prompted someone

1530
01:11:38,100 --> 01:11:42,660
has to act if they do not the request can still stall only now it stalls more neatly

1531
01:11:42,660 --> 01:11:43,660
than before.

1532
01:11:43,660 --> 01:11:47,740
That is why I would separate two kinds of capability very clearly the app handles interface.

1533
01:11:47,740 --> 01:11:51,580
The next layer handles orchestration and if we blur those two we start expecting the

1534
01:11:51,580 --> 01:11:53,540
wrong thing from the first build.

1535
01:11:53,540 --> 01:11:58,100
An interface is about capturing intent well it gives the employee a clean way to enter

1536
01:11:58,100 --> 01:12:02,140
the system it lowers friction reduces ambiguity and makes the opening event reliable but

1537
01:12:02,140 --> 01:12:06,220
orchestration is different orchestration is what moves a request from one accountable

1538
01:12:06,220 --> 01:12:07,580
state to another.

1539
01:12:07,580 --> 01:12:11,700
It is what turns a clean record into a progressing process that includes things like rooting who

1540
01:12:11,700 --> 01:12:15,940
should be asked next it includes reminders what happens if the manager does not respond

1541
01:12:15,940 --> 01:12:20,300
it includes escalation what happens if the approval window starts slipping and it includes

1542
01:12:20,300 --> 01:12:24,500
hand off logic what happens if the assigned approver is absent and delegation needs to take

1543
01:12:24,500 --> 01:12:29,020
effect those are not screen questions those are flow questions and once you see that the

1544
01:12:29,020 --> 01:12:32,700
architecture becomes easier to reason about the canvas app was the right move for the front

1545
01:12:32,700 --> 01:12:37,260
door because the front door needed simplicity but the moment a request exists a different

1546
01:12:37,260 --> 01:12:42,260
kind of system behavior has to take over not better visuals better movement this clicked

1547
01:12:42,260 --> 01:12:46,860
for me years ago when I saw teams celebrate a successful form launch then wonder why cycle

1548
01:12:46,860 --> 01:12:51,380
time only improved part of the way the answer was always the same submission got better

1549
01:12:51,380 --> 01:12:55,860
throughput did not fully change because the request still depended on manual follow up after

1550
01:12:55,860 --> 01:13:00,700
entry the system had learned how to receive intent but not yet how to carry intent through

1551
01:13:00,700 --> 01:13:04,820
the rest of the path that is exactly the point contoso is reaching now the employee side

1552
01:13:04,820 --> 01:13:09,260
is cleaner the operating path behind it is still partially manual so a manager may still

1553
01:13:09,260 --> 01:13:13,980
need prompting HR may still need visibility on delay delegation may still depend on human

1554
01:13:13,980 --> 01:13:18,860
intervention the request may still sit too long in one state if no automation keeps it moving

1555
01:13:18,860 --> 01:13:23,540
that does not mean the app failed it means the app solved the first half well enough that

1556
01:13:23,540 --> 01:13:27,660
the second half is now visible and from a business perspective that is progress because

1557
01:13:27,660 --> 01:13:32,100
hidden process weakness is much harder to improve than visible process weakness before the

1558
01:13:32,100 --> 01:13:35,860
app intake and flow were both messy at the same time so everything blurred together now

1559
01:13:35,860 --> 01:13:39,820
the entry point is cleaner which means the remaining drag stands out we can see where

1560
01:13:39,820 --> 01:13:43,660
movement still breaks down that is a good outcome that gives us a sharper problem statement

1561
01:13:43,660 --> 01:13:49,660
for what comes next not build more app but design the flow layer that carries this governed

1562
01:13:49,660 --> 01:13:54,780
request through approvals reminders and state change without depending on inbox habits which

1563
01:13:54,780 --> 01:13:59,420
brings me to the next architectural move once the request exists in data verse as a proper

1564
01:13:59,420 --> 01:14:03,740
business object automation becomes the force multiplier not because automation is trendy

1565
01:14:03,740 --> 01:14:07,580
and not because every process needs a giant workflow but because a clean record without

1566
01:14:07,580 --> 01:14:11,940
movement still leaves throughput exposed the form collected intent the next layer needs

1567
01:14:11,940 --> 01:14:16,220
to create motion so if this episode was about giving the business a proper front door the

1568
01:14:16,220 --> 01:14:19,620
next one has to deal with the corridor behind it because that is where requests either

1569
01:14:19,620 --> 01:14:25,380
move with discipline or quietly start waiting again so if you are listening to this and

1570
01:14:25,380 --> 01:14:29,260
thinking fine but what do I actually do next let me make that practical do not start with

1571
01:14:29,260 --> 01:14:32,940
a platform feature start with one narrow request that enters your business repeatedly

1572
01:14:32,940 --> 01:14:37,820
and causes delay because people still handle it through messages memory and local interpretation

1573
01:14:37,820 --> 01:14:42,060
that could be leave requests it could be equipment requests it could be onboarding tasks the

1574
01:14:42,060 --> 01:14:46,580
specific use case matters less than the pattern you are looking for a process with one clear

1575
01:14:46,580 --> 01:14:51,820
trigger one obvious decision path and one painful amount of ambiguity at the front door

1576
01:14:51,820 --> 01:14:57,260
then define one measurable outcome not five one for this contours example we used cycle time

1577
01:14:57,260 --> 01:15:01,740
reduction because it ties directly to the operating problem a request that used to drift

1578
01:15:01,740 --> 01:15:06,780
through email now enters a governed path immediately that is visible that is measurable

1579
01:15:06,780 --> 01:15:11,620
and it gives you a way to judge whether the app improved business behavior or just changed

1580
01:15:11,620 --> 01:15:16,940
where people click after that map the process in three parts what event starts it what decision

1581
01:15:16,940 --> 01:15:21,340
follows it what status language should the whole business share if you cannot answer those

1582
01:15:21,340 --> 01:15:25,420
three questions cleanly do not build yet you are still dealing with process fog and the

1583
01:15:25,420 --> 01:15:29,420
platform will not fix that for you it will only express it faster once those answers are

1584
01:15:29,420 --> 01:15:34,220
clear choose the app type based on the job if your first need is a controlled simple low

1585
01:15:34,220 --> 01:15:38,540
friction experience for employees choose canvas canvas is the right front door when adoption

1586
01:15:38,540 --> 01:15:43,260
depends on clarity especially for narrow actions like request submission if your primary need is

1587
01:15:43,260 --> 01:15:48,940
broad operational visibility across records relationships views and process oversight model driven

1588
01:15:48,940 --> 01:15:53,980
maybe the better fit not because it is more advanced but because it is built for a different operating

1589
01:15:53,980 --> 01:15:59,340
posture and if you are unsure ask a simpler question are you designing for ease of entry or for

1590
01:15:59,340 --> 01:16:03,900
depth of operations that question usually clears the noise then model the data with more discipline

1591
01:16:03,900 --> 01:16:08,060
than feels necessary at first that sounds backwards because beginners often want to spend energy

1592
01:16:08,060 --> 01:16:13,020
on screens but the cleaner your data verse structure is now the easier everything becomes later

1593
01:16:13,020 --> 01:16:17,900
create the request object properly you standardize statuses link the request to the employee and

1594
01:16:17,900 --> 01:16:23,500
approval context add structural readiness for future complexity like delegation or country policy

1595
01:16:23,500 --> 01:16:27,340
without trying to automate all of it in release one this is the part most people skip and then

1596
01:16:27,340 --> 01:16:32,060
they pay for it later next protect scope your first release does not need reminders escalations

1597
01:16:32,060 --> 01:16:36,380
advanced routing external integrations in every edge case the business can remember from the last

1598
01:16:36,380 --> 01:16:42,220
10 years it needs one thing more than anything else a stable first value moment in contoso that

1599
01:16:42,220 --> 01:16:46,860
value moment is very simple and employee submits a proper vacation request into data verse and can

1600
01:16:46,860 --> 01:16:51,100
see that it exists with a visible status that is enough to change behavior ship that before you

1601
01:16:51,100 --> 01:16:55,820
chase completeness while you are doing that stay intentional about where you build if the app is

1602
01:16:55,820 --> 01:17:00,380
still an experiment fine move quickly if the app is about to become part of how work gets done stop

1603
01:17:00,380 --> 01:17:05,260
treating environment choice like an afterthought give it cleaner boundaries start as you mean to grow

1604
01:17:05,260 --> 01:17:10,140
that one decision saves you from a lot of support and governance paying later and keep your connector

1605
01:17:10,140 --> 01:17:14,940
story simple a first app does not need to impress people with integration density it needs to prove

1606
01:17:14,940 --> 01:17:20,300
that a better operating path exists the more external complexity you pull in too early the more likely

1607
01:17:20,300 --> 01:17:25,260
you are to create cost surprises testing drag and dependency problems before the business has

1608
01:17:25,260 --> 01:17:30,540
even validated the basic pattern earn complexity do not frontload it so the implementation path is

1609
01:17:30,540 --> 01:17:36,620
not complicated but it does require restraint pick one repeatable request pick one business metric

1610
01:17:36,620 --> 01:17:41,660
define event decision and status choose canvas or model driven based on the real job model data verse

1611
01:17:41,660 --> 01:17:46,700
cleanly ship the smallest usable release keep environments and connectors intentional then watch

1612
01:17:46,700 --> 01:17:51,900
what happens to behavior because if your app idea still sounds vague after all of that there is a good

1613
01:17:51,900 --> 01:17:57,020
chance you do not have an app problem yet you have a process design problem that wants to masquerade

1614
01:17:57,020 --> 01:18:02,860
as a user interface project and that distinction will save you a lot of wasted build effort so that is

1615
01:18:02,860 --> 01:18:08,220
the first architectural move turn structured data into a working front door and use the app type

1616
01:18:08,220 --> 01:18:12,620
that fits the behavior you actually need if you want the next layer where this request starts moving

1617
01:18:12,620 --> 01:18:17,660
through approvals reminders and delegation without inbox drift listen the next episode because

1618
01:18:17,660 --> 01:18:21,500
a form captures intent, but automation is what creates throughput.