The PCF Blueprint: Architecture Over UI

1
00:00:00,000 --> 00:00:03,440
PCF gets pitched to you as a way to make a text box look nicer.

2
00:00:03,440 --> 00:00:07,080
A slider instead of a number field, a calendar view instead of a boring grid.

3
00:00:07,080 --> 00:00:08,960
That is the pitch you hear in every demo.

4
00:00:08,960 --> 00:00:10,280
But that is not what it is.

5
00:00:10,280 --> 00:00:13,320
Everyone treats PowerApps component framework like a UI skin.

6
00:00:13,320 --> 00:00:17,020
They think it is something you slap on at the end to make an app look less like a form

7
00:00:17,020 --> 00:00:18,120
and more like a product.

8
00:00:18,120 --> 00:00:22,080
But the architects who actually run large power platform tenants, they do not see a skin,

9
00:00:22,080 --> 00:00:25,880
they see a governance layer, and that difference matters more than it sounds like it should.

10
00:00:25,880 --> 00:00:29,520
Because underneath the nice controls conversation, there is a real problem.

11
00:00:29,520 --> 00:00:33,080
Technical debt, ALM that either exists or does not.

12
00:00:33,080 --> 00:00:37,280
And the thing everyone calls Citizen Developer Chaos, like it is a people problem.

13
00:00:37,280 --> 00:00:39,640
It is not a people problem, it is a structural one.

14
00:00:39,640 --> 00:00:43,360
If you are the person who ends up cleaning up someone else's power platform mess, the

15
00:00:43,360 --> 00:00:47,360
apps nobody documented, the fields nobody explains, the forms that break the moment someone

16
00:00:47,360 --> 00:00:48,360
leaves the company.

17
00:00:48,360 --> 00:00:50,600
Hit subscribe, this episode is for you.

18
00:00:50,600 --> 00:00:54,400
By the end you will see PCF as the actual difference between a tenant that scales and one

19
00:00:54,400 --> 00:00:57,200
that quietly collapses under its own apps brawl.

20
00:00:57,200 --> 00:00:59,160
The lie we tell ourselves about low code.

21
00:00:59,160 --> 00:01:00,760
Here is the pitch everyone gets.

22
00:01:00,760 --> 00:01:05,120
Low code means anyone can build business analysts, ops managers, whoever.

23
00:01:05,120 --> 00:01:06,520
No developers required.

24
00:01:06,520 --> 00:01:08,720
And PCF in this pitch is just the icing.

25
00:01:08,720 --> 00:01:11,640
It is just a few nice controls on top of what is already easy to build.

26
00:01:11,640 --> 00:01:13,800
It sounds fine, it even sounds a little exciting.

27
00:01:13,800 --> 00:01:17,600
More people building means more problem solved, which should mean faster business value.

28
00:01:17,600 --> 00:01:19,480
But there is a floor assumption buried in there.

29
00:01:19,480 --> 00:01:22,560
The assumption is that speed of creation equals health of the system.

30
00:01:22,560 --> 00:01:24,120
It does not, not even close.

31
00:01:24,120 --> 00:01:28,120
You can have 100 apps built in a month and a tenant that is falling apart underneath them.

32
00:01:28,120 --> 00:01:31,840
Because building fast and building sound are two completely different things.

33
00:01:31,840 --> 00:01:35,400
And low code tooling was never designed to tell you which one you are doing.

34
00:01:35,400 --> 00:01:37,600
This is where the cost actually shows up.

35
00:01:37,600 --> 00:01:41,960
Technical debt research shows that when organizations ignore debt in these builds, it can cut ROI

36
00:01:41,960 --> 00:01:43,520
by 18 to 29%.

37
00:01:43,520 --> 00:01:45,560
That is not a hypothetical drag on productivity.

38
00:01:45,560 --> 00:01:48,720
That is a real number tied to real remediation work later.

39
00:01:48,720 --> 00:01:52,480
That work would not exist if governance had been part of the build from day one.

40
00:01:52,480 --> 00:01:54,200
So who is actually at fault here?

41
00:01:54,200 --> 00:01:56,200
This is where most conversations go wrong.

42
00:01:56,200 --> 00:01:57,520
Citizen developers are not the risk.

43
00:01:57,520 --> 00:02:02,240
A business analyst dragging a field onto a form is not what causes a tenant to buckle.

44
00:02:02,240 --> 00:02:04,040
Ungoverned components are the risk.

45
00:02:04,040 --> 00:02:05,120
Think about the difference.

46
00:02:05,120 --> 00:02:09,800
A citizen developer building inside a system that has approved patterns, versioned controls,

47
00:02:09,800 --> 00:02:10,880
and clear ownership.

48
00:02:10,880 --> 00:02:13,040
That is the system working exactly as intended.

49
00:02:13,040 --> 00:02:15,400
A citizen developer building inside a vacuum.

50
00:02:15,400 --> 00:02:19,120
Where every app invents its own logic, its own validation and its own visual language.

51
00:02:19,120 --> 00:02:20,720
That is not citizen development.

52
00:02:20,720 --> 00:02:22,760
That is just structural drift with a friendly name.

53
00:02:22,760 --> 00:02:26,080
And this is where PCF actually earns its place in the conversation.

54
00:02:26,080 --> 00:02:29,120
Not as decoration, but as the thing that closes that vacuum.

55
00:02:29,120 --> 00:02:32,400
Because a properly built PCF component is not a suggestion.

56
00:02:32,400 --> 00:02:35,160
It is not a style guide somebody wrote and nobody reads.

57
00:02:35,160 --> 00:02:38,840
The moment it gets packaged and deployed, it becomes an enforcement mechanism.

58
00:02:38,840 --> 00:02:43,680
Every app that uses it inherits the same validation, the same behavior and the same guardrails.

59
00:02:43,680 --> 00:02:46,600
That happens whether the person building that app knows it or not.

60
00:02:46,600 --> 00:02:49,000
That is the reframe this whole episode is built around.

61
00:02:49,000 --> 00:02:50,520
PCF is not decoration.

62
00:02:50,520 --> 00:02:52,000
It is the enforcement layer.

63
00:02:52,000 --> 00:02:55,200
And once you see it that way, you start asking a completely different set of questions

64
00:02:55,200 --> 00:02:57,720
about how your tenant is actually built.

65
00:02:57,720 --> 00:03:00,240
What PCF actually is structurally.

66
00:03:00,240 --> 00:03:01,800
Forget the marketing for a second.

67
00:03:01,800 --> 00:03:03,320
Because that's where the confusion starts.

68
00:03:03,320 --> 00:03:05,440
PCF is a code component framework.

69
00:03:05,440 --> 00:03:06,440
That's it.

70
00:03:06,440 --> 00:03:11,000
It is a way to write typescript, package it and plug it into three specific places.

71
00:03:11,000 --> 00:03:13,440
Model driven apps, canvas apps and custom pages.

72
00:03:13,440 --> 00:03:14,960
That is the entire surface area.

73
00:03:14,960 --> 00:03:17,080
It isn't a design tool or a theme engine.

74
00:03:17,080 --> 00:03:20,440
It's a framework for building components that get deployed like software.

75
00:03:20,440 --> 00:03:21,440
Because that's what they are.

76
00:03:21,440 --> 00:03:24,840
When you actually build one of these, you pick one of two templates.

77
00:03:24,840 --> 00:03:26,720
This distinction matters more than people realize.

78
00:03:26,720 --> 00:03:27,920
The first is a field control.

79
00:03:27,920 --> 00:03:29,160
It's bound to one value.

80
00:03:29,160 --> 00:03:31,240
One control replaces one field on a form.

81
00:03:31,240 --> 00:03:32,440
Think of it as a scope swap.

82
00:03:32,440 --> 00:03:36,200
Whatever is sitting in that number field or text field, you're replacing it with your own

83
00:03:36,200 --> 00:03:37,200
logic.

84
00:03:37,200 --> 00:03:38,520
But only for that single value.

85
00:03:38,520 --> 00:03:40,360
The second is a data set control.

86
00:03:40,360 --> 00:03:41,720
It's bound to a whole grid.

87
00:03:41,720 --> 00:03:45,120
This is what replaces subgrids views and entire lists of records.

88
00:03:45,120 --> 00:03:48,840
Instead of touching one value, you're changing how a set of rows gets displayed and sorted

89
00:03:48,840 --> 00:03:50,800
across every form using that view.

90
00:03:50,800 --> 00:03:51,800
Two templates.

91
00:03:51,800 --> 00:03:53,200
Two very different blast radiuses.

92
00:03:53,200 --> 00:03:54,280
This isn't a UI detail.

93
00:03:54,280 --> 00:03:56,920
It's an architecture decision baked into the tool itself.

94
00:03:56,920 --> 00:03:59,160
But here's the part that actually matters for your strategy.

95
00:03:59,160 --> 00:04:02,720
Once you build something as a component, it stops being a simple page tweak.

96
00:04:02,720 --> 00:04:04,640
It becomes a governed, versioned artifact.

97
00:04:04,640 --> 00:04:05,640
It has a manifest.

98
00:04:05,640 --> 00:04:09,200
It has a version number that you have to increment before changes even take effect.

99
00:04:09,200 --> 00:04:14,080
It gets packaged into a solution and tracked like any other piece of deployable software.

100
00:04:14,080 --> 00:04:15,800
Compare that to someone editing a form directly.

101
00:04:15,800 --> 00:04:16,800
They drag a label around.

102
00:04:16,800 --> 00:04:18,200
They tweak a formula in place.

103
00:04:18,200 --> 00:04:19,560
There is no version history on that.

104
00:04:19,560 --> 00:04:20,560
There is no artifact.

105
00:04:20,560 --> 00:04:23,800
There is just a form that looks different today than it did yesterday.

106
00:04:23,800 --> 00:04:24,920
There is no record of why.

107
00:04:24,920 --> 00:04:25,920
That's the shift.

108
00:04:25,920 --> 00:04:27,680
A component isn't a decoration you add to a page.

109
00:04:27,680 --> 00:04:32,000
It is a thing that exists independently of the page with its own life cycle that the page

110
00:04:32,000 --> 00:04:33,320
simply references.

111
00:04:33,320 --> 00:04:36,400
It is just as important to know where PCF doesn't run.

112
00:04:36,400 --> 00:04:37,920
That boundary shapes your architecture.

113
00:04:37,920 --> 00:04:39,560
PCF does not run in Power BI.

114
00:04:39,560 --> 00:04:43,240
It does not run in Power Automate because there is no UI surface to attach it to.

115
00:04:43,240 --> 00:04:44,680
And it does not run on premise.

116
00:04:44,680 --> 00:04:48,600
This is a cloud only capability tied to the modern unified interface.

117
00:04:48,600 --> 00:04:51,400
Not the legacy web client from before 2016.

118
00:04:51,400 --> 00:04:52,600
That boundary isn't trivia.

119
00:04:52,600 --> 00:04:57,280
If you're designing a solution that spans Power BI dashboards and Power Automate flows,

120
00:04:57,280 --> 00:05:01,080
you need to know that your governed component strategy only covers the apps.

121
00:05:01,080 --> 00:05:03,920
Not the reports, not the automations.

122
00:05:03,920 --> 00:05:05,320
All of this sounds technical.

123
00:05:05,320 --> 00:05:08,000
Templates, manifests, and runtime boundaries.

124
00:05:08,000 --> 00:05:10,680
But the implication underneath is entirely executive.

125
00:05:10,680 --> 00:05:14,480
Because what you're really deciding when you choose PCF over a one-off customization is

126
00:05:14,480 --> 00:05:18,040
whether that functionality lives inside a control system or outside of one.

127
00:05:18,040 --> 00:05:20,000
That isn't a developer's decision to make alone.

128
00:05:20,000 --> 00:05:21,440
It's an architecture decision.

129
00:05:21,440 --> 00:05:25,760
And it determines whether your tenant, six months from now, has a handful of known components.

130
00:05:25,760 --> 00:05:29,600
Or a few hundred untraceable page tweaks that nobody can explain.

131
00:05:29,600 --> 00:05:31,680
The governance vacuum nobody talks about.

132
00:05:31,680 --> 00:05:35,200
Picture a typical mid-size org running power platform for three or four years.

133
00:05:35,200 --> 00:05:37,320
Not a huge enterprise, not a startup.

134
00:05:37,320 --> 00:05:40,320
Just a normal company that adopted low code because it worked.

135
00:05:40,320 --> 00:05:44,000
They have somewhere between 200 and 500 canvas apps.

136
00:05:44,000 --> 00:05:45,840
Nobody actually knows the exact number.

137
00:05:45,840 --> 00:05:47,320
And that's the first sign of the problem.

138
00:05:47,320 --> 00:05:48,320
There is no inventory.

139
00:05:48,320 --> 00:05:51,400
There is no single place that says, "These are the apps we have.

140
00:05:51,400 --> 00:05:53,840
This is what they touch and this is who built them."

141
00:05:53,840 --> 00:05:55,600
There is no ownership map either.

142
00:05:55,600 --> 00:05:58,320
Half the apps were built by someone who left 18 months ago.

143
00:05:58,320 --> 00:06:01,560
The other half were built by people who have forgotten what their own formulas do.

144
00:06:01,560 --> 00:06:03,040
This isn't a hypothetical.

145
00:06:03,040 --> 00:06:06,200
This is the default state of power platform at scale.

146
00:06:06,200 --> 00:06:10,680
Environments multiply because it's easy to spin one up and nobody ever tears them down.

147
00:06:10,680 --> 00:06:14,200
Apps multiply because building is fast and nobody is tracking what already exists.

148
00:06:14,200 --> 00:06:16,320
You end up with duplication everywhere.

149
00:06:16,320 --> 00:06:19,360
Five different versions of the same expense approval app.

150
00:06:19,360 --> 00:06:22,360
Each built by a different team that didn't know the others existed.

151
00:06:22,360 --> 00:06:25,360
This is where classic web resources made a bad situation worse.

152
00:06:25,360 --> 00:06:29,080
Back in the JavaScript and HTML era, those things were iframe-based.

153
00:06:29,080 --> 00:06:31,560
They ran in their own little sandboxed bubble.

154
00:06:31,560 --> 00:06:34,720
Invisible to the platform tooling meant to track solution contents.

155
00:06:34,720 --> 00:06:36,680
A web resource didn't have a life cycle.

156
00:06:36,680 --> 00:06:39,160
It didn't have a version number that meant anything.

157
00:06:39,160 --> 00:06:44,320
They just sat there, referenced by a form, until someone opened the code to reverse engineer it.

158
00:06:44,320 --> 00:06:47,840
You couldn't inventory a web resource the way you can inventory a proper component.

159
00:06:47,840 --> 00:06:51,440
You couldn't ask the platform what depends on this and get a real answer.

160
00:06:51,440 --> 00:06:53,560
It existed in a blind spot by design.

161
00:06:53,560 --> 00:06:55,120
So what happens in an environment like that?

162
00:06:55,120 --> 00:06:56,360
The vacuum doesn't stay empty.

163
00:06:56,360 --> 00:06:57,960
It gets filled, just not on purpose.

164
00:06:57,960 --> 00:07:01,560
Someone needs a custom drop-down behavior so they write a web resource.

165
00:07:01,560 --> 00:07:03,560
Someone else needs the same thing three months later.

166
00:07:03,560 --> 00:07:05,840
Doesn't know the first one exists and writes their own version.

167
00:07:05,840 --> 00:07:09,440
A third person copies the second one, tweaks it slightly and ships it into a different

168
00:07:09,440 --> 00:07:10,440
app.

169
00:07:10,440 --> 00:07:11,440
None of this is malicious.

170
00:07:11,440 --> 00:07:14,120
It's just what happens when there is no visibility and no catalog.

171
00:07:14,120 --> 00:07:16,840
And it holds together, right up until it doesn't.

172
00:07:16,840 --> 00:07:20,680
Some updates are shared field and three apps break that nobody realized were touching that

173
00:07:20,680 --> 00:07:21,680
field.

174
00:07:21,680 --> 00:07:25,360
Someone leaves the company and their web resource becomes untouchable because nobody else

175
00:07:25,360 --> 00:07:27,840
understands the code and there is no documentation.

176
00:07:27,840 --> 00:07:31,040
The failure always shows up in production, never earlier because there is nothing in the

177
00:07:31,040 --> 00:07:32,960
structure to surface the problem sooner.

178
00:07:32,960 --> 00:07:33,960
That's the gap.

179
00:07:33,960 --> 00:07:36,320
It isn't a people problem or a training problem.

180
00:07:36,320 --> 00:07:40,480
It is a structural absence of inventory, ownership and life cycle and that gap, the exact

181
00:07:40,480 --> 00:07:43,480
shape of it, is what PCF was built to close.

182
00:07:43,480 --> 00:07:45,360
PCF has enforcement by design.

183
00:07:45,360 --> 00:07:49,680
That gap has a name now, at least for the people watching where power platform governance

184
00:07:49,680 --> 00:07:51,440
is heading in 2026.

185
00:07:51,440 --> 00:07:54,240
The shift is called enforcement by design.

186
00:07:54,240 --> 00:07:57,880
It's worth sitting with that phrase for a second because it's doing a lot of work.

187
00:07:57,880 --> 00:08:01,080
Enforcement by design means the rules aren't written down in a document, hoping people

188
00:08:01,080 --> 00:08:02,080
read them.

189
00:08:02,080 --> 00:08:05,480
There is no policy PDF sitting in a SharePoint folder that nobody opens.

190
00:08:05,480 --> 00:08:08,960
There are no onboarding slides that say please follow governance standards.

191
00:08:08,960 --> 00:08:11,440
Only to be ignored the moment a deadline hits.

192
00:08:11,440 --> 00:08:14,440
Enforcement by design means the rules are built into the tool itself.

193
00:08:14,440 --> 00:08:17,600
Having them isn't a choice, it's just what happens when you use the platform.

194
00:08:17,600 --> 00:08:21,880
And that's exactly what a PCF component does, the moment it gets packaged into a solution.

195
00:08:21,880 --> 00:08:23,800
The mechanism is simpler than it sounds.

196
00:08:23,800 --> 00:08:27,160
The instant you take a component and reference it inside a solution.

197
00:08:27,160 --> 00:08:31,120
It stops being loose code sitting in a project folder, it becomes a government dependency.

198
00:08:31,120 --> 00:08:34,960
The platform now knows it exists, it knows what solution it belongs to, it knows what version

199
00:08:34,960 --> 00:08:38,400
it's on, that knowledge isn't optional metadata you have to configure.

200
00:08:38,400 --> 00:08:40,280
It's just there, automatically.

201
00:08:40,280 --> 00:08:42,080
Because that's how the packaging works.

202
00:08:42,080 --> 00:08:43,640
Once it's a government dependency.

203
00:08:43,640 --> 00:08:47,360
It inherits a whole set of behaviors without anyone lifting a finger to set them up.

204
00:08:47,360 --> 00:08:49,080
First, you get versioning.

205
00:08:49,080 --> 00:08:51,800
Every component carries a version number in its manifest.

206
00:08:51,800 --> 00:08:54,560
That number has to increment before change takes effect.

207
00:08:54,560 --> 00:08:58,080
You can't silently override a component the way you could silently edit a page.

208
00:08:58,080 --> 00:09:00,120
Second, you get promotion rules.

209
00:09:00,120 --> 00:09:04,000
A component inside a solution moves through the same path as everything else that goes

210
00:09:04,000 --> 00:09:06,000
from dev to test to production.

211
00:09:06,000 --> 00:09:09,080
It doesn't get hand-carried into an environment by whoever happened to build it.

212
00:09:09,080 --> 00:09:10,960
Third, you get rollback paths.

213
00:09:10,960 --> 00:09:12,440
If a new version breaks something.

214
00:09:12,440 --> 00:09:15,720
There's an actual previous version to fall back to, but the old one didn't get erased.

215
00:09:15,720 --> 00:09:17,000
It got superseded.

216
00:09:17,000 --> 00:09:18,520
None of that existed with the old model.

217
00:09:18,520 --> 00:09:21,840
A JavaScript web resource had no version discipline built in.

218
00:09:21,840 --> 00:09:25,800
You could edit it in place, re-publish it, and the old behavior was just gone.

219
00:09:25,800 --> 00:09:27,600
There was no promotion path either.

220
00:09:27,600 --> 00:09:31,320
People would build directly in what was functionally a production environment, because nothing

221
00:09:31,320 --> 00:09:32,400
was stopping them.

222
00:09:32,400 --> 00:09:34,560
And rollback, there was nothing to roll back to.

223
00:09:34,560 --> 00:09:38,120
The old code wasn't preserved anywhere unless someone kept a manual backup.

224
00:09:38,120 --> 00:09:40,040
And let's be honest, that almost never happened.

225
00:09:40,040 --> 00:09:41,040
This isn't abstract.

226
00:09:41,040 --> 00:09:42,920
Let's look at how this actually plays out.

227
00:09:42,920 --> 00:09:44,840
A team needs something fixed fast.

228
00:09:44,840 --> 00:09:47,920
Maybe a form field isn't validating correctly and there's a deadline.

229
00:09:47,920 --> 00:09:50,400
Someone writes a quick JavaScript web resource.

230
00:09:50,400 --> 00:09:51,400
Tests it in the moment.

231
00:09:51,400 --> 00:09:52,400
And ships it.

232
00:09:52,400 --> 00:09:53,400
It works.

233
00:09:53,400 --> 00:09:54,400
Everyone moves on.

234
00:09:54,400 --> 00:09:58,400
Six months later, someone else is trying to figure out why a form is behaving strangely.

235
00:09:58,400 --> 00:10:00,880
They open it up and find that web resource sitting there.

236
00:10:00,880 --> 00:10:03,040
But there's no way to answer the basic questions.

237
00:10:03,040 --> 00:10:04,120
Who wrote this?

238
00:10:04,120 --> 00:10:05,320
What version is it?

239
00:10:05,320 --> 00:10:06,320
What else does it touch?

240
00:10:06,320 --> 00:10:09,640
There's no audit trail, because a web resource was never designed to leave one.

241
00:10:09,640 --> 00:10:12,800
Now run that same scenario with a PCF component instead.

242
00:10:12,800 --> 00:10:13,880
Someone builds the fix.

243
00:10:13,880 --> 00:10:16,720
They package it into a solution and push a version increment.

244
00:10:16,720 --> 00:10:19,400
Six months later, when someone opens that same solution.

245
00:10:19,400 --> 00:10:21,840
The component is right there with its version history intact.

246
00:10:21,840 --> 00:10:23,240
You can see when it was deployed.

247
00:10:23,240 --> 00:10:26,760
You can see what changed between versions and because it's tracked as a dependency, you

248
00:10:26,760 --> 00:10:29,760
can see exactly which forms an apps reference it.

249
00:10:29,760 --> 00:10:31,680
Same emergency, same six month gap.

250
00:10:31,680 --> 00:10:35,320
But the outcome is completely different because one of these was built to leave a trail

251
00:10:35,320 --> 00:10:37,160
and the other one wasn't.

252
00:10:37,160 --> 00:10:40,160
The solution layer, why packaging changes everything.

253
00:10:40,160 --> 00:10:42,960
We've talked about what happens once a component is packaged.

254
00:10:42,960 --> 00:10:45,360
Now let's talk about the thing doing the packaging.

255
00:10:45,360 --> 00:10:49,520
Most people hear the word solution and think it's just a dynamics-flavored term for a folder.

256
00:10:49,520 --> 00:10:50,680
It isn't.

257
00:10:50,680 --> 00:10:52,720
Solutions are the delivery mechanism for PCF.

258
00:10:52,720 --> 00:10:55,400
Full stop, they aren't a dynamics concept borrowed for convenience.

259
00:10:55,400 --> 00:10:59,200
They are the actual pipe that moves a component from your machine to a real environment

260
00:10:59,200 --> 00:11:00,760
where real people use it.

261
00:11:00,760 --> 00:11:03,040
In practice, this changes everything.

262
00:11:03,040 --> 00:11:06,840
You write your TypeScript, you build it locally, you test it in a harness.

263
00:11:06,840 --> 00:11:10,880
One of that matters yet in a governance sense because none of it is deployed anywhere real.

264
00:11:10,880 --> 00:11:14,600
The moment it changes is the moment you reference that component inside a solution and push

265
00:11:14,600 --> 00:11:15,600
it.

266
00:11:15,600 --> 00:11:16,600
That single act flips a switch.

267
00:11:16,600 --> 00:11:19,040
The component stops being a folder of code on your laptop.

268
00:11:19,040 --> 00:11:22,960
It starts being a tracked dependency inside a system that knows it exists.

269
00:11:22,960 --> 00:11:26,880
Think about what a tracked dependency actually buys you.

270
00:11:26,880 --> 00:11:31,120
Once a component is in a solution, the platform knows which solution it lives in, what else

271
00:11:31,120 --> 00:11:33,480
is packaged alongside it and what depends on it.

272
00:11:33,480 --> 00:11:34,480
You don't set that up.

273
00:11:34,480 --> 00:11:35,960
It's just what a solution is.

274
00:11:35,960 --> 00:11:37,120
It's just that to a page decoration.

275
00:11:37,120 --> 00:11:40,640
Some tweak someone made directly on a form, no packaging, no reference, nothing tracking

276
00:11:40,640 --> 00:11:41,640
it.

277
00:11:41,640 --> 00:11:44,440
A page decoration disappears from institutional memory, the second the person who made it

278
00:11:44,440 --> 00:11:46,200
stops explaining it in Slack.

279
00:11:46,200 --> 00:11:49,600
A tracked dependency doesn't have that problem because it's not memory dependent, it's

280
00:11:49,600 --> 00:11:51,600
structured dependent.

281
00:11:51,600 --> 00:11:56,160
Inside the solution layer, there's a distinction that matters more than most teams treat it.

282
00:11:56,160 --> 00:11:57,640
Managed versus unmanaged.

283
00:11:57,640 --> 00:11:59,720
An unmanaged solution is your working state.

284
00:11:59,720 --> 00:12:03,000
It's editable, it's flexible, it's where you're still figuring things out.

285
00:12:03,000 --> 00:12:07,240
A managed solution is locked, you can't casually edit its contents in the target environment.

286
00:12:07,240 --> 00:12:09,840
And that's not a limitation, that's the entire point.

287
00:12:09,840 --> 00:12:14,360
Production environments should run managed solutions because production isn't where you want

288
00:12:14,360 --> 00:12:17,160
components changed by whoever happens to click into it.

289
00:12:17,160 --> 00:12:20,680
The unmanaged to manage distinction is really a discipline distinction.

290
00:12:20,680 --> 00:12:24,760
It draws a hard line between this is still being shaped and this is deployed and stable.

291
00:12:24,760 --> 00:12:28,720
Skipping that line is exactly how components end up getting silently altered in place as

292
00:12:28,720 --> 00:12:30,400
nobody is supposed to touch.

293
00:12:30,400 --> 00:12:33,720
And this is where the connection to ALM stops being abstract.

294
00:12:33,720 --> 00:12:37,840
If your component only exists as an unmanaged blob, you push straight into an environment,

295
00:12:37,840 --> 00:12:39,960
you don't have ALM, you have a habit.

296
00:12:39,960 --> 00:12:44,200
Real application lifecycle management means that component moves through a path.

297
00:12:44,200 --> 00:12:48,040
It starts in dev where it's built and broken and fixed, then it goes to test where it gets

298
00:12:48,040 --> 00:12:50,760
validated against something other than your own assumptions.

299
00:12:50,760 --> 00:12:55,000
Finally, it reaches production in production, it reaches real users, packaged as managed,

300
00:12:55,000 --> 00:12:57,920
locked down, and traceable.

301
00:12:57,920 --> 00:13:01,240
The promotion path isn't the best practice you can skip when you're busy.

302
00:13:01,240 --> 00:13:04,720
Once a component lives inside a solution, the promotion path is structural.

303
00:13:04,720 --> 00:13:08,560
The solution mechanism basically forces the question, which environment is this actually

304
00:13:08,560 --> 00:13:09,560
ready for?

305
00:13:09,560 --> 00:13:11,280
That's what's happening underneath all of this.

306
00:13:11,280 --> 00:13:15,080
Governance by architecture stops being a phrase in a slide deck, the moment packaging enters

307
00:13:15,080 --> 00:13:16,240
the picture.

308
00:13:16,240 --> 00:13:19,480
Because packaging turns intention into a pipeline, you don't have to trust that someone

309
00:13:19,480 --> 00:13:20,960
will follow the rules.

310
00:13:20,960 --> 00:13:24,000
The solution layer just doesn't let you skip the steps.

311
00:13:24,000 --> 00:13:26,720
Field controls, the smallest unit of governance.

312
00:13:26,720 --> 00:13:29,240
Zoom all the way down to the smallest possible unit.

313
00:13:29,240 --> 00:13:32,840
Everything we've said about solutions and packaging still applies here, even at this tiny

314
00:13:32,840 --> 00:13:34,720
scale, and that surprises people.

315
00:13:34,720 --> 00:13:37,440
A field control is the simplest thing PCF does.

316
00:13:37,440 --> 00:13:41,720
It's one control bound to one value, replacing one native field on a form.

317
00:13:41,720 --> 00:13:44,640
That is it, there is no grid, no dataset, no list of records.

318
00:13:44,640 --> 00:13:49,400
You are touching a single value, the same way you would touch a single cell in a spreadsheet.

319
00:13:49,400 --> 00:13:52,360
Nothing about that sounds like it should matter much, it's just one field.

320
00:13:52,360 --> 00:13:55,400
But here's the thing, most people get wrong at exactly this scale.

321
00:13:55,400 --> 00:13:59,200
You can hear at the smallest possible unit of PCF you aren't making a cosmetic choice.

322
00:13:59,200 --> 00:14:01,240
You are making an architectural one.

323
00:14:01,240 --> 00:14:04,160
The size of the change has nothing to do with the size of its consequences.

324
00:14:04,160 --> 00:14:05,640
Let's make that concrete.

325
00:14:05,640 --> 00:14:09,160
Say you have a whole number field, someone decides it would be nicer as a slider.

326
00:14:09,160 --> 00:14:12,680
Drag left, drag right, and pick your value visually instead of typing a number.

327
00:14:12,680 --> 00:14:15,680
This sounds like exactly the kind of thing PCF gets marketed for.

328
00:14:15,680 --> 00:14:19,640
But it's the nice controls pitch, except that is not what is actually happening under the

329
00:14:19,640 --> 00:14:20,640
surface.

330
00:14:20,640 --> 00:14:24,720
A whole number field left alone will technically accept any integer you type into it.

331
00:14:24,720 --> 00:14:26,000
A slider constrains that.

332
00:14:26,000 --> 00:14:27,000
It has a minimum.

333
00:14:27,000 --> 00:14:28,000
It has a maximum.

334
00:14:28,000 --> 00:14:29,000
It has a step interval.

335
00:14:29,000 --> 00:14:32,840
The moment you replace that field with a slider, you aren't just predefined data entry.

336
00:14:32,840 --> 00:14:36,040
You are constraining how data enters your system in the first place.

337
00:14:36,040 --> 00:14:39,520
Someone can no longer type 4000 into a field that was only ever meant to hold values between

338
00:14:39,520 --> 00:14:40,520
zero and 100.

339
00:14:40,520 --> 00:14:43,320
You have closed off an entire category of bad input.

340
00:14:43,320 --> 00:14:46,400
And you didn't do it by writing a validation rule that runs after the fact.

341
00:14:46,400 --> 00:14:49,720
You did it by removing the possibility at the point of entry.

342
00:14:49,720 --> 00:14:53,080
That is a data integrity decision wearing a UI costume.

343
00:14:53,080 --> 00:14:54,960
Once you see it that way, you can't really unsee it.

344
00:14:54,960 --> 00:14:57,440
And here's the part that actually compounds over time.

345
00:14:57,440 --> 00:15:00,040
That validation logic doesn't live in a form anymore.

346
00:15:00,040 --> 00:15:03,880
It doesn't live in some business rule that has to be recreated on every screen that uses

347
00:15:03,880 --> 00:15:04,880
this field.

348
00:15:04,880 --> 00:15:09,120
It lives in the code of the control itself, which means it gets reviewed once when the component

349
00:15:09,120 --> 00:15:10,600
is built and packaged.

350
00:15:10,600 --> 00:15:14,920
Then it gets applied everywhere that control is used automatically without anyone reimplementing

351
00:15:14,920 --> 00:15:15,920
it.

352
00:15:15,920 --> 00:15:19,640
Every form, every app in every table, it is bound to inherit the exact same constraint,

353
00:15:19,640 --> 00:15:21,920
the same range, the same behavior.

354
00:15:21,920 --> 00:15:25,640
Nobody has to remember to enforce it a second time compared that to the alternative.

355
00:15:25,640 --> 00:15:29,480
Every team writes their own client-side validation slightly differently on every form that needs

356
00:15:29,480 --> 00:15:32,360
it, some catch the edge case and some do not.

357
00:15:32,360 --> 00:15:34,880
Some remember the maximum while others forget it entirely.

358
00:15:34,880 --> 00:15:38,640
A field control removes that inconsistency by design, not by policy.

359
00:15:38,640 --> 00:15:42,840
And if a single field carries this much architectural weight, it is worth asking what happens

360
00:15:42,840 --> 00:15:47,400
when you stop binding to one value, what happens when you start binding to an entire set

361
00:15:47,400 --> 00:15:48,400
of records.

362
00:15:48,400 --> 00:15:51,280
Instead, that is a different scale of decision entirely.

363
00:15:51,280 --> 00:15:55,160
And it is where most organizations actually lose control of their tenant.

364
00:15:55,160 --> 00:15:57,240
Data set controls governing at scale.

365
00:15:57,240 --> 00:16:01,240
Take that same idea and stretch it across an entire set of records instead of a single value.

366
00:16:01,240 --> 00:16:05,240
That is a data set control, instead of binding to a whole number field or a text field,

367
00:16:05,240 --> 00:16:08,000
you are binding to grids, views and subgrids.

368
00:16:08,000 --> 00:16:11,800
Anything that displays multiple rows at once, it is the same mechanism as a field control,

369
00:16:11,800 --> 00:16:13,520
but at a completely different scale.

370
00:16:13,520 --> 00:16:16,560
And this is where organizations actually lose control of their tenant.

371
00:16:16,560 --> 00:16:18,120
It doesn't happen with field controls.

372
00:16:18,120 --> 00:16:20,000
Nobody notices a slider getting out of hand.

373
00:16:20,000 --> 00:16:24,320
It happens here with grids because grids are where every team ends up building its own version

374
00:16:24,320 --> 00:16:25,320
of the same thing.

375
00:16:25,320 --> 00:16:27,480
Here is what that looks like in practice.

376
00:16:27,480 --> 00:16:31,840
One team needs to show related records on a canvas app screen so they build a gallery,

377
00:16:31,840 --> 00:16:35,760
they add filters, sorting and some conditional formatting to highlight overdue items.

378
00:16:35,760 --> 00:16:36,760
It works fine.

379
00:16:36,760 --> 00:16:40,400
A different team in a different department needs almost the exact same thing three months

380
00:16:40,400 --> 00:16:41,400
later.

381
00:16:41,400 --> 00:16:44,760
They don't know the first gallery exists, so they build their own slightly different filter

382
00:16:44,760 --> 00:16:46,320
logic, slightly different sort order.

383
00:16:46,320 --> 00:16:49,800
It is the same basic idea implemented from scratch all over again.

384
00:16:49,800 --> 00:16:53,200
You can apply that by every business unit that has ever needed to show a list of records

385
00:16:53,200 --> 00:16:54,680
with some custom behavior.

386
00:16:54,680 --> 00:16:57,800
You end up with dozens of galleries doing roughly the same job.

387
00:16:57,800 --> 00:16:59,840
None of them are consistent with each other.

388
00:16:59,840 --> 00:17:01,600
None of them share a single line of logic.

389
00:17:01,600 --> 00:17:03,040
That isn't a hypothetical pattern.

390
00:17:03,040 --> 00:17:06,480
That is just what happens when there is no shared component, and building your own is

391
00:17:06,480 --> 00:17:08,400
the path of least resistance.

392
00:17:08,400 --> 00:17:09,560
Nobody is doing anything wrong.

393
00:17:09,560 --> 00:17:14,080
They are just solving the same problem in isolation over and over because there is nothing

394
00:17:14,080 --> 00:17:15,080
stopping them.

395
00:17:15,080 --> 00:17:18,200
There is nothing steering them towards something that already exists.

396
00:17:18,200 --> 00:17:20,960
A single dataset control changes that math entirely.

397
00:17:20,960 --> 00:17:24,240
You build the grid once, you add the sorting, the filtering, and the conditional formatting

398
00:17:24,240 --> 00:17:26,200
it needs, then you deploy it.

399
00:17:26,200 --> 00:17:30,800
That one control can now replace every one of those ad hoc gallery implementations.

400
00:17:30,800 --> 00:17:35,040
Because it isn't tied to a specific app or a specific team, it is a component sitting

401
00:17:35,040 --> 00:17:38,960
in a solution available anywhere, and that is really the reuse argument in its purest

402
00:17:38,960 --> 00:17:39,960
form.

403
00:17:39,960 --> 00:17:43,480
Build once, then bind it to any table in any form across the entire tenant.

404
00:17:43,480 --> 00:17:46,960
It doesn't matter if one team is showing contacts in another is showing service tickets.

405
00:17:46,960 --> 00:17:50,880
The underlying grid behavior, the sort logic, and the display rules all come from the same

406
00:17:50,880 --> 00:17:51,880
source.

407
00:17:51,880 --> 00:17:55,480
You are not rebuilding the wheel for every table you happen to be working with that week.

408
00:17:55,480 --> 00:17:57,040
Here are the stakes laid out plainly.

409
00:17:57,040 --> 00:18:00,760
With one dataset control governing this behavior, you have one thing to maintain.

410
00:18:00,760 --> 00:18:02,080
You have one place to fix a bug.

411
00:18:02,080 --> 00:18:05,920
You have one place to add a feature, and every app using that control gets the improvement

412
00:18:05,920 --> 00:18:06,920
automatically.

413
00:18:06,920 --> 00:18:09,080
Without it, you have 50 divergent implementations.

414
00:18:09,080 --> 00:18:10,400
Each has its own quirks.

415
00:18:10,400 --> 00:18:13,440
Each is maintained by whoever happens to remember they built it.

416
00:18:13,440 --> 00:18:16,920
Each one is a separate fire waiting to happen when something changes upstream.

417
00:18:16,920 --> 00:18:19,760
But all 50 of them depend on slightly differently.

418
00:18:19,760 --> 00:18:21,720
That isn't just a maintenance inconvenience.

419
00:18:21,720 --> 00:18:26,240
That is the difference between a tenant with one grid to govern and a tenant with 50 grids.

420
00:18:26,240 --> 00:18:28,120
Nobody fully understands anymore.

421
00:18:28,120 --> 00:18:31,440
The performance argument executives actually care about.

422
00:18:31,440 --> 00:18:34,360
Performance usually gets treated like a footnote, something for developers to worry about

423
00:18:34,360 --> 00:18:35,640
in a dark room.

424
00:18:35,640 --> 00:18:37,840
But in reality, it's a governance issue.

425
00:18:37,840 --> 00:18:40,760
Treating it as anything less is how organizations missed the point.

426
00:18:40,760 --> 00:18:42,320
Here is the number you need to know.

427
00:18:42,320 --> 00:18:47,160
The CF components load 50 to 70% faster than legacy HTML web resources.

428
00:18:47,160 --> 00:18:48,920
They also use less memory.

429
00:18:48,920 --> 00:18:51,400
This isn't a small change you need to stop watch to see.

430
00:18:51,400 --> 00:18:55,120
It is the difference between an app that feels instant and one that makes people sit in

431
00:18:55,120 --> 00:18:56,120
wait.

432
00:18:56,120 --> 00:18:57,520
Wondering if the screen is frozen.

433
00:18:57,520 --> 00:19:00,080
The gap exists because of how the code actually runs.

434
00:19:00,080 --> 00:19:02,520
A classic web resource sits inside an iframe.

435
00:19:02,520 --> 00:19:06,240
Think of it as a separate bubble, a tiny sandbox that is totally cut off from the page around

436
00:19:06,240 --> 00:19:07,240
it.

437
00:19:07,240 --> 00:19:09,000
Every time that iframe loads, you pay a tax.

438
00:19:09,000 --> 00:19:12,200
You are loading a separate document and a separate rendering context.

439
00:19:12,200 --> 00:19:14,160
It is extra overhead just to exist.

440
00:19:14,160 --> 00:19:16,120
A PCF component doesn't pay that tax.

441
00:19:16,120 --> 00:19:19,360
It shares the same rendering context as everything else on the page.

442
00:19:19,360 --> 00:19:23,280
It integrates directly into the platform pipeline instead of being bolted onto the side.

443
00:19:23,280 --> 00:19:25,080
There is no iframe boundary to cross.

444
00:19:25,080 --> 00:19:28,480
And no second document quietly loading in the background while the user waits.

445
00:19:28,480 --> 00:19:29,560
That is the mechanical reason.

446
00:19:29,560 --> 00:19:30,920
But here is the shift.

447
00:19:30,920 --> 00:19:33,160
Faster apps are not just a nice to have feature.

448
00:19:33,160 --> 00:19:35,680
You don't just mention them in a release note and move on.

449
00:19:35,680 --> 00:19:39,400
Performance translates directly into the report's leadership actually looks at.

450
00:19:39,400 --> 00:19:41,200
Support tickets go down.

451
00:19:41,200 --> 00:19:45,480
The app is slow is the most common complaint any power platform team here.

452
00:19:45,480 --> 00:19:46,880
And it is rarely about the data.

453
00:19:46,880 --> 00:19:49,120
It is almost always about the rendering.

454
00:19:49,120 --> 00:19:50,120
Adoption goes up.

455
00:19:50,120 --> 00:19:52,640
People quietly abandon tools that feel sluggish.

456
00:19:52,640 --> 00:19:54,480
Even if they never file a formal complaint.

457
00:19:54,480 --> 00:19:55,840
They just stop opening the app.

458
00:19:55,840 --> 00:19:59,000
Eventually someone asks why the usage numbers are dropping.

459
00:19:59,000 --> 00:20:02,240
And the answer traces back to a load time that nobody bothered to measure.

460
00:20:02,240 --> 00:20:06,520
When you argue for governed PCF components over legacy resources, you aren't making an

461
00:20:06,520 --> 00:20:07,520
aesthetic case.

462
00:20:07,520 --> 00:20:10,360
You are making a case about ticket volume and adoption curves.

463
00:20:10,360 --> 00:20:12,440
Those are the numbers that get budgets approved.

464
00:20:12,440 --> 00:20:14,000
But I need to slow down here.

465
00:20:14,000 --> 00:20:18,120
Because performance cuts both ways, this is where most implementations go sideways.

466
00:20:18,120 --> 00:20:21,440
Everything I just described happens when a PCF component is built well.

467
00:20:21,440 --> 00:20:25,920
That 50% to 70% gain isn't automatic, just because you chose the framework.

468
00:20:25,920 --> 00:20:27,880
It is a ceiling, not a guarantee.

469
00:20:27,880 --> 00:20:30,960
The moment you assume the framework does the work for you, you've missed the part that

470
00:20:30,960 --> 00:20:32,280
requires discipline.

471
00:20:32,280 --> 00:20:36,720
Where PCF performance breaks down, a badly built PCF control can be slower than the native

472
00:20:36,720 --> 00:20:38,160
field it replaced.

473
00:20:38,160 --> 00:20:40,800
Not just unoptimized, slower, worse.

474
00:20:40,800 --> 00:20:44,200
It becomes the exact opposite of what PCF is supposed to deliver.

475
00:20:44,200 --> 00:20:45,240
That should stop you for a second.

476
00:20:45,240 --> 00:20:48,400
It means choosing PCF is not a performance decision on its own.

477
00:20:48,400 --> 00:20:49,400
It is a starting point.

478
00:20:49,400 --> 00:20:53,160
It can go in either direction depending entirely on what happens inside the code.

479
00:20:53,160 --> 00:20:54,840
So let's walk through how this breaks.

480
00:20:54,840 --> 00:20:56,440
The failure modes are very specific.

481
00:20:56,440 --> 00:20:58,120
First, bloated bundles.

482
00:20:58,120 --> 00:21:01,160
Every PCF component ships a package of code to the browser.

483
00:21:01,160 --> 00:21:04,520
If that package is heavy, the user pays for it on every single load.

484
00:21:04,520 --> 00:21:08,720
A control meant to show one simple field can end up weighing more than the entire form

485
00:21:08,720 --> 00:21:09,720
it sits on.

486
00:21:09,720 --> 00:21:11,720
Second, unnecessary libraries.

487
00:21:11,720 --> 00:21:13,400
This usually starts with good intentions.

488
00:21:13,400 --> 00:21:17,280
A developer needs one function from a charting library, so they import the whole thing.

489
00:21:17,280 --> 00:21:21,280
When you multiply that across five components on one form, you have five copies of overlapping

490
00:21:21,280 --> 00:21:22,480
code loading at once.

491
00:21:22,480 --> 00:21:23,800
None of them share resources.

492
00:21:23,800 --> 00:21:27,800
All of them add to the initial load time while the user sits there waiting.

493
00:21:27,800 --> 00:21:31,440
Third, constant re-renders.

494
00:21:31,440 --> 00:21:35,480
If a component redraws itself every time a tiny thing changes, it feels laggy.

495
00:21:35,480 --> 00:21:38,800
The moment someone starts typing or clicking, the interface stutters.

496
00:21:38,800 --> 00:21:39,880
That isn't a data problem.

497
00:21:39,880 --> 00:21:43,360
It is a code problem, and it stays invisible until someone actually interacts with the

498
00:21:43,360 --> 00:21:44,360
thing.

499
00:21:44,360 --> 00:21:45,360
None of this is exotic.

500
00:21:45,360 --> 00:21:48,080
These are the same mistakes people make in general web development.

501
00:21:48,080 --> 00:21:49,320
Because that is what this is now.

502
00:21:49,320 --> 00:21:52,160
Native controls are the performance baseline for a reason.

503
00:21:52,160 --> 00:21:55,880
Microsoft spent years optimizing those out of the box fields and grids.

504
00:21:55,880 --> 00:21:57,120
They aren't fast by accident.

505
00:21:57,120 --> 00:21:59,520
They are fast because of massive engineering effort.

506
00:21:59,520 --> 00:22:02,280
A PCF control does not inherit that work automatically.

507
00:22:02,280 --> 00:22:03,280
It starts from zero.

508
00:22:03,280 --> 00:22:07,200
It only matches that baseline if the person building it puts in the same level of discipline.

509
00:22:07,200 --> 00:22:08,560
This is the architectural point.

510
00:22:08,560 --> 00:22:11,880
A PCF control isn't just a power platform customization anymore.

511
00:22:11,880 --> 00:22:13,520
It is a piece of front-end engineering.

512
00:22:13,520 --> 00:22:16,560
Bundlesize, re-render logic dependency choices.

513
00:22:16,560 --> 00:22:19,600
All of it needs the same rigor you would expect from a production web app.

514
00:22:19,600 --> 00:22:21,720
Because that is what is happening every time you deploy.

515
00:22:21,720 --> 00:22:23,480
This is where the conversation has to go next.

516
00:22:23,480 --> 00:22:27,360
If a component can be this good or this bad-based purely on how it was built, then governance

517
00:22:27,360 --> 00:22:29,040
cannot stop at environments.

518
00:22:29,040 --> 00:22:33,360
It has to include a review process for the components themselves before they ever reach the catalog.

519
00:22:33,360 --> 00:22:35,440
Otherwise, you aren't governing quality.

520
00:22:35,440 --> 00:22:38,920
You are just governing where the bad performance gets deployed.

521
00:22:38,920 --> 00:22:41,800
The hybrid model, standard controls versus PCF.

522
00:22:41,800 --> 00:22:45,280
If a component can break this easily, you might think the answer is caution.

523
00:22:45,280 --> 00:22:46,280
And it is.

524
00:22:46,280 --> 00:22:47,920
But not the way most people apply it.

525
00:22:47,920 --> 00:22:49,920
The decision framework here is simple to state.

526
00:22:49,920 --> 00:22:52,920
It's just harder to follow when you're under deadline pressure.

527
00:22:52,920 --> 00:22:53,920
Standard controls first.

528
00:22:53,920 --> 00:22:56,080
PCF only where there is a structural gap.

529
00:22:56,080 --> 00:22:58,200
Not PCF because it looks nicer.

530
00:22:58,200 --> 00:23:03,120
Not PCF because someone on the team wants to try building one, a structural gap.

531
00:23:03,120 --> 00:23:05,800
Something standard controls genuinely cannot do.

532
00:23:05,800 --> 00:23:08,160
Not something they do adequately but less impressively.

533
00:23:08,160 --> 00:23:10,600
So what actually qualifies as a gap, three things.

534
00:23:10,600 --> 00:23:12,400
And we have to name them precisely.

535
00:23:12,400 --> 00:23:16,240
Because vague criteria are how this framework gets abused within a month.

536
00:23:16,240 --> 00:23:18,080
First, complex visualization.

537
00:23:18,080 --> 00:23:20,360
Think of a gant chart or a custom map view.

538
00:23:20,360 --> 00:23:23,440
No combination of native fields and galleries gets you there.

539
00:23:23,440 --> 00:23:25,200
Second, high traffic screens.

540
00:23:25,200 --> 00:23:28,360
The handful of forms or apps that hundreds of people touch every day.

541
00:23:28,360 --> 00:23:32,160
On that scale, even a small usability improvement pays for itself.

542
00:23:32,160 --> 00:23:35,200
Third, reusable patterns across many apps.

543
00:23:35,200 --> 00:23:39,200
The kind of thing we saw with data set controls, where one build replaces dozens of team by team

544
00:23:39,200 --> 00:23:40,200
reinventions.

545
00:23:40,200 --> 00:23:42,080
Notice what is missing from that list.

546
00:23:42,080 --> 00:23:43,080
It would look better.

547
00:23:43,080 --> 00:23:44,240
That is not a criterion.

548
00:23:44,240 --> 00:23:45,240
That is a preference.

549
00:23:45,240 --> 00:23:49,600
And preferences do not justify the maintenance burden a custom component carries for

550
00:23:49,600 --> 00:23:51,120
the rest of its life.

551
00:23:51,120 --> 00:23:52,240
But here is the problem.

552
00:23:52,240 --> 00:23:56,880
The mistake that happens constantly, someone takes a simple text input, a field that does

553
00:23:56,880 --> 00:24:01,440
exactly what a native text field already does and replaces it with a heavy custom control.

554
00:24:01,440 --> 00:24:02,800
Maybe it has a styling flourish.

555
00:24:02,800 --> 00:24:06,160
Maybe it does something the native field already handled with a simple formula.

556
00:24:06,160 --> 00:24:07,320
That is not a governance win.

557
00:24:07,320 --> 00:24:08,800
It is a governance failure.

558
00:24:08,800 --> 00:24:10,200
Dressed up as an improvement.

559
00:24:10,200 --> 00:24:11,720
Now you have a component to version.

560
00:24:11,720 --> 00:24:12,720
You have to review it.

561
00:24:12,720 --> 00:24:13,720
You have to maintain it.

562
00:24:13,720 --> 00:24:16,800
You have to explain it to the next person who opens that form.

563
00:24:16,800 --> 00:24:21,160
And it is buying you nothing that a native field wasn't already giving you for free.

564
00:24:21,160 --> 00:24:23,480
Every PCF component you deploy is a promise.

565
00:24:23,480 --> 00:24:25,520
A promise that someone will maintain it.

566
00:24:25,520 --> 00:24:26,960
That its performance will be watched.

567
00:24:26,960 --> 00:24:28,920
That its dependencies won't quietly rot.

568
00:24:28,920 --> 00:24:30,560
You don't make that promise for a text box.

569
00:24:30,560 --> 00:24:32,760
You make it for the things that actually earn the weight.

570
00:24:32,760 --> 00:24:34,400
Which raises the obvious next question.

571
00:24:34,400 --> 00:24:37,480
If PCF only belongs in the tenant for genuine structural gaps.

572
00:24:37,480 --> 00:24:39,840
How does anyone actually know what's already been built?

573
00:24:39,840 --> 00:24:41,160
What's already approved?

574
00:24:41,160 --> 00:24:43,840
What still needs a fresh component versus a native field?

575
00:24:43,840 --> 00:24:45,360
You can't keep that in someone's head.

576
00:24:45,360 --> 00:24:49,520
You can't rely on institutional memory because we already saw what happens to that memory.

577
00:24:49,520 --> 00:24:51,840
The moment the person carrying it leaves.

578
00:24:51,840 --> 00:24:53,960
That is where the idea of a catalog comes in.

579
00:24:53,960 --> 00:24:55,280
Not a folder of code samples.

580
00:24:55,280 --> 00:25:00,200
A catalog in the governance sense is a documented and versioned list of the components and

581
00:25:00,200 --> 00:25:02,800
organization has actually approved for use.

582
00:25:02,800 --> 00:25:03,800
It says what they do.

583
00:25:03,800 --> 00:25:04,800
It says what they are for.

584
00:25:04,800 --> 00:25:08,320
It shows where the line sits between use this and build your own.

585
00:25:08,320 --> 00:25:09,400
It is an artifact.

586
00:25:09,400 --> 00:25:11,560
The same way a solution is an artifact.

587
00:25:11,560 --> 00:25:14,080
Something that exists independent of any one person's memory.

588
00:25:14,080 --> 00:25:17,360
And once that catalog exists, it stops being a nice reference document.

589
00:25:17,360 --> 00:25:21,320
It starts being the actual organizing principle behind how an architecture team runs its entire

590
00:25:21,320 --> 00:25:23,040
component strategy.

591
00:25:23,040 --> 00:25:24,520
Building the component catalog.

592
00:25:24,520 --> 00:25:27,160
Here is what a mature organization actually maintains.

593
00:25:27,160 --> 00:25:31,520
And it is less exciting than it sounds, not a wiki page someone updated once, not a channel

594
00:25:31,520 --> 00:25:33,680
in teams where people occasionally post.

595
00:25:33,680 --> 00:25:36,040
Hey, did anyone already build this?

596
00:25:36,040 --> 00:25:41,080
A documented versioned library of approved components with a real record of what each one

597
00:25:41,080 --> 00:25:45,280
does, what version it is on, and what it is meant to replace that is the catalog.

598
00:25:45,280 --> 00:25:46,280
It is a list.

599
00:25:46,280 --> 00:25:49,720
But it is a governed list, which is a completely different thing from a list someone made

600
00:25:49,720 --> 00:25:53,800
once and forgot about, because in reality, this matters more than any single control you

601
00:25:53,800 --> 00:25:54,800
could point to.

602
00:25:54,800 --> 00:25:58,560
A catalog is what turns PCF from a developer hobby into an enterprise asset.

603
00:25:58,560 --> 00:26:01,840
Without one, every well-built component is still just one person's good work.

604
00:26:01,840 --> 00:26:02,840
It's sitting somewhere.

605
00:26:02,840 --> 00:26:06,640
It's known only to whoever happened to be in the room when it got built with a catalog.

606
00:26:06,640 --> 00:26:09,480
That same component becomes something the whole organization can find.

607
00:26:09,480 --> 00:26:10,480
They can trust it.

608
00:26:10,480 --> 00:26:13,000
They can reuse it without needing to ask around first.

609
00:26:13,000 --> 00:26:17,760
That is the difference between a nice thing someone made and an actual piece of infrastructure.

610
00:26:17,760 --> 00:26:20,760
And the economics behind this are worth stating plainly.

611
00:26:20,760 --> 00:26:23,000
They are not subtle as we walked through earlier.

612
00:26:23,000 --> 00:26:27,920
One well-built dataset grid can replace 50 ad hoc implementations scattered across business

613
00:26:27,920 --> 00:26:29,240
units.

614
00:26:29,240 --> 00:26:32,640
Implementation is built in isolation by teams that didn't know the others existed.

615
00:26:32,640 --> 00:26:36,000
A catalog is the only mechanism that makes that replacement actually happen.

616
00:26:36,000 --> 00:26:38,520
It is not enough for the good grid to exist somewhere.

617
00:26:38,520 --> 00:26:39,800
People have to know it exists.

618
00:26:39,800 --> 00:26:41,600
They have to know it is approved.

619
00:26:41,600 --> 00:26:43,080
They have to know where to find it.

620
00:26:43,080 --> 00:26:46,920
Otherwise, you have just added a 51st implementation to the pile.

621
00:26:46,920 --> 00:26:47,920
Better than the rest.

622
00:26:47,920 --> 00:26:48,920
Sure.

623
00:26:48,920 --> 00:26:51,440
But still invisible to everyone who isn't already in the loop.

624
00:26:51,440 --> 00:26:53,800
Now here's the question that gets skipped constantly.

625
00:26:53,800 --> 00:26:57,160
And it is the one that decides whether any of this actually holds.

626
00:26:57,160 --> 00:27:01,000
Someone has to own this catalog, not the team in some vague collective sense, a person

627
00:27:01,000 --> 00:27:05,560
or a small group, whose actual job includes deciding what gets added, what gets deprecated,

628
00:27:05,560 --> 00:27:07,880
and what gets rejected when it doesn't meet the bar.

629
00:27:07,880 --> 00:27:08,880
Without that ownership.

630
00:27:08,880 --> 00:27:10,680
A catalog doesn't stay a catalog for long.

631
00:27:10,680 --> 00:27:15,560
It decays exactly the way the original's brawl decayed, quietly, through neglect.

632
00:27:15,560 --> 00:27:19,320
Until nobody is sure if the thing listed in there is even the current version anymore,

633
00:27:19,320 --> 00:27:21,200
because a catalog is not a one-time deliverable.

634
00:27:21,200 --> 00:27:24,960
It is a living structure, and living structures need someone accountable for keeping them

635
00:27:24,960 --> 00:27:25,960
alive.

636
00:27:25,960 --> 00:27:30,200
The moment ownership goes unclear, entries go stale, deprecated components, stay listed

637
00:27:30,200 --> 00:27:34,920
as current, and the whole document slides back into being exactly the kind of unreliable

638
00:27:34,920 --> 00:27:37,600
reference the original governance vacuum was full of.

639
00:27:37,600 --> 00:27:40,040
Which brings up the real question underneath ownership.

640
00:27:40,040 --> 00:27:42,080
How does a catalog actually stay alive?

641
00:27:42,080 --> 00:27:44,400
Mechanically, day to day, version to version?

642
00:27:44,400 --> 00:27:45,720
That is not a policy question.

643
00:27:45,720 --> 00:27:47,120
That is an ALM question.

644
00:27:47,120 --> 00:27:50,320
And it is the machinery that keeps this whole thing from decaying the moment everyone gets

645
00:27:50,320 --> 00:27:51,320
busy again.

646
00:27:51,320 --> 00:27:53,800
I'll miss the backbone, not an afterthought.

647
00:27:53,800 --> 00:27:57,160
Let's state this plainly, because it's easy to not along and still miss the point.

648
00:27:57,160 --> 00:28:00,440
PCF without ALM is just custom code with extra steps.

649
00:28:00,440 --> 00:28:02,280
That isn't a critique of the framework itself.

650
00:28:02,280 --> 00:28:05,920
It's a description of what happens when a team treats PCF as a coding exercise instead

651
00:28:05,920 --> 00:28:07,080
of a delivery discipline.

652
00:28:07,080 --> 00:28:08,600
You can write a beautiful component.

653
00:28:08,600 --> 00:28:11,920
It can be structurally sound, performant, and well within scope.

654
00:28:11,920 --> 00:28:15,480
But if that code gets pushed straight into an environment with no process behind it, you

655
00:28:15,480 --> 00:28:16,880
haven't actually gained anything.

656
00:28:16,880 --> 00:28:20,160
You're just repeating the old, undisciplined web resource habits we spent the first half

657
00:28:20,160 --> 00:28:21,560
of this episode taking apart.

658
00:28:21,560 --> 00:28:24,600
You've simply written the same messy deployment in a more modern language.

659
00:28:24,600 --> 00:28:26,680
So what does a real pipeline actually look like?

660
00:28:26,680 --> 00:28:27,880
It starts with source control.

661
00:28:27,880 --> 00:28:31,480
Not a folder on a laptop, not a zip file, emailed around when someone needs the latest

662
00:28:31,480 --> 00:28:32,480
version.

663
00:28:32,480 --> 00:28:34,640
The code lives in a repository with a full history.

664
00:28:34,640 --> 00:28:37,600
Which means you can see exactly what changed and who changed it.

665
00:28:37,600 --> 00:28:39,680
From there, the power platform CLI takes over.

666
00:28:39,680 --> 00:28:43,520
This is the same tool we used earlier for initializing projects and pushing solutions, but

667
00:28:43,520 --> 00:28:46,240
now it isn't a manual step someone runs when they feel like it.

668
00:28:46,240 --> 00:28:48,040
It's part of a defined sequence.

669
00:28:48,040 --> 00:28:49,480
Build validation comes next.

670
00:28:49,480 --> 00:28:53,400
This is an actual check to ensure the component compiles cleanly and doesn't break on the

671
00:28:53,400 --> 00:28:56,800
way out the door before it ever gets near a real environment.

672
00:28:56,800 --> 00:28:59,560
Only after those checks do you push to an environment.

673
00:28:59,560 --> 00:29:03,880
Even then, the code moves through the dev test production path we already established.

674
00:29:03,880 --> 00:29:07,080
Other than landing in front of users just because someone was in a hurry.

675
00:29:07,080 --> 00:29:10,200
There is a reason this sequence matters beyond just being tidy.

676
00:29:10,200 --> 00:29:12,560
This looks more like software engineering than app building.

677
00:29:12,560 --> 00:29:13,560
That isn't an accident.

678
00:29:13,560 --> 00:29:14,960
That's the entire point.

679
00:29:14,960 --> 00:29:17,720
Power platform was sold on the promise that anyone could build.

680
00:29:17,720 --> 00:29:20,760
That promise is still true for a canvas app screen or a simple flow.

681
00:29:20,760 --> 00:29:25,120
But it stops being true the moment you're writing TypeScript, packaging it into a manifest,

682
00:29:25,120 --> 00:29:28,320
and deploying it to production forms that hundreds of people touch.

683
00:29:28,320 --> 00:29:30,360
At that point, you aren't app-building anymore.

684
00:29:30,360 --> 00:29:33,640
You're doing front-end engineering that happens to live inside power platform.

685
00:29:33,640 --> 00:29:37,960
And it needs to be treated with the same seriousness as any other engineering discipline.

686
00:29:37,960 --> 00:29:42,280
Inside that pipeline, one discipline must be non-negotiable, versioning.

687
00:29:42,280 --> 00:29:44,240
Every manifest carries a version number.

688
00:29:44,240 --> 00:29:47,120
That number has to increment before every single solution push.

689
00:29:47,120 --> 00:29:48,960
This isn't bureaucratic box checking.

690
00:29:48,960 --> 00:29:52,720
It's the only thing standing between a controlled update and a silent override.

691
00:29:52,720 --> 00:29:56,640
Without that increment, a new push can replace a component in place, leaving no distinction

692
00:29:56,640 --> 00:29:59,480
between what was there yesterday and what is there now.

693
00:29:59,480 --> 00:30:03,920
With it, every change is traceable. Every rollback has something real to roll back to.

694
00:30:03,920 --> 00:30:08,400
Nobody is left guessing whether the behavior they see today matches what shipped last month.

695
00:30:08,400 --> 00:30:09,800
That's the backbone.

696
00:30:09,800 --> 00:30:14,600
Source control, CLI-driven builds, validation, and versioned pushes.

697
00:30:14,600 --> 00:30:18,160
You move through defined environments instead of skipping straight to production.

698
00:30:18,160 --> 00:30:22,160
But none of this holds together if the environments underneath aren't built to support it.

699
00:30:22,160 --> 00:30:26,440
A pipeline can be flawless on paper and still fail the moment it runs against an environment

700
00:30:26,440 --> 00:30:30,040
strategy that was never designed for this kind of discipline.

701
00:30:30,040 --> 00:30:31,760
Environment strategy as architecture.

702
00:30:31,760 --> 00:30:33,720
Here is the piece that's easy to skip.

703
00:30:33,720 --> 00:30:36,320
Right up until it's the reason everything falls apart.

704
00:30:36,320 --> 00:30:39,400
Managed environments aren't just a feature you turn on because Microsoft recommends it in

705
00:30:39,400 --> 00:30:40,560
the best practices, doc.

706
00:30:40,560 --> 00:30:43,760
They are the container that makes this entire process possible.

707
00:30:43,760 --> 00:30:47,560
Without them, your source control and versioned manifests have nowhere real to land.

708
00:30:47,560 --> 00:30:51,320
You can have the cleanest ALM process on paper, but it means nothing if the environments

709
00:30:51,320 --> 00:30:54,360
you're pushing into don't enforce any boundaries of their own.

710
00:30:54,360 --> 00:30:56,360
Think about what a managed environment actually does.

711
00:30:56,360 --> 00:31:00,440
It's the tool that lets an organization say, with confidence, that an environment has rules

712
00:31:00,440 --> 00:31:04,440
that apply to everyone, sharing limits, data policies, and make-up permissions all sit

713
00:31:04,440 --> 00:31:05,800
at the environment level.

714
00:31:05,800 --> 00:31:09,360
This means a PCF component doesn't just get governance from being in a solution.

715
00:31:09,360 --> 00:31:11,960
It inherits governance from the environment where it lives.

716
00:31:11,960 --> 00:31:13,680
It's two layers reinforcing each other.

717
00:31:13,680 --> 00:31:16,160
Instead of one layer hoping the other one shows up.

718
00:31:16,160 --> 00:31:19,520
There is a specific path the component should move through before it ever touches a real

719
00:31:19,520 --> 00:31:20,520
user.

720
00:31:20,520 --> 00:31:21,520
Dev comes first.

721
00:31:21,520 --> 00:31:25,600
This is where things get built and broken without any risk because nothing in dev is production.

722
00:31:25,600 --> 00:31:26,760
Test comes second.

723
00:31:26,760 --> 00:31:30,280
This is where the component is validated against something other than the assumptions of

724
00:31:30,280 --> 00:31:31,560
the person who wrote it.

725
00:31:31,560 --> 00:31:35,520
Ideally, this happens with someone who wasn't even in the room when the code was written.

726
00:31:35,520 --> 00:31:37,480
And only then do you move to production.

727
00:31:37,480 --> 00:31:40,240
Where the code finally reaches the people who depend on it every day.

728
00:31:40,240 --> 00:31:41,240
That isn't a suggestion.

729
00:31:41,240 --> 00:31:43,640
That is the shape the whole pipeline is built around.

730
00:31:43,640 --> 00:31:45,800
Skipping a step doesn't make the pipeline faster.

731
00:31:45,800 --> 00:31:48,600
It just makes the failure show up later in front of more people.

732
00:31:48,600 --> 00:31:53,000
And that path gets skipped, you hit the default failure mode, someone builds a control and

733
00:31:53,000 --> 00:31:55,200
tests it in their personal sandbox.

734
00:31:55,200 --> 00:31:58,880
They feel good about how it behaves so they push it straight into a shared solution that

735
00:31:58,880 --> 00:32:00,200
other apps already depend on.

736
00:32:00,200 --> 00:32:01,440
There is no test stage.

737
00:32:01,440 --> 00:32:02,680
There is no second set of eyes.

738
00:32:02,680 --> 00:32:05,960
It's just a jump from work on my machine to live in front of the business.

739
00:32:05,960 --> 00:32:08,480
That gap is exactly where the problems we've covered.

740
00:32:08,480 --> 00:32:12,240
The bloated bundles, the re-render issues and the silent overrides actually reach your

741
00:32:12,240 --> 00:32:14,360
users instead of getting caught somewhere safe.

742
00:32:14,360 --> 00:32:17,520
This isn't optional anymore.

743
00:32:17,520 --> 00:32:22,280
Getting into 2026, environment segmentation research is very blunt about this.

744
00:32:22,280 --> 00:32:26,280
Separating environments by purpose with defined promotion paths is the default expectation

745
00:32:26,280 --> 00:32:29,000
for any organization running power platform at scale.

746
00:32:29,000 --> 00:32:31,000
It isn't a luxury for mature teams.

747
00:32:31,000 --> 00:32:35,800
The organization still treating dev, test and production as one blurry space aren't

748
00:32:35,800 --> 00:32:38,640
just behind on a nice to have feature.

749
00:32:38,640 --> 00:32:42,440
They are behind on the baseline once that environment path is actually solid.

750
00:32:42,440 --> 00:32:44,000
Dev test prod.

751
00:32:44,000 --> 00:32:46,280
Each one enforcing its own boundaries.

752
00:32:46,280 --> 00:32:48,960
The conversation naturally moves somewhere else.

753
00:32:48,960 --> 00:32:51,600
It stops being about where components are allowed to live.

754
00:32:51,600 --> 00:32:55,600
It starts being about who is actually allowed to build them in the first place.

755
00:32:55,600 --> 00:32:57,600
The citizen developer isn't the problem.

756
00:32:57,600 --> 00:32:59,080
Who is allowed to build here?

757
00:32:59,080 --> 00:33:03,040
That question usually comes wrapped in a complaint and it is worth pulling that complaint

758
00:33:03,040 --> 00:33:05,120
apart before you accept it.

759
00:33:05,120 --> 00:33:06,720
The complaint goes something like this.

760
00:33:06,720 --> 00:33:08,440
Citizen developers create chaos.

761
00:33:08,440 --> 00:33:12,360
If you give business users too much access, you end up with apps brawl and broken forms.

762
00:33:12,360 --> 00:33:13,480
Nobody knows what is live.

763
00:33:13,480 --> 00:33:15,560
That diagnosis feels reasonable.

764
00:33:15,560 --> 00:33:17,880
But in reality, it is wrong.

765
00:33:17,880 --> 00:33:19,920
And it is worth being direct about why.

766
00:33:19,920 --> 00:33:22,440
Chaos does not come from non-developers having access.

767
00:33:22,440 --> 00:33:23,920
It comes from missing guardrails.

768
00:33:23,920 --> 00:33:28,200
Those are two completely different problems and they call for two completely different fixes.

769
00:33:28,200 --> 00:33:32,880
If the diagnosis is too many people can build things, the fix is restricting access.

770
00:33:32,880 --> 00:33:34,840
You lock down who gets to touch the platform at all.

771
00:33:34,840 --> 00:33:39,680
But if the diagnosis is, there is nothing steering what gets built, the fix is guardrails.

772
00:33:39,680 --> 00:33:42,480
You need catalogs, environment paths and review processes.

773
00:33:42,480 --> 00:33:47,080
You need the structure we have spent, this entire episode, walking through, blame the person

774
00:33:47,080 --> 00:33:51,080
and you shrink the platform, blame the missing structure and you fix the actual problem.

775
00:33:51,080 --> 00:33:54,480
You do this without giving up any of the reach that made low code worth adopting in the

776
00:33:54,480 --> 00:33:55,480
first place.

777
00:33:55,480 --> 00:33:58,560
This is exactly where the federated governance model earns its place.

778
00:33:58,560 --> 00:34:00,680
A central team defines the components and the rules.

779
00:34:00,680 --> 00:34:01,680
They own the catalog.

780
00:34:01,680 --> 00:34:03,120
They own the environment strategy.

781
00:34:03,120 --> 00:34:05,360
They own the review process for what gets approved.

782
00:34:05,360 --> 00:34:08,080
Business units do not get told to figure out governance on their own.

783
00:34:08,080 --> 00:34:11,760
They also do not get told to wait for IT to build every single screen.

784
00:34:11,760 --> 00:34:14,800
They bolt within the structure the central team already put in place.

785
00:34:14,800 --> 00:34:18,800
That is the whole model in one sentence, rules from the center, building from everywhere

786
00:34:18,800 --> 00:34:19,800
else.

787
00:34:19,800 --> 00:34:21,920
Picture what that actually looks like on a given afternoon.

788
00:34:21,920 --> 00:34:24,920
A business analyst needs to show a filtered list of accounts on a form.

789
00:34:24,920 --> 00:34:28,000
This is someone who has never written a line of typescript and never will.

790
00:34:28,000 --> 00:34:32,160
They open the component picker, find the govern dataset grid already sitting in the catalog

791
00:34:32,160 --> 00:34:33,800
and drag it onto their form.

792
00:34:33,800 --> 00:34:34,800
Done.

793
00:34:34,800 --> 00:34:35,800
There is no custom gallery logic.

794
00:34:35,800 --> 00:34:37,640
There are no rebuilt filter conditions.

795
00:34:37,640 --> 00:34:40,920
There is no 51st version of something that already exists 50 times.

796
00:34:40,920 --> 00:34:43,840
It is not a risk event that is not the moment governance failed.

797
00:34:43,840 --> 00:34:47,880
That is the system working exactly the way it was designed to work because the hard part

798
00:34:47,880 --> 00:34:51,320
the part that requires engineering discipline already happened upstream.

799
00:34:51,320 --> 00:34:55,160
It happened before that analyst ever opened the form so the diagnosis holds.

800
00:34:55,160 --> 00:34:57,680
The risk was never that a business analyst could build something.

801
00:34:57,680 --> 00:35:01,800
The risk was ever letting them build without anything approved to build with.

802
00:35:01,800 --> 00:35:04,040
But naming a model does not actually run itself.

803
00:35:04,040 --> 00:35:05,520
Someone has to be the central team.

804
00:35:05,520 --> 00:35:10,040
Someone has to own the catalog, sign off on what gets added and decide what gets deprecated.

805
00:35:10,040 --> 00:35:13,520
A federated model without a clear owner is just a diagram.

806
00:35:13,520 --> 00:35:15,120
And diagrams do not stop chaos.

807
00:35:15,120 --> 00:35:18,960
That ownership question is exactly where this conversation has to go next.

808
00:35:18,960 --> 00:35:23,920
Because it lands squarely on the one role that is supposed to make all of this real.

809
00:35:23,920 --> 00:35:25,760
The Architects new job description.

810
00:35:25,760 --> 00:35:29,920
That ownership question lands on a role that has been quietly changing shape for years.

811
00:35:29,920 --> 00:35:33,040
Power platform Architect used to mean the person who designed the app.

812
00:35:33,040 --> 00:35:34,280
They picked the data model.

813
00:35:34,280 --> 00:35:36,720
Maybe they reviewed a form layout before it shipped.

814
00:35:36,720 --> 00:35:39,480
In this model that job description is mostly wrong now.

815
00:35:39,480 --> 00:35:40,680
Not obsolete, wrong.

816
00:35:40,680 --> 00:35:44,640
It is describing work that has become a minority of what the role actually needs to do.

817
00:35:44,640 --> 00:35:45,640
Here is the split.

818
00:35:45,640 --> 00:35:47,520
Stated as bluntly as it deserves.

819
00:35:47,520 --> 00:35:52,040
Something like 70% of the job is now policy, catalog and pipeline design.

820
00:35:52,040 --> 00:35:55,240
The Architect decides what goes in the catalog and what gets rejected.

821
00:35:55,240 --> 00:35:58,120
They define the environment path a component has to move through.

822
00:35:58,120 --> 00:36:01,400
They set the review bar for what counts as production ready code.

823
00:36:01,400 --> 00:36:04,720
And they write that bar down somewhere other than in their own head.

824
00:36:04,720 --> 00:36:08,760
Screen building, the thing the title used to mean almost entirely, is now the smaller

825
00:36:08,760 --> 00:36:09,760
slice.

826
00:36:09,760 --> 00:36:12,400
Somebody still has to build the flagship components, sure.

827
00:36:12,400 --> 00:36:14,680
But the job stopped being mostly about building.

828
00:36:14,680 --> 00:36:18,120
The moment governance became the thing standing between the tenant that scales and one that

829
00:36:18,120 --> 00:36:19,120
doesn't.

830
00:36:19,120 --> 00:36:23,000
That split creates a skill gap most organizations have not priced in yet.

831
00:36:23,000 --> 00:36:26,560
An Architect who thinks like an app builder asks if the screen works.

832
00:36:26,560 --> 00:36:30,240
An Architect who thinks like a platform engineer asks what happens to every other app if this

833
00:36:30,240 --> 00:36:33,760
component breaks and they want to know how we find out before it happens.

834
00:36:33,760 --> 00:36:34,760
Those are different instincts.

835
00:36:34,760 --> 00:36:36,480
They are built from different experience.

836
00:36:36,480 --> 00:36:40,320
One who has spent a career configuring forms does not automatically know how to evaluate

837
00:36:40,320 --> 00:36:41,320
a build pipeline.

838
00:36:41,320 --> 00:36:45,000
They do not naturally reason about blast radius across a hundred consuming apps.

839
00:36:45,000 --> 00:36:46,560
That is not a knock on anyone's ability.

840
00:36:46,560 --> 00:36:50,480
It is just a real gap between the skills the old title required and the skills this version

841
00:36:50,480 --> 00:36:52,400
of the role actually needs.

842
00:36:52,400 --> 00:36:56,200
Organizations that do not name that gap out loud end up with Architects still doing 2019's

843
00:36:56,200 --> 00:36:57,200
job.

844
00:36:57,200 --> 00:36:59,600
Meanwhile, 2026's problems pile up around them.

845
00:36:59,600 --> 00:37:04,760
Now inside that policy and catalog work sits the piece that actually matters most day-to-day.

846
00:37:04,760 --> 00:37:06,280
Review responsibility.

847
00:37:06,280 --> 00:37:10,120
Every new PCF component anyone proposes is a candidate for the catalog.

848
00:37:10,120 --> 00:37:13,360
This is true whether the person building it thinks of it that way or not, which means

849
00:37:13,360 --> 00:37:15,840
somebody has to actually look at it before it gets in.

850
00:37:15,840 --> 00:37:17,000
This is not a rubber stamp.

851
00:37:17,000 --> 00:37:18,560
It is a real gatekeeping function.

852
00:37:18,560 --> 00:37:20,920
Does it meet the performance bar we walked through earlier?

853
00:37:20,920 --> 00:37:23,280
Does it duplicate something already approved?

854
00:37:23,280 --> 00:37:25,520
Does it introduce a dependency nobody has vetted?

855
00:37:25,520 --> 00:37:29,480
That review is where the catalog either stays trustworthy or slowly fills with components

856
00:37:29,480 --> 00:37:31,400
nobody is confident in anymore.

857
00:37:31,400 --> 00:37:33,360
But here is the limit of that gatekeeping.

858
00:37:33,360 --> 00:37:34,720
And it is worth naming honestly.

859
00:37:34,720 --> 00:37:38,080
A review process only works on things the architect can actually see.

860
00:37:38,080 --> 00:37:41,500
You can gatekeep the front door all day but it does not help if components are getting

861
00:37:41,500 --> 00:37:43,000
deployed through side doors.

862
00:37:43,000 --> 00:37:44,240
Nobody is watching.

863
00:37:44,240 --> 00:37:46,080
Forms get customized directly.

864
00:37:46,080 --> 00:37:49,160
Solutions get pushed without going through the catalog process at all.

865
00:37:49,160 --> 00:37:50,960
Gatekeeping assumes visibility.

866
00:37:50,960 --> 00:37:54,640
Without it you are reviewing a fraction of what is actually running in the tenant and calling

867
00:37:54,640 --> 00:37:55,840
it governance.

868
00:37:55,840 --> 00:37:58,560
Which is exactly the problem that has to get solved next.

869
00:37:58,560 --> 00:38:02,560
Because right now most organizations genuinely do not know what is running where.

870
00:38:02,560 --> 00:38:04,840
Every auditability and the cost of not knowing.

871
00:38:04,840 --> 00:38:06,200
Here is the blunt problem.

872
00:38:06,200 --> 00:38:08,200
Ask most organizations a simple question.

873
00:38:08,200 --> 00:38:09,640
Which apps use which components?

874
00:38:09,640 --> 00:38:10,760
Who actually owns them?

875
00:38:10,760 --> 00:38:11,760
Then watch what happens.

876
00:38:11,760 --> 00:38:12,920
Nobody has a clean answer.

877
00:38:12,920 --> 00:38:15,080
It is not because people are hiding something.

878
00:38:15,080 --> 00:38:17,280
It is because nobody ever built the system to answer it.

879
00:38:17,280 --> 00:38:18,440
There is no single list.

880
00:38:18,440 --> 00:38:22,120
There is only tribal knowledge scattered across whoever happened to build each piece.

881
00:38:22,120 --> 00:38:23,520
And half of those people have moved teams.

882
00:38:23,520 --> 00:38:24,840
They changed roles.

883
00:38:24,840 --> 00:38:26,520
Or they left the company entirely.

884
00:38:26,520 --> 00:38:28,920
The information technically exists somewhere.

885
00:38:28,920 --> 00:38:31,040
Spread across a hundred different memories.

886
00:38:31,040 --> 00:38:33,560
Which means for practical purposes it does not exist at all.

887
00:38:33,560 --> 00:38:36,520
This is exactly why an architect's gatekeeping hits a ceiling.

888
00:38:36,520 --> 00:38:38,440
You cannot review what you cannot see.

889
00:38:38,440 --> 00:38:41,840
And right now most tenants are running components that nobody is tracking.

890
00:38:41,840 --> 00:38:44,120
The research on governance is even blunter.

891
00:38:44,120 --> 00:38:46,320
Visibility is becoming a baseline expectation.

892
00:38:46,320 --> 00:38:49,000
It is not a nice extra for teams with time to spare.

893
00:38:49,000 --> 00:38:50,920
That is the shift you need to sit with.

894
00:38:50,920 --> 00:38:53,960
Inventory used to be something a mature team eventually got around to.

895
00:38:53,960 --> 00:38:55,200
Now it is table stakes.

896
00:38:55,200 --> 00:38:58,080
It is the same way source control became a requirement.

897
00:38:58,080 --> 00:39:00,120
It is no longer an optional best practice.

898
00:39:00,120 --> 00:39:03,680
If you cannot produce a list of what is deployed and who is responsible for it.

899
00:39:03,680 --> 00:39:04,680
You are not just behind.

900
00:39:04,680 --> 00:39:07,600
You are missing a baseline requirement for the modern enterprise.

901
00:39:07,600 --> 00:39:10,200
Now compare that to what a packaged PCF component gives you.

902
00:39:10,200 --> 00:39:11,200
You get it by default.

903
00:39:11,200 --> 00:39:12,440
Without building extra tools.

904
00:39:12,440 --> 00:39:13,440
You know who built it.

905
00:39:13,440 --> 00:39:15,000
You know what version it is on.

906
00:39:15,000 --> 00:39:16,720
You know where it is deployed.

907
00:39:16,720 --> 00:39:17,960
Across which solutions.

908
00:39:17,960 --> 00:39:20,920
Into which environments.

909
00:39:20,920 --> 00:39:23,600
That is not a report someone has to manually assemble.

910
00:39:23,600 --> 00:39:26,200
It is a direct consequence of the packaging discipline.

911
00:39:26,200 --> 00:39:27,600
The manifest versioning.

912
00:39:27,600 --> 00:39:28,840
The solution referencing.

913
00:39:28,840 --> 00:39:30,760
The environment promotion path.

914
00:39:30,760 --> 00:39:34,080
Every one of those steps leaves a trace and those traces add up to an audit trail.

915
00:39:34,080 --> 00:39:36,680
Whether you deliberately designed it to be one or not.

916
00:39:36,680 --> 00:39:38,520
Set that against the web resource era.

917
00:39:38,520 --> 00:39:39,640
The contrast is not subtle.

918
00:39:39,640 --> 00:39:41,760
A JavaScript web resource had none of that.

919
00:39:41,760 --> 00:39:43,080
No required version increment.

920
00:39:43,080 --> 00:39:46,000
No solution dependency forcing it to declare where it lived.

921
00:39:46,000 --> 00:39:48,600
It could sit inside a form quietly doing its job.

922
00:39:48,600 --> 00:39:51,200
The only record of who built it was a comment in the code.

923
00:39:51,200 --> 00:39:53,280
If the developer even bothered to leave one.

924
00:39:53,280 --> 00:39:54,720
Ask who owns it two years later.

925
00:39:54,720 --> 00:39:58,720
The honest answer is usually a shrug that gap between visibility and invisibility does not

926
00:39:58,720 --> 00:39:59,720
stay theoretical.

927
00:39:59,720 --> 00:40:01,760
It becomes urgent at one specific moment.

928
00:40:01,760 --> 00:40:03,480
The second something needs to change.

929
00:40:03,480 --> 00:40:06,800
As long as nothing is changing, nobody notices what they do not know.

930
00:40:06,800 --> 00:40:07,800
But a component review.

931
00:40:07,800 --> 00:40:09,040
A version bump.

932
00:40:09,040 --> 00:40:10,440
A deprecation decision.

933
00:40:10,440 --> 00:40:13,000
All of that requires knowing exactly what is out there.

934
00:40:13,000 --> 00:40:17,040
And that is the problem waiting on the other side of the next change.

935
00:40:17,040 --> 00:40:18,360
The upgrade problem.

936
00:40:18,360 --> 00:40:19,360
Nobody plans for.

937
00:40:19,360 --> 00:40:21,440
So here is that change nobody planned for.

938
00:40:21,440 --> 00:40:23,680
Picture a dataset control that has done its job well.

939
00:40:23,680 --> 00:40:24,680
It is deployed once.

940
00:40:24,680 --> 00:40:27,000
It is now sitting inside 40 different forms.

941
00:40:27,000 --> 00:40:28,720
It spans a dozen different business units.

942
00:40:28,720 --> 00:40:29,720
It works.

943
00:40:29,720 --> 00:40:30,720
People rely on it.

944
00:40:30,720 --> 00:40:32,120
And then a business requirement shows up.

945
00:40:32,120 --> 00:40:34,120
One that cannot be solved without a breaking change.

946
00:40:34,120 --> 00:40:36,360
And you required field a different data shape.

947
00:40:36,360 --> 00:40:38,680
Something that cannot just slide in as a quiet patch.

948
00:40:38,680 --> 00:40:39,760
Here is what that actually means.

949
00:40:39,760 --> 00:40:41,200
This is not a change to one app.

950
00:40:41,200 --> 00:40:44,680
It is a change to every app in form that references that component.

951
00:40:44,680 --> 00:40:45,680
All at once.

952
00:40:45,680 --> 00:40:47,400
The moment the update goes live.

953
00:40:47,400 --> 00:40:48,400
40 forms.

954
00:40:48,400 --> 00:40:49,400
40 different teams.

955
00:40:49,400 --> 00:40:51,240
40 sets of users who never asked for a change.

956
00:40:51,240 --> 00:40:52,240
That is the blast radius.

957
00:40:52,240 --> 00:40:53,240
It is not a metaphor.

958
00:40:53,240 --> 00:40:58,400
It is a literal description of how many places a single line of code will touch.

959
00:40:58,400 --> 00:41:00,560
This is where manifest versioning earns its keep.

960
00:41:00,560 --> 00:41:02,560
But it is from a different angle than before.

961
00:41:02,560 --> 00:41:04,560
Earlier versioning was about traceability.

962
00:41:04,560 --> 00:41:06,160
Knowing what shipped and when.

963
00:41:06,160 --> 00:41:07,560
Here it is about containment.

964
00:41:07,560 --> 00:41:11,360
A properly incremented version means the update does not silently overwrite everything.

965
00:41:11,360 --> 00:41:14,200
It does not break what every consuming app was depending on.

966
00:41:14,200 --> 00:41:18,120
It creates a clear line between the old behavior and the new behavior.

967
00:41:18,120 --> 00:41:21,200
Without that discipline, a breaking change does not announce itself.

968
00:41:21,200 --> 00:41:22,200
It just shows up.

969
00:41:22,200 --> 00:41:26,200
In front of users, they open a form and find something different than what was there yesterday

970
00:41:26,200 --> 00:41:27,760
and then the help desk phone start ringing.

971
00:41:27,760 --> 00:41:30,360
So what does handling this correctly actually look like?

972
00:41:30,360 --> 00:41:32,520
It is not a single push to every environment.

973
00:41:32,520 --> 00:41:35,160
That is the instinct when you are under deadline pressure.

974
00:41:35,160 --> 00:41:36,360
Get it everywhere at once.

975
00:41:36,360 --> 00:41:37,360
Get it done.

976
00:41:37,360 --> 00:41:39,960
That is also how 40 forms break simultaneously.

977
00:41:39,960 --> 00:41:42,040
The correct pattern is a stage rollout.

978
00:41:42,040 --> 00:41:45,000
You move through the managed environment path we already established.

979
00:41:45,000 --> 00:41:46,000
Deferst.

980
00:41:46,000 --> 00:41:47,000
Then test.

981
00:41:47,000 --> 00:41:48,160
Then a limited slicer production.

982
00:41:48,160 --> 00:41:49,840
What's what happens at each stage?

983
00:41:49,840 --> 00:41:53,680
From the forms that depend on its still behave correctly, then let it reach the full set

984
00:41:53,680 --> 00:41:56,360
of apps deliberately in stages.

985
00:41:56,360 --> 00:41:58,640
Do not do it all at once out of impatience.

986
00:41:58,640 --> 00:42:01,040
This moment matters more than almost anything else.

987
00:42:01,040 --> 00:42:04,080
This is the point where governance either proves its value.

988
00:42:04,080 --> 00:42:05,560
Or it falls apart completely.

989
00:42:05,560 --> 00:42:09,640
All the structure from earlier, the catalog, the environment strategy, the review process,

990
00:42:09,640 --> 00:42:11,600
none of it was really being tested until right now.

991
00:42:11,600 --> 00:42:14,440
A catalog is easy to maintain when nothing is changing.

992
00:42:14,440 --> 00:42:17,600
An environment path is easy to respect when there is no pressure.

993
00:42:17,600 --> 00:42:20,800
But an upgrade with a 40 form blast radius is the real test.

994
00:42:20,800 --> 00:42:22,800
That is where the structure either holds.

995
00:42:22,800 --> 00:42:26,600
Or it gets abandoned because someone decided staging was taking too long.

996
00:42:26,600 --> 00:42:29,440
React, fluent UI, and the cost of standing out.

997
00:42:29,440 --> 00:42:32,120
Before you even start building that upgrade, a decision happens.

998
00:42:32,120 --> 00:42:34,800
It happens the moment someone initializes the component.

999
00:42:34,800 --> 00:42:35,800
Standard template.

1000
00:42:35,800 --> 00:42:38,160
Or react based template.

1001
00:42:38,160 --> 00:42:41,040
Most teams treat this like a coin flip or a matter of taste.

1002
00:42:41,040 --> 00:42:44,800
Usually just picking whichever one the last tutorial they watched happened to use.

1003
00:42:44,800 --> 00:42:45,800
But it's not a coin flip.

1004
00:42:45,800 --> 00:42:47,080
It's an architectural decision.

1005
00:42:47,080 --> 00:42:48,880
And it's one worth slowing down for.

1006
00:42:48,880 --> 00:42:50,960
Here is the plain version of why this matters.

1007
00:42:50,960 --> 00:42:54,840
When you build a PCF component on a React template, that component doesn't ship its own copy

1008
00:42:54,840 --> 00:42:56,080
of React to the browser.

1009
00:42:56,080 --> 00:42:59,440
It taps into the React runtime, the platform is already running.

1010
00:42:59,440 --> 00:43:02,960
Every model driven app and every canvas app with code components enabled already has

1011
00:43:02,960 --> 00:43:03,960
React loaded.

1012
00:43:03,960 --> 00:43:06,800
So the platform is already paying that cost once for everything.

1013
00:43:06,800 --> 00:43:10,800
A React based PCF control rides on top of that existing runtime instead of packing its

1014
00:43:10,800 --> 00:43:14,880
own copy into the bundle and shipping it separately to every user who opens the form.

1015
00:43:14,880 --> 00:43:16,720
A standard template component doesn't do that.

1016
00:43:16,720 --> 00:43:18,840
It's not wrong and it's not automatically worse.

1017
00:43:18,840 --> 00:43:20,840
But it's not tapping into anything shared either.

1018
00:43:20,840 --> 00:43:23,200
It's just its own island of code, self-contained.

1019
00:43:23,200 --> 00:43:26,520
Which is fine right up until you have a dozen of these islands on the same form.

1020
00:43:26,520 --> 00:43:30,640
Each one potentially duplicating logic the platform already has sitting right there.

1021
00:43:30,640 --> 00:43:31,640
Unused.

1022
00:43:31,640 --> 00:43:34,520
So here is the architectural point underneath the technical detail.

1023
00:43:34,520 --> 00:43:37,240
Choosing React isn't about which template feels more modern.

1024
00:43:37,240 --> 00:43:41,220
It's about keeping bundle size down because a component that reuses the platforms existing

1025
00:43:41,220 --> 00:43:43,640
runtime is lighter than one that reinvents it.

1026
00:43:43,640 --> 00:43:47,480
And it's about keeping the UI consistent with the rest of the platform because React components

1027
00:43:47,480 --> 00:43:52,320
built this way use the same underlying rendering approach as everything else on that screen.

1028
00:43:52,320 --> 00:43:55,040
That's the same discipline we walked through with bundle bloat earlier.

1029
00:43:55,040 --> 00:43:57,400
Except this time it's not a mistake inside the component.

1030
00:43:57,400 --> 00:44:01,120
It's a structural choice about whether the component plays well with everything around

1031
00:44:01,120 --> 00:44:03,640
it or quietly duplicates what's already there.

1032
00:44:03,640 --> 00:44:07,520
Now the honest trade off pretending this is a free upgrade would be dishonest.

1033
00:44:07,520 --> 00:44:08,760
React adds a learning curve.

1034
00:44:08,760 --> 00:44:11,720
Not everyone building PCF components already knows.

1035
00:44:11,720 --> 00:44:15,560
React, its patterns or its way of thinking about state and rendering.

1036
00:44:15,560 --> 00:44:20,200
That is not a small gap for a team used to standard templates and vanilla typescript.

1037
00:44:20,200 --> 00:44:22,960
Which means choosing React isn't purely a technical call.

1038
00:44:22,960 --> 00:44:24,260
It's a resourcing decision.

1039
00:44:24,260 --> 00:44:25,600
Does the team have that skill?

1040
00:44:25,600 --> 00:44:27,760
Or does it need to build it or hire for it?

1041
00:44:27,760 --> 00:44:32,400
Pretending the learning curve doesn't exist just pushes the cost somewhere less visible

1042
00:44:32,400 --> 00:44:36,760
usually into a component that took three times longer to build than it should have.

1043
00:44:36,760 --> 00:44:39,760
But here is why this decision doesn't stay contained to one control.

1044
00:44:39,760 --> 00:44:43,280
The consistency argument matching the platforms existing rendering approach doesn't stop

1045
00:44:43,280 --> 00:44:45,320
mattering after the first component ships.

1046
00:44:45,320 --> 00:44:46,320
It compounds.

1047
00:44:46,320 --> 00:44:49,880
Every component built the same way adds to a visual and technical language that either

1048
00:44:49,880 --> 00:44:51,880
holds together across the tenant.

1049
00:44:51,880 --> 00:44:54,840
Or starts fragmenting the moment different teams make different choices.

1050
00:44:54,840 --> 00:44:57,520
Which is exactly where the conversation has to go next.

1051
00:44:57,520 --> 00:45:00,720
Because the same question that applies to React applies just as directly to what these

1052
00:45:00,720 --> 00:45:03,520
components actually look like once they are rendered.

1053
00:45:03,520 --> 00:45:05,320
Fluent UI as a governance signal.

1054
00:45:05,320 --> 00:45:09,720
So here is the part of that visual language decision that most teams treat as an afterthought.

1055
00:45:09,720 --> 00:45:11,280
It deserves better than that.

1056
00:45:11,280 --> 00:45:13,240
Using fluent UI isn't a design preference.

1057
00:45:13,240 --> 00:45:14,520
It's a compliance signal.

1058
00:45:14,520 --> 00:45:17,360
Whether anyone building the component thinks of it that way or not.

1059
00:45:17,360 --> 00:45:18,880
Here is what that actually means in practice.

1060
00:45:18,880 --> 00:45:21,680
A component built with fluent UI looks like it belongs.

1061
00:45:21,680 --> 00:45:25,680
Same spacing, same type scale, same interaction patterns, the rest of the platform already

1062
00:45:25,680 --> 00:45:26,680
uses.

1063
00:45:26,680 --> 00:45:30,880
A user opening a form can't tell where the native controls end and the custom one begins.

1064
00:45:30,880 --> 00:45:31,920
And that is exactly the point.

1065
00:45:31,920 --> 00:45:36,200
A component that looks native builds trust automatically without anyone having to argue

1066
00:45:36,200 --> 00:45:37,200
for it.

1067
00:45:37,200 --> 00:45:39,920
And the questions are feel that looks like every other field on the form.

1068
00:45:39,920 --> 00:45:42,000
But a component that looks bolted on.

1069
00:45:42,000 --> 00:45:45,280
Different fonts, different spacing, a button that behaves nothing like the buttons around

1070
00:45:45,280 --> 00:45:46,280
it.

1071
00:45:46,280 --> 00:45:47,280
Invites scrutiny.

1072
00:45:47,280 --> 00:45:48,680
It may not even deserve on the merits.

1073
00:45:48,680 --> 00:45:52,400
Users notice the scene before they notice whether the thing actually works well.

1074
00:45:52,400 --> 00:45:55,000
And once something looks off, it doesn't just get ignored.

1075
00:45:55,000 --> 00:45:56,320
It gets worked around.

1076
00:45:56,320 --> 00:46:00,000
People start avoiding the custom control and building their own shadow version of whatever

1077
00:46:00,000 --> 00:46:01,640
it was supposed to replace.

1078
00:46:01,640 --> 00:46:05,720
Which puts you right back in the sprawl this entire episode has been trying to close.

1079
00:46:05,720 --> 00:46:10,000
Now inside Fluent UI itself, there is a decision architecture teams can't dodge.

1080
00:46:10,000 --> 00:46:11,760
Version 8 versus version 9.

1081
00:46:11,760 --> 00:46:13,080
Different styling.

1082
00:46:13,080 --> 00:46:14,800
Different underlying approach.

1083
00:46:14,800 --> 00:46:18,320
Components build on one don't automatically feel consistent sitting next to components

1084
00:46:18,320 --> 00:46:19,480
built on the other.

1085
00:46:19,480 --> 00:46:22,920
This isn't a detail to leave to whoever happens to be building each component that week.

1086
00:46:22,920 --> 00:46:24,400
It needs a stated position.

1087
00:46:24,400 --> 00:46:28,320
It needs a documented choice about which version the organization is standardizing on.

1088
00:46:28,320 --> 00:46:32,280
The same way the catalog documents, which components are approved in the first place.

1089
00:46:32,280 --> 00:46:37,080
Move it unstated and you end up with some controls that feel like 2019 and others that feel

1090
00:46:37,080 --> 00:46:42,560
current, sitting on the same tenant, sending mixed signals, nobody intended to send.

1091
00:46:42,560 --> 00:46:45,600
Here is where this compounds into something bigger than any one component.

1092
00:46:45,600 --> 00:46:50,320
A 100 components built consistently using the same Fluent version and the same visual language

1093
00:46:50,320 --> 00:46:51,520
readers platform.

1094
00:46:51,520 --> 00:46:55,160
They feel like they were designed by one team with one set of standards even if 40 different

1095
00:46:55,160 --> 00:46:56,960
people built them over three years.

1096
00:46:56,960 --> 00:47:00,040
A 100 components built inconsistently read as risk.

1097
00:47:00,040 --> 00:47:04,200
Because any single one is broken, but because the inconsistency itself is the signal.

1098
00:47:04,200 --> 00:47:05,760
It tells anyone looking.

1099
00:47:05,760 --> 00:47:09,480
Security compliance, a new architect doing an audit that there is no coordinating structure

1100
00:47:09,480 --> 00:47:13,000
behind what has been deployed, which is really what this whole argument has been about

1101
00:47:13,000 --> 00:47:14,320
from the start.

1102
00:47:14,320 --> 00:47:16,960
Visual consistency isn't about aesthetics, it's about trust.

1103
00:47:16,960 --> 00:47:20,280
And trust is the actual currency this entire governance model runs on.

1104
00:47:20,280 --> 00:47:22,520
The trust economy of a governed platform.

1105
00:47:22,520 --> 00:47:24,320
Let's pull back from Fluent UI for a second.

1106
00:47:24,320 --> 00:47:27,240
We need to name what we've actually been talking about this whole time.

1107
00:47:27,240 --> 00:47:31,080
That's the real subject running underneath every part of this episode, whether we use that

1108
00:47:31,080 --> 00:47:33,560
word or not, but here's the reframe worth sitting with.

1109
00:47:33,560 --> 00:47:36,840
A governed PCF strategy isn't what slows down low-code adoption.

1110
00:47:36,840 --> 00:47:39,840
It's what lets leadership say yes to more of it.

1111
00:47:39,840 --> 00:47:43,120
That sounds backwards if you've spent time in an organization where governance is just

1112
00:47:43,120 --> 00:47:45,920
the thing standing between makers and getting stuff done.

1113
00:47:45,920 --> 00:47:48,400
But think about what leadership is actually weighing.

1114
00:47:48,400 --> 00:47:52,880
Every time someone asks for broader access, more environments, more permission to build.

1115
00:47:52,880 --> 00:47:54,880
They aren't weighing the idea of low-code itself.

1116
00:47:54,880 --> 00:47:56,520
They're weighing their last experience with it.

1117
00:47:56,520 --> 00:48:00,640
If that last experience was clean, a component that shipped through the catalog, moved through

1118
00:48:00,640 --> 00:48:04,600
dev and test the way it was supposed to, and behaved exactly as documented.

1119
00:48:04,600 --> 00:48:06,480
Then the next yes becomes easy.

1120
00:48:06,480 --> 00:48:10,360
Governance isn't a tax on adoption, it's the thing that makes adoption, survivable enough

1121
00:48:10,360 --> 00:48:11,680
to keep doing it.

1122
00:48:11,680 --> 00:48:13,920
Because in reality, the opposite is also true.

1123
00:48:13,920 --> 00:48:18,080
Every ungoverned app that breaks in production doesn't just cause one bad afternoon, it makes

1124
00:48:18,080 --> 00:48:20,400
the next approval harder to get.

1125
00:48:20,400 --> 00:48:24,080
Leadership remembers the outage, they remember the emergency call, and they remember explaining

1126
00:48:24,080 --> 00:48:28,840
to their own boss why a form used by hundreds of people just stopped working with no warning

1127
00:48:28,840 --> 00:48:31,880
that memory doesn't stay contained to the one app that broke.

1128
00:48:31,880 --> 00:48:35,800
It attaches itself to the whole category, low-code custom components, anything that sounds

1129
00:48:35,800 --> 00:48:36,800
like it.

1130
00:48:36,800 --> 00:48:40,800
The next request for access gets measured against that memory, not against its own merits.

1131
00:48:40,800 --> 00:48:42,160
Trust doesn't erode evenly.

1132
00:48:42,160 --> 00:48:45,480
It erodes in spikes, and every ungoverned failure is a spike.

1133
00:48:45,480 --> 00:48:49,200
This is where that ROI figure from earlier stops being an abstract statistic and becomes

1134
00:48:49,200 --> 00:48:51,480
the actual mechanism at work.

1135
00:48:51,480 --> 00:48:56,160
Governance that account for technical debt see roughly 29% higher ROI than those that ignore

1136
00:48:56,160 --> 00:48:57,160
it.

1137
00:48:57,160 --> 00:49:00,720
That gap isn't some separate financial curiosity, it's the same conversation.

1138
00:49:00,720 --> 00:49:04,840
Governed platforms produce that ROI gap specifically because trust compounds.

1139
00:49:04,840 --> 00:49:08,360
Every clean rollout buys the next one a little more room, every failure spends that room

1140
00:49:08,360 --> 00:49:09,360
down.

1141
00:49:09,360 --> 00:49:12,720
And this is exactly why security and compliance teams aren't a separate audience anymore.

1142
00:49:12,720 --> 00:49:17,280
PCF governance used to be treated as a developer concern, or maybe an architecture concern,

1143
00:49:17,280 --> 00:49:20,360
but definitely not something compliance needed is seated at the table for it.

1144
00:49:20,360 --> 00:49:21,640
It's no longer accurate.

1145
00:49:21,640 --> 00:49:26,360
The audit trail, the environment segmentation, the version discipline, all of that is compliance

1146
00:49:26,360 --> 00:49:27,360
is story now too.

1147
00:49:27,360 --> 00:49:30,840
It's not adjacent to the work, it is the work, which raises the obvious question, what does

1148
00:49:30,840 --> 00:49:35,280
this actually look like when an organization tries to build it for real, not as a theory,

1149
00:49:35,280 --> 00:49:36,800
but as an actual rollout?

1150
00:49:36,800 --> 00:49:38,440
A realistic rollout pattern.

1151
00:49:38,440 --> 00:49:40,040
So what does an actual rollout look like?

1152
00:49:40,040 --> 00:49:41,040
Stripped of the theory?

1153
00:49:41,040 --> 00:49:44,080
And laid out as something a platform team could genuinely start on Monday?

1154
00:49:44,080 --> 00:49:45,320
There's a pattern to it.

1155
00:49:45,320 --> 00:49:48,400
It's not complicated in concept, even if it's demanding in practice.

1156
00:49:48,400 --> 00:49:49,400
First.

1157
00:49:49,400 --> 00:49:53,480
It's not a guess, but an actual pass through the tenant to see what components are already

1158
00:49:53,480 --> 00:49:54,480
out there.

1159
00:49:54,480 --> 00:49:58,200
You need to see what's duplicated, and what's quietly holding 40 forms together with zero

1160
00:49:58,200 --> 00:50:00,000
documentation behind it.

1161
00:50:00,000 --> 00:50:01,000
Then.

1162
00:50:01,000 --> 00:50:02,000
Define the catalog.

1163
00:50:02,000 --> 00:50:03,000
The real one.

1164
00:50:03,000 --> 00:50:04,000
Versioned and owned.

1165
00:50:04,000 --> 00:50:05,000
Not just a wiki page.

1166
00:50:05,000 --> 00:50:09,040
Then, pilot with one high value component, picks something with enough reach to matter.

1167
00:50:09,040 --> 00:50:10,960
But small enough to get right the first time.

1168
00:50:10,960 --> 00:50:14,920
Only after that pilot proves the pattern works, does the team scale it out further.

1169
00:50:14,920 --> 00:50:16,000
But here's the problem.

1170
00:50:16,000 --> 00:50:17,920
There is attention sitting underneath that sequence.

1171
00:50:17,920 --> 00:50:20,760
And it's what stalls most of these efforts before they even start.

1172
00:50:20,760 --> 00:50:23,200
A platform team wants tenant-wide consistency.

1173
00:50:23,200 --> 00:50:24,440
They want the whole thing.

1174
00:50:24,440 --> 00:50:29,000
DevTestProDiscipline, one catalog, one visual language everywhere right now.

1175
00:50:29,000 --> 00:50:30,440
That's the intention.

1176
00:50:30,440 --> 00:50:34,440
The obstacle is that existing apps brawl doesn't care what the platform team wants.

1177
00:50:34,440 --> 00:50:37,560
There are already hundreds of canvas apps out there.

1178
00:50:37,560 --> 00:50:42,160
Built over years, by people who've since moved teams, using patterns nobody documented,

1179
00:50:42,160 --> 00:50:45,040
you can't consistency your way through that in one pass.

1180
00:50:45,040 --> 00:50:47,440
The obstacle isn't going away just because the intention is good.

1181
00:50:47,440 --> 00:50:49,800
So what's actually happening is a shift in strategy.

1182
00:50:49,800 --> 00:50:52,160
The resolution is less dramatic than most teams expect.

1183
00:50:52,160 --> 00:50:53,480
They don't rebuild everything.

1184
00:50:53,480 --> 00:50:54,480
That's not a shortcut.

1185
00:50:54,480 --> 00:50:57,080
It's the only version of this that's actually achievable.

1186
00:50:57,080 --> 00:50:59,840
Instead, they govern the highest traffic screens first.

1187
00:50:59,840 --> 00:51:01,800
The forms and apps that touch the most people.

1188
00:51:01,800 --> 00:51:05,040
And carry the most risk if something breaks, get the catalog treatment.

1189
00:51:05,040 --> 00:51:07,840
They get the environment path and the review process.

1190
00:51:07,840 --> 00:51:09,160
Everything else waits.

1191
00:51:09,160 --> 00:51:10,640
The catalog grows from there.

1192
00:51:10,640 --> 00:51:12,320
One governed component at a time.

1193
00:51:12,320 --> 00:51:15,280
It expands outward from where the stakes are highest.

1194
00:51:15,280 --> 00:51:18,800
Instead of trying to cover the whole tenant at once and covering none of it well.

1195
00:51:18,800 --> 00:51:22,160
And here's the timeline reality that leadership needs to hear stated plainly.

1196
00:51:22,160 --> 00:51:23,520
This is a multi-quarter shift.

1197
00:51:23,520 --> 00:51:24,520
It's not a sprint.

1198
00:51:24,520 --> 00:51:25,520
It's not a weekend project.

1199
00:51:25,520 --> 00:51:28,320
And it's not something that gets wrapped up before the next budget review.

1200
00:51:28,320 --> 00:51:29,640
Auditing takes time.

1201
00:51:29,640 --> 00:51:31,600
Building a real catalog takes time.

1202
00:51:31,600 --> 00:51:33,520
Piling one component properly.

1203
00:51:33,520 --> 00:51:38,520
Watching it move through dev and test before it touches production takes time.

1204
00:51:38,520 --> 00:51:42,160
Anyone promising this in six weeks is promising something that skips the exact steps that

1205
00:51:42,160 --> 00:51:43,800
make governance worth doing.

1206
00:51:43,800 --> 00:51:47,240
None of this pattern holds if the people funding it don't understand what they're actually

1207
00:51:47,240 --> 00:51:48,240
paying for.

1208
00:51:48,240 --> 00:51:49,760
A multi-quarter rollout.

1209
00:51:49,760 --> 00:51:50,760
Gov.

1210
00:51:50,760 --> 00:51:51,760
One screen at a time.

1211
00:51:51,760 --> 00:51:54,040
Sound slow next to a UI refresh that ships in a week.

1212
00:51:54,040 --> 00:51:57,000
If leadership is expecting the second thing and gets the first.

1213
00:51:57,000 --> 00:52:00,280
The whole effort loses air before the catalog even reaches double digits.

1214
00:52:00,280 --> 00:52:02,000
That's where things change.

1215
00:52:02,000 --> 00:52:04,800
The real next conversation isn't about sequencing anymore.

1216
00:52:04,800 --> 00:52:07,520
It's about making sure the people signing off.

1217
00:52:07,520 --> 00:52:10,840
Understand exactly what this spending actually buys.

1218
00:52:10,840 --> 00:52:12,520
What leadership is really funding.

1219
00:52:12,520 --> 00:52:16,320
Let's name what leadership actually thinks they're approving when this budget request lands

1220
00:52:16,320 --> 00:52:17,600
on their desk.

1221
00:52:17,600 --> 00:52:20,880
Most of the time they hear component library or governance framework.

1222
00:52:20,880 --> 00:52:22,760
They file it mentally under UI project.

1223
00:52:22,760 --> 00:52:23,760
A refresh.

1224
00:52:23,760 --> 00:52:26,120
Something designer Jason nice to have.

1225
00:52:26,120 --> 00:52:28,640
And easy to delay if the quarter gets tight.

1226
00:52:28,640 --> 00:52:29,640
That framing is wrong.

1227
00:52:29,640 --> 00:52:32,320
And it's worth correcting before the request ever gets submitted.

1228
00:52:32,320 --> 00:52:33,320
This isn't a UI project.

1229
00:52:33,320 --> 00:52:35,120
It's platform infrastructure spend.

1230
00:52:35,120 --> 00:52:37,760
It belongs in the same category as your environment strategy.

1231
00:52:37,760 --> 00:52:39,800
The same category as identity management.

1232
00:52:39,800 --> 00:52:43,360
The same category as anything else that has to hold firm before you build a single thing

1233
00:52:43,360 --> 00:52:45,000
on top of it.

1234
00:52:45,000 --> 00:52:49,040
The technical debt research makes the case for this reframe in the planist terms possible.

1235
00:52:49,040 --> 00:52:50,880
Unfunded governance doesn't just disappear.

1236
00:52:50,880 --> 00:52:51,880
It moves.

1237
00:52:51,880 --> 00:52:54,320
It shows up later as unplanned remediation cost.

1238
00:52:54,320 --> 00:52:57,880
This is the exact expense nobody put a line item against because nobody wanted to admit

1239
00:52:57,880 --> 00:52:58,880
it was coming.

1240
00:52:58,880 --> 00:53:01,840
That's the mechanism underneath the ROI numbers we've already covered.

1241
00:53:01,840 --> 00:53:05,000
The gap isn't between spending on governance and not spending at all.

1242
00:53:05,000 --> 00:53:08,120
It's between spending on it now deliberately on a timeline you control.

1243
00:53:08,120 --> 00:53:11,720
Spending on it later urgently on a timeline and outage controls for you.

1244
00:53:11,720 --> 00:53:16,360
Then there's the alternative cost that almost never makes it into the original budget conversation.

1245
00:53:16,360 --> 00:53:20,640
It stays hidden because it's scattered across categories that don't look connected on paper.

1246
00:53:20,640 --> 00:53:22,160
Firefighting broken apps.

1247
00:53:22,160 --> 00:53:26,400
The emergency calls, the after hours fixes, the apology emails to whoever's form just went

1248
00:53:26,400 --> 00:53:27,400
down.

1249
00:53:27,400 --> 00:53:30,720
Security review backlogs happen because nobody cataloged what's actually running so every

1250
00:53:30,720 --> 00:53:34,000
audit starts from zero instead of from a known inventory.

1251
00:53:34,000 --> 00:53:37,280
Shadow 80 workarounds appear because the business units got tired of waiting and built

1252
00:53:37,280 --> 00:53:41,080
their own version of whatever the platform team never got around to governing.

1253
00:53:41,080 --> 00:53:43,640
None of that shows up as a single number leadership can point to.

1254
00:53:43,640 --> 00:53:44,840
It shows up as friction.

1255
00:53:44,840 --> 00:53:49,040
It's spread across a dozen teams and each one absorbs a piece of a cost that was never

1256
00:53:49,040 --> 00:53:50,040
budgeted anywhere.

1257
00:53:50,040 --> 00:53:52,160
So here's the reframe one last time.

1258
00:53:52,160 --> 00:53:54,040
Architecture over UI isn't a design preference.

1259
00:53:54,040 --> 00:53:55,800
It's a funding decision.

1260
00:53:55,800 --> 00:54:00,360
Every dollar spent on the catalog, the environment path and the review process is a dollar spent

1261
00:54:00,360 --> 00:54:05,800
avoiding the much larger, much less predictable bill that shows up when none of that exists.

1262
00:54:05,800 --> 00:54:08,160
Up isn't choosing between spending and not spending.

1263
00:54:08,160 --> 00:54:11,880
They're choosing between a number they control and a number they don't, which leaves one honest

1264
00:54:11,880 --> 00:54:12,880
question.

1265
00:54:12,880 --> 00:54:14,800
What do you actually do with this on Monday morning?

1266
00:54:14,800 --> 00:54:16,440
The blueprint, not the skin.

1267
00:54:16,440 --> 00:54:19,400
Here's the transformation stated as plainly as it deserves.

1268
00:54:19,400 --> 00:54:21,000
PCF stops being a UI trick.

1269
00:54:21,000 --> 00:54:24,760
The moment you start treating it as the enforcement layer for the whole platform.

1270
00:54:24,760 --> 00:54:28,320
It's the thing standing between the tenant that scales and one that quietly comes apart

1271
00:54:28,320 --> 00:54:29,680
under its own apps brawl.

1272
00:54:29,680 --> 00:54:30,960
So here's the direct challenge.

1273
00:54:30,960 --> 00:54:32,640
Don't wait for a framework meeting.

1274
00:54:32,640 --> 00:54:37,200
This week audit one high traffic app not to see how it looks to see who owns its components.

1275
00:54:37,200 --> 00:54:40,640
Ask who built them, ask what they're bound to, ask whether anyone could tell you today

1276
00:54:40,640 --> 00:54:42,360
if that control broke tomorrow.

1277
00:54:42,360 --> 00:54:45,720
If this reframed how you think about power platform governance, leave a review.

1278
00:54:45,720 --> 00:54:47,200
It helps more people find this.

1279
00:54:47,200 --> 00:54:49,760
And if you want to help shape where this goes next.

1280
00:54:49,760 --> 00:54:51,880
Follow me, Mirko Peters on LinkedIn.

1281
00:54:51,880 --> 00:54:55,600
The tenants that scale are the ones that stopped treating components as decoration.