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

2
00:00:05,120 --> 00:00:08,120
Most conversations about power apps start in the wrong place because people want to

3
00:00:08,120 --> 00:00:10,600
debate screens, buttons, or user adoption.

4
00:00:10,600 --> 00:00:15,000
They might talk about automation for a moment, but then they wonder why the app feels unstable

5
00:00:15,000 --> 00:00:16,340
six months later.

6
00:00:16,340 --> 00:00:20,000
If you look closely, the failure rarely starts in the app layer and it actually begins

7
00:00:20,000 --> 00:00:23,360
much deeper in the data foundation that everything else depends on.

8
00:00:23,360 --> 00:00:24,700
This isn't a tool discussion.

9
00:00:24,700 --> 00:00:28,500
This is a system behavior discussion with direct business consequences because Excel and

10
00:00:28,500 --> 00:00:30,720
SharePoint lists feel fast and familiar.

11
00:00:30,720 --> 00:00:34,980
Teams use them as structural compensation for needs they were never built to carry.

12
00:00:34,980 --> 00:00:39,660
The app grows and the process spreads until AI gets added, which makes governance painful

13
00:00:39,660 --> 00:00:42,580
and turns every later fix into expensive rework.

14
00:00:42,580 --> 00:00:46,180
We need to start where the real behavior begins and that means looking underneath the app

15
00:00:46,180 --> 00:00:48,060
at the foundation itself.

16
00:00:48,060 --> 00:00:50,020
The hidden cost pattern most teams miss.

17
00:00:50,020 --> 00:00:53,260
The first mistake most teams make is measuring the wrong kind of cost.

18
00:00:53,260 --> 00:00:56,860
They look at what they already own, noting that Excel and SharePoint are already there and

19
00:00:56,860 --> 00:00:57,860
ready to use.

20
00:00:57,860 --> 00:01:01,020
The list takes five minutes to create while a spreadsheet takes two.

21
00:01:01,020 --> 00:01:04,220
So a canvas app on top of that feels like genuine progress.

22
00:01:04,220 --> 00:01:08,500
From the outside, that looks efficient because the budget stays low and delivery looks quick,

23
00:01:08,500 --> 00:01:10,300
which makes the team feel resourceful.

24
00:01:10,300 --> 00:01:12,660
But that first impression only measures entry cost.

25
00:01:12,660 --> 00:01:17,220
It ignores coordination cost and coordination cost is where fragile systems start charging

26
00:01:17,220 --> 00:01:18,220
interest.

27
00:01:18,220 --> 00:01:21,260
This clicked for me when I saw how often leaders compare data versus to SharePoint as if

28
00:01:21,260 --> 00:01:23,780
the only real variable was the price of the license.

29
00:01:23,780 --> 00:01:27,420
That comparison sounds practical, but it strips out the part of the system that hurts

30
00:01:27,420 --> 00:01:30,980
most later, which is the human effort required to keep it running.

31
00:01:30,980 --> 00:01:34,340
Human effort is not a rounding error and it is exactly where the business pays for weak

32
00:01:34,340 --> 00:01:35,580
structure every single day.

33
00:01:35,580 --> 00:01:39,180
You're not saving money, you're shifting costs from licenses to complexity.

34
00:01:39,180 --> 00:01:40,020
And why is that?

35
00:01:40,020 --> 00:01:43,940
When the foundation can't hold the operating load, the people inside the process start inventing

36
00:01:43,940 --> 00:01:45,940
workarounds to get their jobs done.

37
00:01:45,940 --> 00:01:51,180
They copy data into another list because permissions don't work cleanly or they export to Excel

38
00:01:51,180 --> 00:01:53,700
because the report can't answer a basic question.

39
00:01:53,700 --> 00:01:57,780
They send status updates in email because the source record can't be trusted and eventually

40
00:01:57,780 --> 00:02:02,380
they build their own tracker because the shared one is already drifting from reality.

41
00:02:02,380 --> 00:02:05,460
Now nobody trusts the first record, so a second one appears.

42
00:02:05,460 --> 00:02:06,460
Then a third.

43
00:02:06,460 --> 00:02:09,980
Then someone creates a reconciliation step just to compare all three.

44
00:02:09,980 --> 00:02:13,580
At that point, the organization thinks it has a process problem or a training problem,

45
00:02:13,580 --> 00:02:16,260
but the reality is usually a structural problem.

46
00:02:16,260 --> 00:02:20,340
The architecture made inconsistency cheap, so inconsistency spread throughout the department.

47
00:02:20,340 --> 00:02:22,340
That matters more than most teams admit.

48
00:02:22,340 --> 00:02:25,780
Consistency workarounds become normal, they stop looking like exceptions and start looking

49
00:02:25,780 --> 00:02:27,060
like the actual process.

50
00:02:27,060 --> 00:02:30,860
The business adapts around the weakness and manages ad review meetings because the data

51
00:02:30,860 --> 00:02:32,900
can't speak for itself anymore.

52
00:02:32,900 --> 00:02:36,380
Analysts spend hours checking versions because the status field means something different

53
00:02:36,380 --> 00:02:37,660
in each place.

54
00:02:37,660 --> 00:02:41,780
And operations teams delay decisions because they can't tell which number is current.

55
00:02:41,780 --> 00:02:43,220
It's a system outcome.

56
00:02:43,220 --> 00:02:47,460
And the cost pattern gets worse over time because each local fix adds more surface area

57
00:02:47,460 --> 00:02:48,460
to the problem.

58
00:02:48,460 --> 00:02:52,700
It feels more copies and more side channels appear alongside undocumented logic living in

59
00:02:52,700 --> 00:02:54,140
inboxes and habits.

60
00:02:54,140 --> 00:02:58,020
The system starts negotiating with itself before it can do any useful work, which slows

61
00:02:58,020 --> 00:02:59,700
down every person involved.

62
00:02:59,700 --> 00:03:04,100
This is why familiar tools can feel efficient at the beginning and incredibly expensive later

63
00:03:04,100 --> 00:03:05,100
on.

64
00:03:05,100 --> 00:03:08,860
They reduce startup friction, but they increase dependency on manual coordination and that

65
00:03:08,860 --> 00:03:12,180
trade looks harmless until the process is under real pressure.

66
00:03:12,180 --> 00:03:15,620
Take reporting as an example, a team starts with a simple list, but then another team needs

67
00:03:15,620 --> 00:03:18,340
the same data structure differently, so they duplicate it.

68
00:03:18,340 --> 00:03:22,100
A manager eventually wants a dashboard, but since the key fields aren't consistent, someone

69
00:03:22,100 --> 00:03:25,260
has to clean the export before every single meeting.

70
00:03:25,260 --> 00:03:29,460
Nothing looks catastrophic in the moment, but each report now depends on cleanup work,

71
00:03:29,460 --> 00:03:33,300
which means the business has no real time truth or take approvals.

72
00:03:33,300 --> 00:03:37,620
If the record structure is weak, every approval includes a layer of interpretation that

73
00:03:37,620 --> 00:03:38,620
shouldn't be there.

74
00:03:38,620 --> 00:03:42,660
People ask what version they are looking at or who owns it and they waste time hunting

75
00:03:42,660 --> 00:03:44,900
for the latest attachment or the right list.

76
00:03:44,900 --> 00:03:48,780
The delay isn't caused by the approval itself, but by the system failing to present a clear

77
00:03:48,780 --> 00:03:50,940
state to the person making the decision.

78
00:03:50,940 --> 00:03:52,180
Ownership breaks the same way.

79
00:03:52,180 --> 00:03:56,100
If a customer or a project exists in multiple places, then accountability fragments right

80
00:03:56,100 --> 00:03:57,100
along with it.

81
00:03:57,100 --> 00:04:00,940
Everyone touches the process, but nobody owns the truth and once nobody owns the truth,

82
00:04:00,940 --> 00:04:03,980
every decision gets slower because it starts with validation.

83
00:04:03,980 --> 00:04:06,420
That is the hidden cost pattern most teams miss.

84
00:04:06,420 --> 00:04:10,860
The visible tool stays cheap while the invisible operating cost climbs through labor, rework,

85
00:04:10,860 --> 00:04:11,860
and trust erosion.

86
00:04:11,860 --> 00:04:15,620
Because those costs sit across different departments instead of on one invoice, they rarely

87
00:04:15,620 --> 00:04:18,060
get blamed on the foundation, but they should.

88
00:04:18,060 --> 00:04:21,580
Because before we can talk about data verse properly, we need to separate one thing very

89
00:04:21,580 --> 00:04:22,580
clearly.

90
00:04:22,580 --> 00:04:25,460
Storage is not the same as behavior.

91
00:04:25,460 --> 00:04:28,020
Data verse is not about storage, it is about behavior.

92
00:04:28,020 --> 00:04:31,380
When I tell you that data verse is the right foundation for your business, I'm not starting

93
00:04:31,380 --> 00:04:32,380
with a storage argument.

94
00:04:32,380 --> 00:04:34,220
I'm starting with a behavior argument.

95
00:04:34,220 --> 00:04:37,820
That distinction is vital because most teams hear the word database and immediately reduce

96
00:04:37,820 --> 00:04:39,780
the conversation to where records sit.

97
00:04:39,780 --> 00:04:44,340
They think in containers, imagining this table lives here while that list lives there or that

98
00:04:44,340 --> 00:04:49,340
file sits in a specific folder, but operational systems are not actually defined by where data

99
00:04:49,340 --> 00:04:50,340
rests.

100
00:04:50,340 --> 00:04:54,380
They are defined by what the structure permits, what it blocks, what it remembers, and

101
00:04:54,380 --> 00:04:57,700
what it enforces while your people are actually doing the work.

102
00:04:57,700 --> 00:05:00,420
Data verse matters because it does much more than hold records.

103
00:05:00,420 --> 00:05:04,980
It carries rules, it carries relationships, it carries ownership, and it carries identity.

104
00:05:04,980 --> 00:05:09,220
This gives the entire system a way to behave consistently, even when the number of users

105
00:05:09,220 --> 00:05:11,620
processes, records, and automation starts growing.

106
00:05:11,620 --> 00:05:14,020
That is a very different job from a spreadsheet.

107
00:05:14,020 --> 00:05:16,060
And it is also a different job from a list.

108
00:05:16,060 --> 00:05:20,300
A spreadsheet is great when one person needs flexibility and a list is useful when a team

109
00:05:20,300 --> 00:05:21,820
needs lightweight tracking.

110
00:05:21,820 --> 00:05:25,740
But business operations do not stay lightweight for long and the moment multiple teams touch

111
00:05:25,740 --> 00:05:28,180
the same object, the problem changes completely.

112
00:05:28,180 --> 00:05:32,540
Whether it is a customer, a case, an asset, a project, or a request, you no longer need simple

113
00:05:32,540 --> 00:05:33,540
storage.

114
00:05:33,540 --> 00:05:35,940
You need controlled behavior across a shared reality.

115
00:05:35,940 --> 00:05:39,300
This is where data verse changes the game and I use that phrase carefully.

116
00:05:39,300 --> 00:05:42,460
It is not because the tool is flashy but because it changes what the platform can actually

117
00:05:42,460 --> 00:05:43,780
guarantee for the business.

118
00:05:43,780 --> 00:05:46,180
For example, relationships stop being optional.

119
00:05:46,180 --> 00:05:50,580
If an approval belongs to a request, and that request belongs to a project, and the project

120
00:05:50,580 --> 00:05:53,620
belongs to a customer, that structure can be modeled directly.

121
00:05:53,620 --> 00:05:57,420
You are no longer copying customer names across three different places and hoping people spell

122
00:05:57,420 --> 00:05:59,020
them the same way every time.

123
00:05:59,020 --> 00:06:03,220
The context moves through the relationship itself that changes behavior.

124
00:06:03,220 --> 00:06:04,740
What columns change behavior to?

125
00:06:04,740 --> 00:06:09,580
A date is a date, a currency value is a currency value, and a choice is a defined choice.

126
00:06:09,580 --> 00:06:13,980
The system stops accepting vague inputs that look harmless in the moment but become incredibly

127
00:06:13,980 --> 00:06:16,140
expensive six months later.

128
00:06:16,140 --> 00:06:20,540
Validation stops being a polite suggestion and starts becoming part of the operating surface.

129
00:06:20,540 --> 00:06:25,620
Ownership changes behavior, security changes behavior, and audit history changes behavior.

130
00:06:25,620 --> 00:06:30,020
Once the platform knows who can see what, who changed what, and which record belongs to

131
00:06:30,020 --> 00:06:31,060
which process.

132
00:06:31,060 --> 00:06:35,740
The people inside that process stop negotiating basic facts every time they touch the work.

133
00:06:35,740 --> 00:06:36,940
And why is that so important?

134
00:06:36,940 --> 00:06:39,220
Because most friction in business systems is not dramatic.

135
00:06:39,220 --> 00:06:41,380
It is just repetitive ambiguity.

136
00:06:41,380 --> 00:06:43,260
You've probably heard these questions before.

137
00:06:43,260 --> 00:06:44,980
What does this status actually mean?

138
00:06:44,980 --> 00:06:46,460
Which record should I trust?

139
00:06:46,460 --> 00:06:48,260
Who is allowed to update this?

140
00:06:48,260 --> 00:06:50,300
Why does this report show something different?

141
00:06:50,300 --> 00:06:53,380
Was this field changed or was I looking at the wrong version?

142
00:06:53,380 --> 00:06:57,780
Ditorverse reduces that ambiguity by making structure part of the system rather than

143
00:06:57,780 --> 00:06:59,060
part of team memory.

144
00:06:59,060 --> 00:07:00,780
That is the part many people miss.

145
00:07:00,780 --> 00:07:04,620
They compare dataverse to a cheaper storage option and ignore the enforcement layer but the

146
00:07:04,620 --> 00:07:06,340
enforcement layer is the whole point.

147
00:07:06,340 --> 00:07:09,700
If the structure is optional, drift is inevitable and one's drift starts.

148
00:07:09,700 --> 00:07:13,700
Every app, every flow, every report, and every AI experience inherits that instability.

149
00:07:13,700 --> 00:07:15,500
So let me put it simply.

150
00:07:15,500 --> 00:07:17,420
Dataverse does not store your data differently.

151
00:07:17,420 --> 00:07:19,500
It forces your business to behave differently.

152
00:07:19,500 --> 00:07:24,540
It does that by narrowing the space for inconsistency which means fewer duplicate definitions,

153
00:07:24,540 --> 00:07:28,380
fewer side channels and fewer local interpretations of what a record means.

154
00:07:28,380 --> 00:07:32,860
It does not remove complexity from the business but it does remove unnecessary variation from

155
00:07:32,860 --> 00:07:34,500
the system carrying that business.

156
00:07:34,500 --> 00:07:36,180
And that is what good architecture should do.

157
00:07:36,180 --> 00:07:37,620
It should not make things look advanced.

158
00:07:37,620 --> 00:07:39,180
It should make things hold.

159
00:07:39,180 --> 00:07:42,300
If you remember nothing else from this section, remember this.

160
00:07:42,300 --> 00:07:45,460
A data platform is really an operating model in technical form.

161
00:07:45,460 --> 00:07:48,340
It decides whether truth can stay shared when pressure increases.

162
00:07:48,340 --> 00:07:52,820
It decides whether automation runs on clean states or messy guesses and it decides whether

163
00:07:52,820 --> 00:07:55,980
governance feels natural or bolted on later.

164
00:07:55,980 --> 00:07:59,940
Once you see dataverse through that lens, the comparison with SharePoint and Excel becomes

165
00:07:59,940 --> 00:08:00,940
much clearer.

166
00:08:00,940 --> 00:08:03,380
We are no longer asking which tool is easier to start with.

167
00:08:03,380 --> 00:08:08,620
We are asking which foundation can keep the business coherent when the load goes up.

168
00:08:08,620 --> 00:08:11,700
Why familiar tools create fragile systems under pressure?

169
00:08:11,700 --> 00:08:15,020
Now map that to the tools most teams start with.

170
00:08:15,020 --> 00:08:18,900
Excel is a brilliant personal productivity tool and I still use it myself.

171
00:08:18,900 --> 00:08:22,740
Most of us do because it is fast, flexible and forgiving, which is exactly why it works

172
00:08:22,740 --> 00:08:26,900
so well for individual thinking, rough analysis and one-off coordination.

173
00:08:26,900 --> 00:08:29,420
But none of those strengths make it a shared operational backbone.

174
00:08:29,420 --> 00:08:33,260
In fact, the very flexibility people love in Excel becomes a liability once the file turns

175
00:08:33,260 --> 00:08:38,700
into a business dependency because flexibility without enforcement invites silent divergence.

176
00:08:38,700 --> 00:08:42,460
One person adds a column, another changes a formula, someone downloads a copy and someone

177
00:08:42,460 --> 00:08:43,980
else emails a version.

178
00:08:43,980 --> 00:08:46,020
Now the team is not working on a record anymore.

179
00:08:46,020 --> 00:08:49,900
It is working on interpretations of a record that is fine for scratch work, but it is fragile

180
00:08:49,900 --> 00:08:51,300
for operations.

181
00:08:51,300 --> 00:08:55,660
SharePoint lists sit in a slightly different category and this is where people often get confused.

182
00:08:55,660 --> 00:09:00,100
A SharePoint list is more structured than a spreadsheet and for lightweight tracking that matters.

183
00:09:00,100 --> 00:09:04,060
It is useful for collaboration, especially when the process stays close to a single team

184
00:09:04,060 --> 00:09:06,300
with low volume and simple status management.

185
00:09:06,300 --> 00:09:10,460
So I am not arguing that SharePoint is bad, I am saying it has a design center and that

186
00:09:10,460 --> 00:09:15,380
design center is not enterprise relational operations across growing processes, security

187
00:09:15,380 --> 00:09:17,940
boundaries and cross team dependencies.

188
00:09:17,940 --> 00:09:20,220
From a system perspective that is not a criticism.

189
00:09:20,220 --> 00:09:21,500
It is just scope.

190
00:09:21,500 --> 00:09:25,980
The problem starts when the business quietly changes scope, but the foundation does not.

191
00:09:25,980 --> 00:09:30,020
A list that worked perfectly for one team becomes the basis for an app, then another team

192
00:09:30,020 --> 00:09:33,500
needs access, then reporting expands and then approvals become more complex.

193
00:09:33,500 --> 00:09:37,660
Then audit questions arrive, someone wants role-based visibility and an executive asks why

194
00:09:37,660 --> 00:09:40,980
the dashboard does not match what operations sees on the ground.

195
00:09:40,980 --> 00:09:44,380
At that point the system is under pressure and pressure reveals design intent.

196
00:09:44,380 --> 00:09:47,020
The tool is doing exactly what it was set up to do.

197
00:09:47,020 --> 00:09:49,700
It is just not set up for what the business now needs.

198
00:09:49,700 --> 00:09:53,460
This is why fragility appears late, early adoption feels like success.

199
00:09:53,460 --> 00:09:57,700
Because the app launches fast, users engage and everyone feels pragmatic because no premium

200
00:09:57,700 --> 00:09:59,740
decision had to be made up front.

201
00:09:59,740 --> 00:10:03,380
But the success is often misleading because the test conditions were gentle.

202
00:10:03,380 --> 00:10:07,820
Low data volume, limited roles, minimal process branching and few dependencies all make a

203
00:10:07,820 --> 00:10:09,460
weak structure look strong.

204
00:10:09,460 --> 00:10:13,540
Then load increases and load does not just mean more records, it means more joins between

205
00:10:13,540 --> 00:10:18,260
teams, more exceptions in the process, more access rules, more automation, more scrutiny

206
00:10:18,260 --> 00:10:20,500
and more demand for trusted reporting.

207
00:10:20,500 --> 00:10:24,020
A foundation that looked efficient at low pressure starts creating friction everywhere

208
00:10:24,020 --> 00:10:25,020
at once.

209
00:10:25,020 --> 00:10:26,100
Take auditability as an example.

210
00:10:26,100 --> 00:10:30,340
In Excel reconstruction is manual and in SharePoint change history exists, but not with

211
00:10:30,340 --> 00:10:34,820
the same operational depth as a platform built around business data, security and server-side

212
00:10:34,820 --> 00:10:35,820
logic.

213
00:10:35,820 --> 00:10:39,380
When someone asks who changed the field, what the previous value was, and whether that

214
00:10:39,380 --> 00:10:43,540
change affected downstream decisions, the answer often lives across versions, inboxes,

215
00:10:43,540 --> 00:10:44,980
exports and memory.

216
00:10:44,980 --> 00:10:47,420
That is not an audit trail, it is an investigation.

217
00:10:47,420 --> 00:10:51,820
This team access creates the same pattern, SharePoint permissions can work for many scenarios.

218
00:10:51,820 --> 00:10:57,660
But as complexity rises, teams often compensate by creating extra lists, filtered copies or parallel

219
00:10:57,660 --> 00:11:00,460
stores just to manage visibility.

220
00:11:00,460 --> 00:11:04,540
Once access control drives duplication, the security problem becomes a data problem.

221
00:11:04,540 --> 00:11:07,140
Now you do not have one truth with controlled visibility.

222
00:11:07,140 --> 00:11:09,500
You have multiple truths with partial overlap.

223
00:11:09,500 --> 00:11:12,020
That is a single point of failure multiplied.

224
00:11:12,020 --> 00:11:13,620
Analytics exposes the weakness too.

225
00:11:13,620 --> 00:11:17,820
He does ask for one report, but the data shape underneath was never built for relational

226
00:11:17,820 --> 00:11:21,900
reasoning at scale, so analysts start cleaning, mapping and stitching before they can answer

227
00:11:21,900 --> 00:11:22,900
basic questions.

228
00:11:22,900 --> 00:11:26,700
The report may still get delivered, but the operating model behind it is unstable because

229
00:11:26,700 --> 00:11:29,020
every answer depends on reconstruction.

230
00:11:29,020 --> 00:11:31,980
And this is why familiar tools create false confidence.

231
00:11:31,980 --> 00:11:35,740
They lower the barrier to starting, but they do not remove the architectural requirements

232
00:11:35,740 --> 00:11:36,740
of growth.

233
00:11:36,740 --> 00:11:37,740
They postpone them.

234
00:11:37,740 --> 00:11:41,340
Then later when the business depends on the process, every missing structural decision

235
00:11:41,340 --> 00:11:42,420
comes back at once.

236
00:11:42,420 --> 00:11:46,460
The first crack usually appears in the data shape itself, because that is where weak foundations

237
00:11:46,460 --> 00:11:47,780
stop hiding.

238
00:11:47,780 --> 00:11:49,980
Flat data versus relational data.

239
00:11:49,980 --> 00:11:53,460
So let's look at the first structural crack in the foundation, which is the actual shape

240
00:11:53,460 --> 00:11:54,460
of your data.

241
00:11:54,460 --> 00:11:58,420
Flat data feels simple because it puts everything in one place, giving you one row, one record,

242
00:11:58,420 --> 00:12:01,660
and one long list of columns that looks clean at first glance.

243
00:12:01,660 --> 00:12:03,820
A customer name sits right next to the request.

244
00:12:03,820 --> 00:12:07,140
The request sits next to the status and the status sits next to the owner.

245
00:12:07,140 --> 00:12:11,380
Then someone adds project details, approval notes, a region, a cost center, and an asset

246
00:12:11,380 --> 00:12:12,380
ID.

247
00:12:12,380 --> 00:12:16,620
Until suddenly that single row is carrying pieces of five different business objects.

248
00:12:16,620 --> 00:12:20,740
That is the exact moment simplicity turns deceptive because flat data does not preserve

249
00:12:20,740 --> 00:12:21,740
context.

250
00:12:21,740 --> 00:12:25,820
It simply copies it and copying context is where inconsistency begins to rot the system.

251
00:12:25,820 --> 00:12:29,660
If the same customer appears in 50 different records, then that customer's truth now exists

252
00:12:29,660 --> 00:12:30,980
in 50 different places.

253
00:12:30,980 --> 00:12:34,300
If the account manager changes, you don't just update one relationship.

254
00:12:34,300 --> 00:12:38,860
You have to update 50 rows or you update 12 and leave 38 of them completely wrong.

255
00:12:38,860 --> 00:12:43,220
If the region name gets entered slightly differently each time, your reporting starts splitting one business

256
00:12:43,220 --> 00:12:44,940
reality into several fake ones.

257
00:12:44,940 --> 00:12:48,580
North, North region, and N region all have the same business meaning, but because they

258
00:12:48,580 --> 00:12:52,100
are different stored values, you get three different answers in your dashboard.

259
00:12:52,100 --> 00:12:53,500
People usually call that dirty data.

260
00:12:53,500 --> 00:12:55,260
I prefer to call it predictable data.

261
00:12:55,260 --> 00:12:59,100
The structure allowed for repetition where the business actually needed a reference and

262
00:12:59,100 --> 00:13:02,900
this is where relational data changes your entire operating logic.

263
00:13:02,900 --> 00:13:07,540
Instead of copying the customer into every single transaction, you relate the transaction

264
00:13:07,540 --> 00:13:09,300
to that customer one time.

265
00:13:09,300 --> 00:13:13,100
Instead of storing a project name in every approval, you connect the approval to the master

266
00:13:13,100 --> 00:13:14,100
project record.

267
00:13:14,100 --> 00:13:17,180
That might sound technical, but the business effect is simple.

268
00:13:17,180 --> 00:13:20,260
Contacts travels through relationships instead of manual duplication.

269
00:13:20,260 --> 00:13:21,420
And why is that so powerful?

270
00:13:21,420 --> 00:13:25,260
It's powerful because now one single truth can support many different uses without being

271
00:13:25,260 --> 00:13:27,460
rewritten every time the process moves forward.

272
00:13:27,460 --> 00:13:31,700
A one-to-many relationship is the easiest place to see this in action.

273
00:13:31,700 --> 00:13:36,220
One customer can have many cases, one manager can approve many requests and one project can

274
00:13:36,220 --> 00:13:37,500
contain many tasks.

275
00:13:37,500 --> 00:13:41,780
In a flat model, you keep repeating that parent information across every child row, but

276
00:13:41,780 --> 00:13:45,660
in a relational model, the child points back to the parent and the parent carries the shared

277
00:13:45,660 --> 00:13:46,940
truth for everyone.

278
00:13:46,940 --> 00:13:52,020
So when a customer changes their address or a project changes owners or a manager moves

279
00:13:52,020 --> 00:13:55,660
to a new department, you only update the thing that actually changed.

280
00:13:55,660 --> 00:13:59,540
The connected records inherit that context from the relationship itself rather than relying

281
00:13:59,540 --> 00:14:02,300
on a copy-pasted value that is already starting to drift.

282
00:14:02,300 --> 00:14:06,100
Many to many relationships matter just as much, especially once your business reality

283
00:14:06,100 --> 00:14:08,020
stops fitting into tidy little hierarchies.

284
00:14:08,020 --> 00:14:12,260
Think about people assigned to multiple projects, assets linked to multiple service events,

285
00:14:12,260 --> 00:14:15,100
or approvals that involve more than one stakeholder group.

286
00:14:15,100 --> 00:14:19,420
Flat tools usually try to fake this with extra columns, comma-separated values, or duplicate

287
00:14:19,420 --> 00:14:20,420
rows.

288
00:14:20,420 --> 00:14:24,740
But all of those approaches eventually collapse under reporting and security needs because

289
00:14:24,740 --> 00:14:29,500
the relationship exists only in human interpretation, not in the data model.

290
00:14:29,500 --> 00:14:32,820
Dataverse handles this differently because relationships are first-class parts of the

291
00:14:32,820 --> 00:14:33,820
model itself.

292
00:14:33,820 --> 00:14:38,020
Structure acknowledges that business objects depend on each other, which means the system

293
00:14:38,020 --> 00:14:43,260
can reason across records without asking users to recreate meaning in every single field.

294
00:14:43,260 --> 00:14:45,540
This matters in very ordinary everyday scenarios.

295
00:14:45,540 --> 00:14:49,060
A customer record should not have to be rebuilt every time a service case is open.

296
00:14:49,060 --> 00:14:53,140
A project should not carry copied budget labels across every task just so your reporting

297
00:14:53,140 --> 00:14:54,140
can function.

298
00:14:54,140 --> 00:14:57,740
An asset should not be typed into a text field on every inspection if the business needs

299
00:14:57,740 --> 00:15:02,540
to see life cycle history, ownership, and service context later on.

300
00:15:02,540 --> 00:15:05,100
It is the shortcut nobody teaches you.

301
00:15:05,100 --> 00:15:07,780
Relationship design is not some technical luxury for architects.

302
00:15:07,780 --> 00:15:11,780
It is the structural guardrail that prevents the same business truth from fragmenting into

303
00:15:11,780 --> 00:15:13,780
dozens of local broken copies.

304
00:15:13,780 --> 00:15:15,300
I sometimes explain it this way.

305
00:15:15,300 --> 00:15:19,140
Flat data treats every record like a self-contained sentence, while relational data treats

306
00:15:19,140 --> 00:15:21,700
records like connected parts of the same language.

307
00:15:21,700 --> 00:15:25,460
That is why one model scales effortlessly and the other eventually starts contradicting

308
00:15:25,460 --> 00:15:26,460
itself.

309
00:15:26,460 --> 00:15:29,300
And once those relationships matter, your query behavior starts to matter too because

310
00:15:29,300 --> 00:15:33,140
a good structure only helps if the platform can actually reason across the full data set

311
00:15:33,140 --> 00:15:35,820
when people ask real questions.

312
00:15:35,820 --> 00:15:39,140
Delegation, thresholds, and the 5000 item illusion.

313
00:15:39,140 --> 00:15:43,380
Once relationships matter, scale stops being an abstract problem for the future and starts

314
00:15:43,380 --> 00:15:46,060
becoming a truth problem in the present.

315
00:15:46,060 --> 00:15:49,940
This is exactly where many power apps built on SharePoint begin to mislead the people using

316
00:15:49,940 --> 00:15:50,940
them.

317
00:15:50,940 --> 00:15:54,940
The phrase most people here is the 5000 item threshold because they hear that specific

318
00:15:54,940 --> 00:15:59,540
number, they assume the rule is simple, stay under 5000 and you're safe but go over 5000

319
00:15:59,540 --> 00:16:00,540
and things break.

320
00:16:00,540 --> 00:16:04,100
That mental model is wrong and it creates a dangerous kind of false confidence for the

321
00:16:04,100 --> 00:16:05,100
builder.

322
00:16:05,100 --> 00:16:08,660
Because the real issue is not just how many rows exist in the list, the real issue is

323
00:16:08,660 --> 00:16:09,980
where the thinking happens.

324
00:16:09,980 --> 00:16:14,100
If a query can be delegated, the data source does the heavy lifting by filtering, sorting,

325
00:16:14,100 --> 00:16:18,220
and evaluating across the full data set before sending results back to the app.

326
00:16:18,220 --> 00:16:22,780
If the query cannot be delegated, power apps start pulling a limited subset locally and

327
00:16:22,780 --> 00:16:26,940
the reasons over that smaller slice instead in practice that usually means the app only sees

328
00:16:26,940 --> 00:16:31,940
500 rows by default or maybe 2000 if someone went in and manually changed the app settings.

329
00:16:31,940 --> 00:16:33,740
Now pause and think about that for a second.

330
00:16:33,740 --> 00:16:38,180
You might have a list with 18,000 records and when a user opens the app, everything looks

331
00:16:38,180 --> 00:16:39,180
normal.

332
00:16:39,180 --> 00:16:42,180
Search seems to work and the filter returns results but the app may only be evaluating the

333
00:16:42,180 --> 00:16:45,620
first 500 or 2000 records for parts of that logic.

334
00:16:45,620 --> 00:16:49,020
That means the app is not slow in the way we usually think about performance.

335
00:16:49,020 --> 00:16:52,660
It is incomplete and having incomplete data in an operational app is actually the

336
00:16:52,660 --> 00:16:57,420
worst than having visibly broken data because people will act on that information with total

337
00:16:57,420 --> 00:16:58,420
confidence.

338
00:16:58,420 --> 00:17:00,460
This is the 5000 item illusion.

339
00:17:00,460 --> 00:17:03,660
Teams think the threshold is a wall they will eventually hit.

340
00:17:03,660 --> 00:17:06,660
But often it's just a warning sign they've already passed.

341
00:17:06,660 --> 00:17:10,940
The real damage starts much earlier when delegation breaks quietly and the app continues to function

342
00:17:10,940 --> 00:17:13,740
just well enough to hide the underlying problem.

343
00:17:13,740 --> 00:17:17,740
SharePoint can store far more than 5000 items and that part is technically true.

344
00:17:17,740 --> 00:17:22,540
The issue is that large list behavior combined with non-delegable queries in power apps,

345
00:17:22,540 --> 00:17:26,020
changes what the app can reliably know about your business.

346
00:17:26,020 --> 00:17:31,020
Search, complex filters and certain formula choices can push evaluation away from the server

347
00:17:31,020 --> 00:17:32,500
and onto the client device.

348
00:17:32,500 --> 00:17:36,100
Once that happens, the app stops reasoning over the whole truth and starts reasoning over

349
00:17:36,100 --> 00:17:37,340
a random sample.

350
00:17:37,340 --> 00:17:41,780
From a business perspective that is not a technical nuance, it is a massive decision risk.

351
00:17:41,780 --> 00:17:46,540
A manager thinks no high priority request exists because the matching record was sitting

352
00:17:46,540 --> 00:17:48,260
outside the delegated slice.

353
00:17:48,260 --> 00:17:52,780
An operations team thinks an approval queue is clear because the app never evaluated the

354
00:17:52,780 --> 00:17:53,900
full set of data.

355
00:17:53,900 --> 00:17:58,300
A dashboard looks current but the underlying query only considered a fraction of the records.

356
00:17:58,300 --> 00:18:02,620
Now trust starts dropping and nobody can see why because the app still opens and still

357
00:18:02,620 --> 00:18:03,980
appears to be alive.

358
00:18:03,980 --> 00:18:07,660
The people inside the system don't usually say they have a delegation problem.

359
00:18:07,660 --> 00:18:11,220
They say the data feels off or the app misses things or they simply don't trust the

360
00:18:11,220 --> 00:18:12,620
report anymore.

361
00:18:12,620 --> 00:18:14,540
And they are absolutely right to feel that way.

362
00:18:14,540 --> 00:18:17,060
This is why Dataverse changes the conversation entirely.

363
00:18:17,060 --> 00:18:21,820
Dataverse supports full delegation for standard operations like filter, sort, search and

364
00:18:21,820 --> 00:18:23,780
look up across massive data sets.

365
00:18:23,780 --> 00:18:27,460
The app keeps asking the platform to reason at the source, not at the screen which ensures

366
00:18:27,460 --> 00:18:32,300
users get answers based on the full data set rather than whatever subset the client happened

367
00:18:32,300 --> 00:18:33,460
to inspect.

368
00:18:33,460 --> 00:18:36,580
This is also why people underestimate the pain of migration later.

369
00:18:36,580 --> 00:18:40,660
If you build a process on SharePoint and only discover these delegation limits, once the

370
00:18:40,660 --> 00:18:44,180
app is business critical, you aren't just tuning a formula anymore.

371
00:18:44,180 --> 00:18:48,380
You are confronting the fact that your foundation cannot reason at the scale your process now

372
00:18:48,380 --> 00:18:49,940
requires to survive.

373
00:18:49,940 --> 00:18:54,060
And that becomes expensive very fast because scale problems are not only about speed, they

374
00:18:54,060 --> 00:18:56,980
are about maintaining truth under load.

375
00:18:56,980 --> 00:19:01,420
A slow query is frustrating, but a partial answer that looks complete is corrosive to the

376
00:19:01,420 --> 00:19:02,420
organization.

377
00:19:02,420 --> 00:19:06,380
It damages your reporting, your automation and your team's confidence all at the same time.

378
00:19:06,380 --> 00:19:10,020
So when someone tells you SharePoint can hold a lot of data, they are telling you something

379
00:19:10,020 --> 00:19:11,660
that is technically true.

380
00:19:11,660 --> 00:19:14,300
But the real question you should be asking is different.

381
00:19:14,300 --> 00:19:18,900
Can your app think across all of that data, reliably when your decisions depend on it?

382
00:19:18,900 --> 00:19:21,900
If the answer is no, then your storage volume is not a win condition.

383
00:19:21,900 --> 00:19:26,420
It is just proof that the wrong foundation lasted a little bit longer than anyone expected.

384
00:19:26,420 --> 00:19:28,780
Data quality collapse is usually a system outcome.

385
00:19:28,780 --> 00:19:32,940
Once scale starts distorting what your application can see, the next failure usually shows up

386
00:19:32,940 --> 00:19:34,900
in the trust you place in your data.

387
00:19:34,900 --> 00:19:38,260
When this happens most teams look for someone to blame and they almost always point their

388
00:19:38,260 --> 00:19:39,860
fingers at the wrong target.

389
00:19:39,860 --> 00:19:42,020
They blame the user.

390
00:19:42,020 --> 00:19:43,820
We've all heard the complaints before.

391
00:19:43,820 --> 00:19:45,500
Someone picked the wrong status.

392
00:19:45,500 --> 00:19:47,180
Someone forgot to update the owner.

393
00:19:47,180 --> 00:19:50,660
Or someone created a duplicate record for the third time this week.

394
00:19:50,660 --> 00:19:54,100
Maybe someone typed the customer name differently or broke a look up field.

395
00:19:54,100 --> 00:19:57,260
That story feels reasonable because a human being touched the field.

396
00:19:57,260 --> 00:20:01,340
But if your structure makes inconsistency the easiest path, then bad data isn't just a

397
00:20:01,340 --> 00:20:02,340
user error.

398
00:20:02,340 --> 00:20:04,140
It is a predictable output of the design.

399
00:20:04,140 --> 00:20:05,140
It's a system outcome.

400
00:20:05,140 --> 00:20:08,740
I've seen this pattern repeat across dozens of organizations where teams complain that

401
00:20:08,740 --> 00:20:12,580
data quality is tanking yet the model itself accepts almost anything.

402
00:20:12,580 --> 00:20:16,980
You see text fields where a defined choice should exist, free typing where a relationship

403
00:20:16,980 --> 00:20:21,420
should be enforced, and optional fields that the entire process actually depends on.

404
00:20:21,420 --> 00:20:25,420
When you have multiple places to capture the same fact, without a structural rule deciding

405
00:20:25,420 --> 00:20:27,740
which one wins, you aren't managing data.

406
00:20:27,740 --> 00:20:28,940
You're managing chaos.

407
00:20:28,940 --> 00:20:33,580
In that kind of environment, bad data is not an exception to the rule but rather it becomes

408
00:20:33,580 --> 00:20:36,460
the path of least resistance for everyone involved.

409
00:20:36,460 --> 00:20:39,340
Multiquates are the most obvious example of this structural failure.

410
00:20:39,340 --> 00:20:43,820
If a customer can be entered manually every single time a request is created, then duplicates

411
00:20:43,820 --> 00:20:44,820
are not a surprise.

412
00:20:44,820 --> 00:20:46,140
They are almost guaranteed.

413
00:20:46,140 --> 00:20:49,780
One person writes the legal name while another uses the trading name and then someone else

414
00:20:49,780 --> 00:20:53,220
adds an extra space or shortens it to fit a specific screen.

415
00:20:53,220 --> 00:20:57,300
Now your reporting splits one customer into four different versions, your automation misses

416
00:20:57,300 --> 00:21:02,060
critical records, and your team's waste hours asking which account is the real one.

417
00:21:02,060 --> 00:21:05,660
The same thing happens with stale values that lose their meaning over time.

418
00:21:05,660 --> 00:21:09,140
A copied field might look accurate on day one but the moment the source changes and the

419
00:21:09,140 --> 00:21:12,620
copy stays the same you've created a lie in your database.

420
00:21:12,620 --> 00:21:16,980
Status fields drift the same way when different teams interpret the same word differently,

421
00:21:16,980 --> 00:21:22,060
such as when in review means waiting for approval to one group but active work to another.

422
00:21:22,060 --> 00:21:26,180
One label with three different meanings results in a system with no shared state.

423
00:21:26,180 --> 00:21:27,580
That is not a training issue first.

424
00:21:27,580 --> 00:21:32,060
That is architecture debt because if the system does not define meaning tightly enough people

425
00:21:32,060 --> 00:21:36,060
will naturally fill that gap with their own local interpretation and local interpretation

426
00:21:36,060 --> 00:21:39,980
is exactly how data quality collapses the moment you try to scale.

427
00:21:39,980 --> 00:21:44,420
Dataverse changes that pattern by moving quality control directly into the platform itself.

428
00:21:44,420 --> 00:21:48,340
Data types are explicit, relationships are modeled and choices are strictly defined so

429
00:21:48,340 --> 00:21:51,940
that required fields can be enforced before mistake happens.

430
00:21:51,940 --> 00:21:55,540
Business rules can validate inputs before bad records have a chance to spread into your

431
00:21:55,540 --> 00:21:57,700
flows, reports and downstream apps.

432
00:21:57,700 --> 00:22:02,380
The point here is not to make the system feel restrictive but rather to remove whole categories

433
00:22:02,380 --> 00:22:05,420
of cleanup work that never should have existed in the first place.

434
00:22:05,420 --> 00:22:09,660
This is where one source of truth stops being a corporate slogan and starts being a functional

435
00:22:09,660 --> 00:22:10,660
reality.

436
00:22:10,660 --> 00:22:15,300
In a well structured dataverse model the customer record is the only customer record and

437
00:22:15,300 --> 00:22:19,220
every case project or approval points back to that single object.

438
00:22:19,220 --> 00:22:23,060
That means when something changes you change the truth exactly once instead of hunting

439
00:22:23,060 --> 00:22:27,100
through 12 different places where you might miss one and when you commit to that structure

440
00:22:27,100 --> 00:22:30,860
the business starts to see a compounding return on its investment.

441
00:22:30,860 --> 00:22:33,340
You deal with less reconciliation and less manual checking.

442
00:22:33,340 --> 00:22:37,500
You stop correcting the same mistakes every Friday and you finally end the debates about

443
00:22:37,500 --> 00:22:39,580
who spreadsheet is actually current.

444
00:22:39,580 --> 00:22:42,660
That is time back but more importantly it is trust back.

445
00:22:42,660 --> 00:22:46,060
Data quality is not just about technical correctness, it is about whether the people inside

446
00:22:46,060 --> 00:22:49,980
the system believe a record can carry a decision without extra verification.

447
00:22:49,980 --> 00:22:54,500
The moment they stop believing the data they will create side systems like personal lists,

448
00:22:54,500 --> 00:22:57,860
private notes and manual exports to compensate for the failure.

449
00:22:57,860 --> 00:23:02,340
Now your poor data quality is actively generating even more poor data quality in a spiral that

450
00:23:02,340 --> 00:23:04,900
is nearly impossible to stop with policy emails.

451
00:23:04,900 --> 00:23:08,300
That spiral only stops when the model itself narrows the room for inconsistency.

452
00:23:08,300 --> 00:23:12,940
So if your organization is spending hours deduplicating records or fixing broken lookups don't

453
00:23:12,940 --> 00:23:15,140
start by asking who entered the data wrong.

454
00:23:15,140 --> 00:23:16,860
Start by asking a harder question.

455
00:23:16,860 --> 00:23:18,140
What did the structure permit?

456
00:23:18,140 --> 00:23:22,100
Because once data quality improves at the foundation your process speed starts changing

457
00:23:22,100 --> 00:23:26,860
with it and that is where the operating model finally begins to feel different.

458
00:23:26,860 --> 00:23:30,020
Cycle time falls when the system stops negotiating with itself.

459
00:23:30,020 --> 00:23:34,740
Once your data quality improves something else changes that leaders feel almost immediately.

460
00:23:34,740 --> 00:23:36,660
Your cycle time starts to drop.

461
00:23:36,660 --> 00:23:40,220
This doesn't happen because people suddenly started working harder or because the app got

462
00:23:40,220 --> 00:23:41,580
a prettier interface.

463
00:23:41,580 --> 00:23:45,260
Cycle time falls because the system finally stops negotiating with itself before work is allowed

464
00:23:45,260 --> 00:23:46,260
to move forward.

465
00:23:46,260 --> 00:23:49,900
That negotiation is a hidden tax found everywhere in weak architectures.

466
00:23:49,900 --> 00:23:51,740
A request gets submitted.

467
00:23:51,740 --> 00:23:56,900
The owner is unclear so the process stops while somebody asks who is supposed to approve it.

468
00:23:56,900 --> 00:24:00,380
The approver finally opens the record but the status logic is inconsistent so they have

469
00:24:00,380 --> 00:24:04,460
to ask whether the file is actually ready or still missing a key document.

470
00:24:04,460 --> 00:24:08,860
When an attachment lives in one place and comments live in another the process pauses while

471
00:24:08,860 --> 00:24:10,900
people try to reconstruct the context.

472
00:24:10,900 --> 00:24:14,700
None of that looks dramatic on a high level dashboard but together these moments create

473
00:24:14,700 --> 00:24:19,580
a very expensive form of waiting and waiting is usually not a human productivity issue first.

474
00:24:19,580 --> 00:24:22,820
It is a coordination issue produced by the structure of the system.

475
00:24:22,820 --> 00:24:27,140
This is why often tell leaders that slow processes are rarely slow because the work itself is

476
00:24:27,140 --> 00:24:28,140
difficult.

477
00:24:28,140 --> 00:24:31,900
They are slow because the system keeps forcing a human to interpret the data between every

478
00:24:31,900 --> 00:24:33,260
single hand off.

479
00:24:33,260 --> 00:24:37,220
One person enters data, another tries to understand it, a third checks if it can be trusted

480
00:24:37,220 --> 00:24:40,300
and a fourth sends an email to confirm what should have been obvious.

481
00:24:40,300 --> 00:24:44,820
The process is moving technically but it is moving through a thick layer of structural friction.

482
00:24:44,820 --> 00:24:48,620
Dataverse changes that dynamic because it gives power apps and power automate a stable

483
00:24:48,620 --> 00:24:50,580
operational core to work from.

484
00:24:50,580 --> 00:24:55,020
Records have defined shapes, relationships carry their own context and rules enforce the

485
00:24:55,020 --> 00:24:56,700
state of the work at every step.

486
00:24:56,700 --> 00:25:00,220
That means your automation can trigger on something the platform actually trusts and your

487
00:25:00,220 --> 00:25:04,900
people can act on records without revalidating the basics every time they open a screen.

488
00:25:04,900 --> 00:25:09,260
That is a very different operating model from the typical email led approvals and list-driven

489
00:25:09,260 --> 00:25:11,220
workflows we see in most offices.

490
00:25:11,220 --> 00:25:14,220
In weak systems every hand off contains translation work.

491
00:25:14,220 --> 00:25:17,940
In stronger systems the hand off contains state that difference is much bigger than it

492
00:25:17,940 --> 00:25:18,940
sounds.

493
00:25:18,940 --> 00:25:22,980
If a request enters an approval phase in dataverse the record already carries the required fields,

494
00:25:22,980 --> 00:25:25,380
the right parent object and the allowed next status.

495
00:25:25,380 --> 00:25:29,740
Power automate doesn't need to chase clarity through complex side logic or exception handling

496
00:25:29,740 --> 00:25:32,660
because the structure underneath it is already coherent.

497
00:25:32,660 --> 00:25:36,540
So the process gets faster, not because automation replaced the people but because the system

498
00:25:36,540 --> 00:25:39,700
removed the avoidable ambiguity that was slowing them down.

499
00:25:39,700 --> 00:25:42,900
This is the part many teams miss when they talk about automation ROI.

500
00:25:42,900 --> 00:25:47,500
They assume speed comes from replacing manual clicks and while that is sometimes true,

501
00:25:47,500 --> 00:25:51,020
most operational speed comes from removing interpretation loops.

502
00:25:51,020 --> 00:25:54,900
A manual approval is not always slow because a person touched it.

503
00:25:54,900 --> 00:25:59,300
It gets slow when the record arrives incomplete, duplicated or detached from the context needed

504
00:25:59,300 --> 00:26:00,660
to make a choice.

505
00:26:00,660 --> 00:26:05,780
That is why structured entities and one source of truth actually matter for your bottom line.

506
00:26:05,780 --> 00:26:09,580
When those pieces hold your flow design gets simpler your exception handling shrinks and

507
00:26:09,580 --> 00:26:14,420
the process starts behaving more like a pipeline than a messy conversation thread.

508
00:26:14,420 --> 00:26:19,220
I've seen organizations think they need better reminders or stricter SLAs when the real

509
00:26:19,220 --> 00:26:24,780
issue was that the system kept handing people records that still required a phone call to explain.

510
00:26:24,780 --> 00:26:28,980
Once you fix that structural gap, the performance shift can feel disproportionate as days become

511
00:26:28,980 --> 00:26:31,460
hours and rework virtually disappears.

512
00:26:31,460 --> 00:26:34,420
The process stops feeling busy and starts feeling direct.

513
00:26:34,420 --> 00:26:35,420
That is not magic.

514
00:26:35,420 --> 00:26:38,740
It is what happens when the record arrives ready for action.

515
00:26:38,740 --> 00:26:44,060
So if you want faster delivery, don't start by looking at the workflow diagram alone.

516
00:26:44,060 --> 00:26:48,500
Or underneath it by looking at the data shape, the ownership model and the relationship design.

517
00:26:48,500 --> 00:26:53,420
Because process speed is not only an automation question, it is a structural clarity question.

518
00:26:53,420 --> 00:26:57,260
And once that clarity is in place, another layer becomes possible, especially in regulated

519
00:26:57,260 --> 00:27:01,500
environments where speed only matters if you can trust how the work moved.

520
00:27:01,500 --> 00:27:03,860
Auditability changes the operating model.

521
00:27:03,860 --> 00:27:07,180
This is where speed alone stops being enough for a growing business.

522
00:27:07,180 --> 00:27:12,140
In any serious environment, especially once approval start affecting money, contracts

523
00:27:12,140 --> 00:27:15,460
or regulated decisions, the question isn't just how fast the work moved.

524
00:27:15,460 --> 00:27:19,140
The real question is whether the system can actually prove how it moved.

525
00:27:19,140 --> 00:27:22,140
And that shifts the standard for every team involved.

526
00:27:22,140 --> 00:27:26,900
Most teams treat auditability like documentation after the fact, which is usually just something

527
00:27:26,900 --> 00:27:30,300
you try to reconstruct once a problem finally appears.

528
00:27:30,300 --> 00:27:34,700
Someone asks, who changed a specific field when it happened, what the old value was, and

529
00:27:34,700 --> 00:27:38,420
whether the person had the right access to trigger that downstream action.

530
00:27:38,420 --> 00:27:42,300
When the scramble begins as people start digging through file histories, email chains, flow

531
00:27:42,300 --> 00:27:44,900
runs and personal memories to piece it all together.

532
00:27:44,900 --> 00:27:48,460
That isn't governance, it's forensic work triggered by weak infrastructure and it's a massive

533
00:27:48,460 --> 00:27:50,140
drain on resources.

534
00:27:50,140 --> 00:27:53,940
Dataverse changes this dynamic because audit history becomes a built-in memory inside the

535
00:27:53,940 --> 00:27:55,300
operating layer itself.

536
00:27:55,300 --> 00:27:59,860
On most customizable tables, the platform tracks data changes, user activities and security

537
00:27:59,860 --> 00:28:01,340
modifications automatically.

538
00:28:01,340 --> 00:28:04,260
So the record is no longer just a snapshot of the current state.

539
00:28:04,260 --> 00:28:08,700
It carries a permanent trace of how that state was reached, which matters more than most leaders

540
00:28:08,700 --> 00:28:09,700
realize.

541
00:28:09,700 --> 00:28:12,900
Once the platform can answer who changed what and when it happened, several things shift

542
00:28:12,900 --> 00:28:13,900
at once.

543
00:28:13,900 --> 00:28:18,020
Troubleshooting gets faster, security reviews get cleaner, and compliance work stops being

544
00:28:18,020 --> 00:28:20,500
a theatrical performance for auditors.

545
00:28:20,500 --> 00:28:24,740
Operational trust rises because the business no longer needs to reconstruct history from fragments

546
00:28:24,740 --> 00:28:27,060
scattered across five different tools.

547
00:28:27,060 --> 00:28:30,900
And this is where it becomes relevant for anyone responsible for systems.

548
00:28:30,900 --> 00:28:33,500
Think about what this does to your everyday decision making.

549
00:28:33,500 --> 00:28:38,020
If a state has changed unexpectedly, you can simply inspect the history instead of debating

550
00:28:38,020 --> 00:28:40,140
whose version of the truth is right.

551
00:28:40,140 --> 00:28:43,820
If a workflow behaved strangely, the team can trace the record path instead of interviewing

552
00:28:43,820 --> 00:28:45,260
everyone who might have touched it.

553
00:28:45,260 --> 00:28:48,980
The system starts carrying its own evidence, which is a very different operating posture

554
00:28:48,980 --> 00:28:50,620
from reactive reconstruction.

555
00:28:50,620 --> 00:28:55,420
This lowers costs in a way many teams miss, but it's not because audit logs are free.

556
00:28:55,420 --> 00:28:59,060
Dataverse audit logs consume storage and heavy auditing on high-change tables can increase

557
00:28:59,060 --> 00:29:02,340
storage pressure or even slow things down if you enable it carelessly.

558
00:29:02,340 --> 00:29:05,740
This isn't a pitch for turning on every switch forever, but it is an argument for being

559
00:29:05,740 --> 00:29:08,620
intentional about what the business truly needs to remember.

560
00:29:08,620 --> 00:29:11,100
That distinction is vital for a healthy system.

561
00:29:11,100 --> 00:29:15,820
Good audit design is selective, focusing on critical tables, sensitive fields, and meaningful

562
00:29:15,820 --> 00:29:19,100
business events, rather than endless background noise.

563
00:29:19,100 --> 00:29:23,620
Recent platform improvements like per-table storage management and retention policies exist

564
00:29:23,620 --> 00:29:27,700
because Microsoft is effectively telling us that memory has value, but unmanaged memory

565
00:29:27,700 --> 00:29:28,700
has a cost.

566
00:29:28,700 --> 00:29:32,580
Leaders need to think about auditability as infrastructure rather than a checkbox.

567
00:29:32,580 --> 00:29:36,300
You have to ask what the organization must be able to prove and which records carry real

568
00:29:36,300 --> 00:29:37,660
regulatory risk.

569
00:29:37,660 --> 00:29:41,900
You need to decide how long that history stays in dataverse and what should move to long-term

570
00:29:41,900 --> 00:29:43,140
storage for analysis.

571
00:29:43,140 --> 00:29:47,060
Once you ask those questions, governance stops feeling like bureaucracy and starts looking

572
00:29:47,060 --> 00:29:48,780
like capacity planning for trust.

573
00:29:48,780 --> 00:29:52,220
This is where the operating model truly changes in a weak environment audit work only

574
00:29:52,220 --> 00:29:56,660
begins after someone gets suspicious, but in a stronger environment traceability is continuous.

575
00:29:56,660 --> 00:30:00,660
The organization doesn't have to panic and assemble evidence from inboxes because the evidence

576
00:30:00,660 --> 00:30:02,660
is already part of the platform's memory.

577
00:30:02,660 --> 00:30:06,820
It changes how people behave across compliance and leadership because accountability is no

578
00:30:06,820 --> 00:30:08,220
longer a special event.

579
00:30:08,220 --> 00:30:09,220
It's just normal.

580
00:30:09,220 --> 00:30:11,100
There is another effect to consider as well.

581
00:30:11,100 --> 00:30:16,060
When teams know the platform records meaningful changes consistently, those local side channels

582
00:30:16,060 --> 00:30:18,460
and private spreadsheets lose their appeal.

583
00:30:18,460 --> 00:30:22,620
Hidden edits and parallel trackers become harder to justify because the official record

584
00:30:22,620 --> 00:30:24,140
is now the accountable record.

585
00:30:24,140 --> 00:30:26,220
That strength and trust in the model itself.

586
00:30:26,220 --> 00:30:30,420
Disability supports compliance and helps with investigations, but structurally it does

587
00:30:30,420 --> 00:30:31,660
something much deeper.

588
00:30:31,660 --> 00:30:35,780
It gives the system a reliable past and a system with a reliable past can support decisions

589
00:30:35,780 --> 00:30:37,700
with far less friction in the present.

590
00:30:37,700 --> 00:30:41,140
Which brings me to the next layer because one traceability is part of the foundation

591
00:30:41,140 --> 00:30:45,780
governance stops looking like overhead and starts acting like infrastructure.

592
00:30:45,780 --> 00:30:46,780
Governance is not restriction.

593
00:30:46,780 --> 00:30:48,460
It prevents collapse at scale.

594
00:30:48,460 --> 00:30:52,100
This is usually the point where people tense up because the moment you say the word governance,

595
00:30:52,100 --> 00:30:54,060
many teams hear the word delay.

596
00:30:54,060 --> 00:30:58,180
They hear forms approvals and central control from people who are far away from the actual

597
00:30:58,180 --> 00:30:59,180
work being done.

598
00:30:59,180 --> 00:31:03,180
I understand that reaction because bad governance often feels like friction added from

599
00:31:03,180 --> 00:31:06,820
the outside, but that isn't the kind of control and operational platform needs.

600
00:31:06,820 --> 00:31:10,100
It needs structural control that keeps growth from turning into chaos.

601
00:31:10,100 --> 00:31:14,660
In low-code ecosystems, freedom without boundaries doesn't stay innovative for long.

602
00:31:14,660 --> 00:31:19,460
It quickly turns into apps, brawl, duplicated entities and multiple truths trying to answer

603
00:31:19,460 --> 00:31:20,700
the same business question.

604
00:31:20,700 --> 00:31:24,220
For a few months that might look like momentum because you have lots of makers and lots of

605
00:31:24,220 --> 00:31:27,480
apps, then you wake up six months later and nobody knows which app is official, which

606
00:31:27,480 --> 00:31:32,100
flow is safe to change or why two departments have different definitions for the same customer.

607
00:31:32,100 --> 00:31:35,060
That isn't agility, it's unmanaged divergence.

608
00:31:35,060 --> 00:31:39,420
Once that divergence spreads, scale becomes incredibly expensive and risk becomes harder

609
00:31:39,420 --> 00:31:40,580
to see.

610
00:31:40,580 --> 00:31:45,140
Change gets slower because every update might break something hidden and while the organization

611
00:31:45,140 --> 00:31:49,460
thinks it moved fast, it actually just created a larger surface for failure.

612
00:31:49,460 --> 00:31:53,060
Developments in datavers and the power platform should be framed as continuity control.

613
00:31:53,060 --> 00:31:57,460
It's the set of decisions that lets many builders contribute without dissolving the integrity

614
00:31:57,460 --> 00:31:58,900
of the whole system.

615
00:31:58,900 --> 00:32:02,540
Start with your environment strategy, which sounds administrative but is actually a prime

616
00:32:02,540 --> 00:32:05,460
example of governance acting as infrastructure.

617
00:32:05,460 --> 00:32:09,020
Development, test and production environments are not just ceremony.

618
00:32:09,020 --> 00:32:12,780
They are risk boundaries that separate experimentation from reliability.

619
00:32:12,780 --> 00:32:18,140
Without that separation, teams end up testing in live systems and patching directly in production,

620
00:32:18,140 --> 00:32:22,100
which slowly trains the business to accept instability as a normal way of life.

621
00:32:22,100 --> 00:32:26,220
That might feel fast in the moment, but it's expensive later because every live fix teaches

622
00:32:26,220 --> 00:32:28,740
the platform to drift further away from reality.

623
00:32:28,740 --> 00:32:30,980
Then you have data loss prevention policies.

624
00:32:30,980 --> 00:32:35,420
People hear that and think restriction, but DLP is really just a way of deciding which

625
00:32:35,420 --> 00:32:38,940
kinds of data movement the organization will allow to become normal.

626
00:32:38,940 --> 00:32:43,020
If those boundaries are unclear, makers will combine connectors in ways that look harmless

627
00:32:43,020 --> 00:32:45,460
locally but are dangerous globally.

628
00:32:45,460 --> 00:32:49,500
Live data starts crossing services without any shared intent and the problem isn't that

629
00:32:49,500 --> 00:32:50,500
people are careless.

630
00:32:50,500 --> 00:32:54,060
It's that the environment never told them where the safe edges were.

631
00:32:54,060 --> 00:32:56,340
Ownership matters just as much as the technical settings.

632
00:32:56,340 --> 00:33:00,820
If an app exists in production and nobody can clearly answer who owns the flow or the

633
00:33:00,820 --> 00:33:04,180
business definition underneath it, then you don't have a scalable asset.

634
00:33:04,180 --> 00:33:08,780
You have a dependency with unclear accountability and those always fail badly because the governance

635
00:33:08,780 --> 00:33:12,300
questions arrive at the exact moment the operational pressure is highest.

636
00:33:12,300 --> 00:33:14,060
This is why role design is so important.

637
00:33:14,060 --> 00:33:18,260
It's not just about security roles in a technical sense but operational roles regarding who

638
00:33:18,260 --> 00:33:24,260
can build, who can approve and who decides when a local solution becomes enterprise infrastructure.

639
00:33:24,260 --> 00:33:28,140
If those lines stay vague, every successful small app becomes a candidate for accidental

640
00:33:28,140 --> 00:33:29,460
business criticality.

641
00:33:29,460 --> 00:33:30,660
It happens all the time.

642
00:33:30,660 --> 00:33:35,300
A small app solves one team's problem, then another team adopts it, then a flow gets added

643
00:33:35,300 --> 00:33:38,860
and suddenly leadership is referencing a dashboard built on top of it.

644
00:33:38,860 --> 00:33:42,780
The thing that started as a local convenience has become operational infrastructure, but the

645
00:33:42,780 --> 00:33:45,060
governance model never evolved to support it.

646
00:33:45,060 --> 00:33:46,500
That is where the collapse begins.

647
00:33:46,500 --> 00:33:51,020
When leaders resist governance because they fear it will slow down delivery, I usually push

648
00:33:51,020 --> 00:33:53,020
on one specific point.

649
00:33:53,020 --> 00:33:55,180
Unmanaged freedom doesn't actually remove control.

650
00:33:55,180 --> 00:33:59,700
It just relocates that control into hidden places, undocumented logic and silent risk that

651
00:33:59,700 --> 00:34:01,020
you eventually have to pay for.

652
00:34:01,020 --> 00:34:04,700
You still pay for control, you just pay for it late and you usually pay for it during a

653
00:34:04,700 --> 00:34:05,700
major failure.

654
00:34:05,700 --> 00:34:07,620
Good governance pays earlier and loses less.

655
00:34:07,620 --> 00:34:12,260
I see it as business continuity for local platforms because it protects shared definitions,

656
00:34:12,260 --> 00:34:14,420
employment parts and sensitive data.

657
00:34:14,420 --> 00:34:18,220
It protects the people inside the system from inheriting a platform that looks productive

658
00:34:18,220 --> 00:34:21,300
on the surface but is fundamentally unstable underneath.

659
00:34:21,300 --> 00:34:25,140
Once you see it that way, governance stops sounding like a restriction and starts looking

660
00:34:25,140 --> 00:34:26,860
like a load-bearing structure.

661
00:34:26,860 --> 00:34:30,780
That is exactly where the next issue appears because when that structure is weak, security

662
00:34:30,780 --> 00:34:32,100
rarely stays clean.

663
00:34:32,100 --> 00:34:35,980
It starts forcing copies inside systems just to make access work at all.

664
00:34:35,980 --> 00:34:37,580
So here's the question I'd leave you with.

665
00:34:37,580 --> 00:34:41,820
If you audited your governance, the same way you audited your systems, what would you find?

666
00:34:41,820 --> 00:34:46,380
And more importantly, is that system designed to sustain your growth or is it slowly creating

667
00:34:46,380 --> 00:34:49,380
a single point of failure that will drain you over time?

668
00:34:49,380 --> 00:34:52,260
Security that does not force data duplication.

669
00:34:52,260 --> 00:34:56,260
Security is usually the first place where a weak architecture reveals itself.

670
00:34:56,260 --> 00:35:00,340
Because the moment people cannot cleanly control who sees what, they start copying data

671
00:35:00,340 --> 00:35:01,340
to compensate.

672
00:35:01,340 --> 00:35:05,780
A manager might need access to one specific part of a list but not the entire thing, so

673
00:35:05,780 --> 00:35:08,740
someone creates a second list to solve the problem.

674
00:35:08,740 --> 00:35:12,380
Capital teams should only see their own records, so the data gets split by geography into separate

675
00:35:12,380 --> 00:35:13,460
silos.

676
00:35:13,460 --> 00:35:17,260
One department should not view a sensitive field, so the record gets exported, trimmed and

677
00:35:17,260 --> 00:35:19,140
stored in a completely different location.

678
00:35:19,140 --> 00:35:23,020
Now your security problem has transformed into a duplication problem, and as we know in

679
00:35:23,020 --> 00:35:27,420
systems design, duplication always becomes a truth problem later on.

680
00:35:27,420 --> 00:35:30,980
This is one of the most expensive patents I see in operational setups that rely heavily

681
00:35:30,980 --> 00:35:31,980
on SharePoint.

682
00:35:31,980 --> 00:35:35,940
Permissions can absolutely work in SharePoint for basic collaboration, but when teams try

683
00:35:35,940 --> 00:35:41,060
to stretch that model across growing business processes and sensitive data, they often compensate

684
00:35:41,060 --> 00:35:42,820
with structure outside the platform.

685
00:35:42,820 --> 00:35:46,900
You see hidden lists, local copies and team specific trackers appearing everywhere.

686
00:35:46,900 --> 00:35:50,740
These process branches exist only because the original access design could not hold the

687
00:35:50,740 --> 00:35:52,180
model together under pressure.

688
00:35:52,180 --> 00:35:55,900
That is not secure architecture, it is fragmentation disguised as control.

689
00:35:55,900 --> 00:35:59,540
The business consequence is much bigger than most people expect because one security drives

690
00:35:59,540 --> 00:36:00,940
duplication.

691
00:36:00,940 --> 00:36:02,980
Every single copy begins to drift.

692
00:36:02,980 --> 00:36:07,500
One team looks at one version of a customer while another team updates a parallel record,

693
00:36:07,500 --> 00:36:10,860
and eventually a report pulls from the wrong place entirely.

694
00:36:10,860 --> 00:36:14,540
When an automation triggers from a partial data store, your access control has quietly

695
00:36:14,540 --> 00:36:16,540
damaged your operational coherence.

696
00:36:16,540 --> 00:36:20,620
Dataverse changes that pattern because the model can stay whole while visibility changes

697
00:36:20,620 --> 00:36:22,140
based on the user's role.

698
00:36:22,140 --> 00:36:26,620
This is where role-based access control actually becomes a business tool, rather than just

699
00:36:26,620 --> 00:36:27,740
a technical feature.

700
00:36:27,740 --> 00:36:32,140
The same record can exist once inside one controlled model, and different people see different

701
00:36:32,140 --> 00:36:35,900
things based on their team, business unit or specific field permissions.

702
00:36:35,900 --> 00:36:39,900
That is a completely different design outcome from copying a record into five places just

703
00:36:39,900 --> 00:36:41,260
to hide certain parts of it.

704
00:36:41,260 --> 00:36:43,060
So let me put that in business language.

705
00:36:43,060 --> 00:36:44,820
You do not need three versions of the truth.

706
00:36:44,820 --> 00:36:46,900
You need one truth with controlled visibility.

707
00:36:46,900 --> 00:36:50,620
That sounds obvious, but structurally it changes everything for the organization.

708
00:36:50,620 --> 00:36:54,540
Once the data remains centralized, collaboration improves because teams are no longer comparing

709
00:36:54,540 --> 00:36:56,300
separate records during meetings.

710
00:36:56,300 --> 00:37:00,580
Trust improves because every report comes from the same operational object and support

711
00:37:00,580 --> 00:37:05,220
improves because the app logic does not need to chase exceptions across multiple stores.

712
00:37:05,220 --> 00:37:09,060
Security improves because access is enforced at the platform layer instead of through improvised

713
00:37:09,060 --> 00:37:12,300
workarounds that people eventually forget.

714
00:37:12,300 --> 00:37:16,140
Field level security matters here too, especially when a record must stay shared, but specific

715
00:37:16,140 --> 00:37:18,340
parts of it should remain restricted.

716
00:37:18,340 --> 00:37:22,300
Salary information, pricing details and internal risk markers do not always require a separate

717
00:37:22,300 --> 00:37:25,140
process, but they often require a stronger model.

718
00:37:25,140 --> 00:37:29,780
Dataverse supports that stronger model by letting the platform carry visibility rules closer

719
00:37:29,780 --> 00:37:33,860
to the data itself rather than forcing the process to fracture around sensitivity.

720
00:37:33,860 --> 00:37:38,100
And once that happens, something subtle but important changes in how people behave.

721
00:37:38,100 --> 00:37:41,700
Teams stop building parallel systems just to feel safe.

722
00:37:41,700 --> 00:37:45,380
And they stop hoarding private exports because the official system no longer exposes too

723
00:37:45,380 --> 00:37:49,780
much or too little, the record becomes usable across many different roles without becoming

724
00:37:49,780 --> 00:37:51,540
universal in the wrong way.

725
00:37:51,540 --> 00:37:55,220
That is where good security starts reducing complexity instead of adding to it.

726
00:37:55,220 --> 00:37:58,980
Canvas apps connected to many external sources often struggle here because the security

727
00:37:58,980 --> 00:38:01,860
logic gets distributed across too many places.

728
00:38:01,860 --> 00:38:05,300
Part of it lives in the source, part lives in the formulas and another part lives in the

729
00:38:05,300 --> 00:38:06,580
sharing settings.

730
00:38:06,580 --> 00:38:10,500
That can work for a while, but it creates more opportunities for your policy to drift over

731
00:38:10,500 --> 00:38:11,500
time.

732
00:38:11,500 --> 00:38:15,440
Dataverse connected apps and especially model driven apps simplify that by letting the data

733
00:38:15,440 --> 00:38:19,840
layer carry the policy consistently, which brings me to a hard truth that leaders need

734
00:38:19,840 --> 00:38:21,700
to hear early in the process.

735
00:38:21,700 --> 00:38:25,820
If your security model is weak, your data model will fragment to compensate.

736
00:38:25,820 --> 00:38:30,380
Once that fragmentation begins, the cost does not stay trapped inside the security budget.

737
00:38:30,380 --> 00:38:35,220
It spreads into your reporting, your automation, your support, and ultimately your trust in

738
00:38:35,220 --> 00:38:36,220
the system.

739
00:38:36,220 --> 00:38:39,420
Access design is not a side discussion for the IT department.

740
00:38:39,420 --> 00:38:41,940
It is a core part of architectural resilience.

741
00:38:41,940 --> 00:38:44,540
The same question keeps showing up in different forms.

742
00:38:44,540 --> 00:38:48,060
Can the business share one operational reality without breaking control?

743
00:38:48,060 --> 00:38:51,060
If the answer is yes, then scaling the business gets much easier.

744
00:38:51,060 --> 00:38:55,260
If the answer is no, copies will begin multiplying and every copy becomes another slow

745
00:38:55,260 --> 00:38:57,380
failure waiting to surface.

746
00:38:57,380 --> 00:39:00,220
If no one owns the data model, everyone reinvents it.

747
00:39:00,220 --> 00:39:03,820
Once your access is stable, the next fault line appears higher up the stack in the form

748
00:39:03,820 --> 00:39:05,060
of model ownership.

749
00:39:05,060 --> 00:39:08,340
This is where a lot of organizations get into trouble because they treat the data model

750
00:39:08,340 --> 00:39:11,260
like a technical artifact instead of an operating decision.

751
00:39:11,260 --> 00:39:14,980
A table gets created, a few columns get added, and then another team extends it for their

752
00:39:14,980 --> 00:39:15,980
own needs.

753
00:39:15,980 --> 00:39:19,500
A second app needs something similar, so it creates a near copy with slightly different

754
00:39:19,500 --> 00:39:21,340
names to avoid a meeting.

755
00:39:21,340 --> 00:39:24,660
Nobody stops to ask the harder question, which is not whether we can build this, but

756
00:39:24,660 --> 00:39:28,300
who is allowed to define what this thing actually means for the business?

757
00:39:28,300 --> 00:39:31,700
If no one owns the data model, everyone will eventually reinvent it.

758
00:39:31,700 --> 00:39:32,980
That is not just a theory.

759
00:39:32,980 --> 00:39:37,900
It is what happens in almost every fast-moving low-code environment that lacks clear stewardship.

760
00:39:37,900 --> 00:39:42,500
One team calls a record a client while another calls it a customer, and a third uses account

761
00:39:42,500 --> 00:39:44,980
to mean something much narrower.

762
00:39:44,980 --> 00:39:48,980
Status values begin to drift, relationships get approximated, and local fields appear

763
00:39:48,980 --> 00:39:51,700
because they solve immediate pain for one person.

764
00:39:51,700 --> 00:39:55,660
Six months later, reporting cannot reconcile the entities and leaders start hearing different

765
00:39:55,660 --> 00:39:58,940
answers to the same question depending on which app they asked.

766
00:39:58,940 --> 00:40:04,220
That is semantic drift, and semantic drift turns directly into a massive operating cost.

767
00:40:04,220 --> 00:40:08,740
Because once shared objects lose their shared meaning, every integration becomes tedious

768
00:40:08,740 --> 00:40:09,900
translation work.

769
00:40:09,900 --> 00:40:13,660
Every dashboard becomes an argument about definitions instead of a tool for insight, and

770
00:40:13,660 --> 00:40:17,260
every new app starts from field discovery instead of from established truth.

771
00:40:17,260 --> 00:40:21,420
The business thinks it has a tooling problem, but what it really has is a naming and ownership

772
00:40:21,420 --> 00:40:23,300
vacuum with technical symptoms.

773
00:40:23,300 --> 00:40:27,700
Now, some organizations try to solve this by giving ownership fully to the IT department

774
00:40:27,700 --> 00:40:31,740
that can help with consistency, but it creates another risk where IT protects the architecture

775
00:40:31,740 --> 00:40:33,980
while drifting away from process reality.

776
00:40:33,980 --> 00:40:37,460
The tables stay neat and tidy, but the model stops fitting how work actually moves through

777
00:40:37,460 --> 00:40:38,460
the office.

778
00:40:38,460 --> 00:40:42,500
Then, the business starts building around the model instead of through it, and those side

779
00:40:42,500 --> 00:40:44,100
systems return.

780
00:40:44,100 --> 00:40:48,020
Other organizations swing the other way and give ownership fully to the business units.

781
00:40:48,020 --> 00:40:51,980
That sounds empowering on paper, but it often creates the opposite problem where the model

782
00:40:51,980 --> 00:40:55,860
matches local language, but ignores reuse and enterprise consequences.

783
00:40:55,860 --> 00:40:59,420
The structure feels useful right now, but it becomes incredibly expensive to maintain

784
00:40:59,420 --> 00:41:00,420
later.

785
00:41:00,420 --> 00:41:03,220
So the stable path is usually a hybrid form of ownership.

786
00:41:03,220 --> 00:41:04,900
Business ownership of meaning.

787
00:41:04,900 --> 00:41:07,700
Technical ownership of structure, shared ownership of change.

788
00:41:07,700 --> 00:41:12,780
That means process leaders help define what a customer or a project actually is in operational

789
00:41:12,780 --> 00:41:13,780
terms.

790
00:41:13,780 --> 00:41:17,860
Form and architecture leaders then shape how that meaning becomes a durable model inside

791
00:41:17,860 --> 00:41:20,860
dataverse with relationships and life cycle in mind.

792
00:41:20,860 --> 00:41:25,260
One side without the other creates drift, but together you get a model that reflects reality

793
00:41:25,260 --> 00:41:26,460
and can still scale.

794
00:41:26,460 --> 00:41:31,140
This is why naming is not cosmetic and definitions are not just for documentation.

795
00:41:31,140 --> 00:41:34,180
They are executive choices with technical consequences.

796
00:41:34,180 --> 00:41:38,860
If leadership allows every department to define common objects differently, then fragmentation

797
00:41:38,860 --> 00:41:40,220
is not an accident.

798
00:41:40,220 --> 00:41:41,700
It is a funded outcome.

799
00:41:41,700 --> 00:41:44,420
And that outcome spreads quietly through the organization.

800
00:41:44,420 --> 00:41:49,180
A field gets added in one app because nobody wants to sit through a governance meeting.

801
00:41:49,180 --> 00:41:53,260
Another team cannot use it because the meaning is unclear, so they add their own field to

802
00:41:53,260 --> 00:41:54,540
the same table.

803
00:41:54,540 --> 00:41:58,620
Then an integration maps both fields poorly and reporting needs a manual bridge to make sense

804
00:41:58,620 --> 00:41:59,620
of the mess.

805
00:41:59,620 --> 00:42:04,420
Now a tiny naming shortcut has become a structural dependency with a permanent support

806
00:42:04,420 --> 00:42:05,660
cost attached to it.

807
00:42:05,660 --> 00:42:10,460
This is also where data councils and architecture reviews can help, but only if they stay practical

808
00:42:10,460 --> 00:42:11,460
and fast.

809
00:42:11,460 --> 00:42:14,780
The governance turns into abstract committee work, people will simply route around it to

810
00:42:14,780 --> 00:42:16,540
get their jobs done.

811
00:42:16,540 --> 00:42:21,060
But if ownership is visible and tied to actual operating objects, then teams stop reinventing

812
00:42:21,060 --> 00:42:22,820
the same truth under different labels.

813
00:42:22,820 --> 00:42:27,820
So before you try to scale dataverse, ask a very plain question, who owns the business

814
00:42:27,820 --> 00:42:29,340
meaning of the core entities?

815
00:42:29,340 --> 00:42:32,260
I'm not asking who can edit a table or who built the first app.

816
00:42:32,260 --> 00:42:36,980
I am asking who owns the truth those records represent across the entire organization.

817
00:42:36,980 --> 00:42:40,580
Because if that answer stays vague, the platform will still grow and apps will still ship.

818
00:42:40,580 --> 00:42:44,540
And underneath all of it, the model will start splitting into local dialects.

819
00:42:44,540 --> 00:42:49,100
And once that happens, your scale becomes sprawl with better branding.

820
00:42:49,100 --> 00:42:52,740
Environment strategy decides whether growth becomes scale or sprawl.

821
00:42:52,740 --> 00:42:56,820
Once ownership is clear, the next decision is where changes are allowed to happen, because

822
00:42:56,820 --> 00:43:01,580
even a well-owned model can still collapse if the platform grows in random places.

823
00:43:01,580 --> 00:43:05,700
This is why environment strategy matters much earlier than most teams think.

824
00:43:05,700 --> 00:43:10,540
People often treat environments like admin plumbing, calling them dev, test, prod or sandbox.

825
00:43:10,540 --> 00:43:12,980
But from a business perspective, these are not just containers.

826
00:43:12,980 --> 00:43:17,020
They are risk boundaries that decide where experimentation can stay experimental

827
00:43:17,020 --> 00:43:20,380
and where production can stay trusted while the business keeps running.

828
00:43:20,380 --> 00:43:23,100
If you ignore that, growth does not turn into scale.

829
00:43:23,100 --> 00:43:24,300
It turns into sprawl.

830
00:43:24,300 --> 00:43:27,700
sprawl in power platform is sneaky because it often begins with good intentions

831
00:43:27,700 --> 00:43:29,980
when someone needs to solve a real problem fast.

832
00:43:29,980 --> 00:43:34,020
They build in the default environment because it is there, then another team does the same

833
00:43:34,020 --> 00:43:36,940
and eventually a maker leaves while an app keeps running.

834
00:43:36,940 --> 00:43:41,500
A flow still triggers and a connection belongs to someone who changed roles six months ago

835
00:43:41,500 --> 00:43:44,140
creating a fragmented system that nobody planned.

836
00:43:44,140 --> 00:43:47,820
The platform fragments because the system allowed local convenience to become

837
00:43:47,820 --> 00:43:49,500
the permanent operating structure.

838
00:43:49,500 --> 00:43:50,660
That is a system outcome.

839
00:43:50,660 --> 00:43:52,820
The reason environment strategy matters is simple.

840
00:43:52,820 --> 00:43:55,740
Innovation needs boundaries if you want it to become repeatable.

841
00:43:55,740 --> 00:43:59,340
Without those boundaries, every app becomes its own little island of assumptions,

842
00:43:59,340 --> 00:44:02,020
connectors, permissions and undocumented choices.

843
00:44:02,020 --> 00:44:04,580
That can look productive from the outside because things are getting built,

844
00:44:04,580 --> 00:44:07,340
but inside the platform trust starts thinning out.

845
00:44:07,340 --> 00:44:12,580
Support teams cannot see clear release paths, security teams cannot see where sensitive data is moving

846
00:44:12,580 --> 00:44:15,820
and business owners cannot tell which app is the one that actually matters

847
00:44:15,820 --> 00:44:17,980
and once trust drops, speed drops right after it.

848
00:44:17,980 --> 00:44:19,500
So let me take one step back.

849
00:44:19,500 --> 00:44:23,420
A healthy environment strategy usually starts with one basic principle.

850
00:44:23,420 --> 00:44:27,260
Development is not production and production should never behave like development

851
00:44:27,260 --> 00:44:29,900
just because nobody wanted administrative friction.

852
00:44:29,900 --> 00:44:33,260
That means having a place to build, a place to test and a place to run.

853
00:44:33,260 --> 00:44:35,820
We do this not because process theatre looks mature,

854
00:44:35,820 --> 00:44:38,660
but because every system needs a safe way to absorb change

855
00:44:38,660 --> 00:44:41,260
without teaching the business to expect instability.

856
00:44:41,260 --> 00:44:44,060
When teams skip that separation, they create silent coupling.

857
00:44:44,060 --> 00:44:46,620
A maker changes the table directly in a live environment,

858
00:44:46,620 --> 00:44:50,180
a flow gets updated to fix one issue while quietly breaking another.

859
00:44:50,180 --> 00:44:53,460
And a connection reference behaves differently than expected.

860
00:44:53,460 --> 00:44:56,260
The app still opens, so everyone assumes the change was safe

861
00:44:56,260 --> 00:44:58,980
until a downstream process fails two days later.

862
00:44:58,980 --> 00:45:01,060
Now the organization is not only dealing with a bug,

863
00:45:01,060 --> 00:45:04,220
but it is also dealing with the fact that nobody can clearly explain

864
00:45:04,220 --> 00:45:06,860
how change entered production in the first place.

865
00:45:06,860 --> 00:45:09,260
That is not scale, that is operational gambling.

866
00:45:09,260 --> 00:45:11,780
The default environment deserves special attention here

867
00:45:11,780 --> 00:45:14,660
because it becomes a fragmentation engine in many tenants.

868
00:45:14,660 --> 00:45:17,260
It feels convenient and lowers the barrier to entry,

869
00:45:17,260 --> 00:45:20,700
but if serious apps and business critical automation start accumulating there

870
00:45:20,700 --> 00:45:24,780
without a clear policy, the platform slowly loses architectural shape.

871
00:45:24,780 --> 00:45:29,180
Dependencies get buried, ownership blurs and governance has to discover assets

872
00:45:29,180 --> 00:45:31,660
after they already matter, which is always late.

873
00:45:31,660 --> 00:45:34,060
A stronger approach is not to stop people from building,

874
00:45:34,060 --> 00:45:36,900
but to root that building through intentional lanes.

875
00:45:36,900 --> 00:45:39,540
Personal productivity use cases can stay lightweight,

876
00:45:39,540 --> 00:45:43,060
while team experiments live in managed spaces with visibility.

877
00:45:43,060 --> 00:45:45,260
Shared production apps move through environments

878
00:45:45,260 --> 00:45:47,140
with clear ownership and deployment parts,

879
00:45:47,140 --> 00:45:50,420
which is how experimentation becomes enterprise capability

880
00:45:50,420 --> 00:45:52,380
instead of accidental infrastructure.

881
00:45:52,380 --> 00:45:55,020
There is also a compliance angle people underestimate.

882
00:45:55,020 --> 00:45:57,340
Environment design affects where data sits,

883
00:45:57,340 --> 00:46:00,740
how policies apply and how confidently changes can be reviewed.

884
00:46:00,740 --> 00:46:02,740
So environment strategy is not just for admins,

885
00:46:02,740 --> 00:46:05,940
it shapes supportability, audit posture and executive confidence

886
00:46:05,940 --> 00:46:08,420
in whether the platform can grow without becoming opaque.

887
00:46:08,420 --> 00:46:10,420
If you remember one thing here, remember this,

888
00:46:10,420 --> 00:46:12,780
unmanaged environments do not create agility.

889
00:46:12,780 --> 00:46:16,220
They create hidden dependencies that only become visible during failure.

890
00:46:16,220 --> 00:46:17,740
So before the next app gets built,

891
00:46:17,740 --> 00:46:19,780
leaders need to answer a plain question.

892
00:46:19,780 --> 00:46:21,420
Where are people allowed to experiment?

893
00:46:21,420 --> 00:46:24,380
Where are they allowed to test and where is the business allowed to depend?

894
00:46:24,380 --> 00:46:26,500
Because when those boundaries stay vague,

895
00:46:26,500 --> 00:46:28,820
scale does not emerge from growth.

896
00:46:28,820 --> 00:46:29,820
Sprull does.

897
00:46:29,820 --> 00:46:32,060
Without ALM, every update is a gamble.

898
00:46:32,060 --> 00:46:33,340
Once environments are clear,

899
00:46:33,340 --> 00:46:35,100
the next pressure point is change itself.

900
00:46:35,100 --> 00:46:37,460
Even with a strong model and sensible boundaries,

901
00:46:37,460 --> 00:46:39,260
the platform still has to evolve.

902
00:46:39,260 --> 00:46:42,380
New fields get added, flows change, security roles shift,

903
00:46:42,380 --> 00:46:45,380
and a rule that worked last quarter no longer fits the process now.

904
00:46:45,380 --> 00:46:47,460
Change is normal, but the risk begins when change

905
00:46:47,460 --> 00:46:49,420
has no controlled path into production.

906
00:46:49,420 --> 00:46:52,460
That is where ALM enters, and I want to keep this very plain.

907
00:46:52,460 --> 00:46:54,940
Application lifecycle management is just the discipline

908
00:46:54,940 --> 00:46:56,300
of moving change safely.

909
00:46:56,300 --> 00:46:58,940
Not eventually, and not when the platform gets big enough,

910
00:46:58,940 --> 00:47:00,620
but from the moment something matters.

911
00:47:00,620 --> 00:47:02,700
Without ALM, every fix is personal.

912
00:47:02,700 --> 00:47:04,900
A maker edits directly in production.

913
00:47:04,900 --> 00:47:07,500
Someone patches a flow because users are waiting,

914
00:47:07,500 --> 00:47:10,220
or a table gets changed to support a local request.

915
00:47:10,220 --> 00:47:12,100
It works, or it seems to work,

916
00:47:12,100 --> 00:47:15,780
but nobody can say with confidence what changed or what depends on it.

917
00:47:15,780 --> 00:47:18,460
There is no way to know if it was tested somewhere safe first,

918
00:47:18,460 --> 00:47:21,260
or how to go back if the update creates damage two hours later.

919
00:47:21,260 --> 00:47:22,860
That is not low-code agility.

920
00:47:22,860 --> 00:47:24,220
That is fragile release behavior.

921
00:47:24,220 --> 00:47:25,700
And why is that so dangerous?

922
00:47:25,700 --> 00:47:28,380
Because low-code creates a false sense of safety.

923
00:47:28,380 --> 00:47:32,020
The interface feels accessible, so people assume the consequences stay small,

924
00:47:32,020 --> 00:47:34,220
but a production power app tied to dataverse

925
00:47:34,220 --> 00:47:36,420
and reporting is still a live business system.

926
00:47:36,420 --> 00:47:39,260
If you edit it carelessly, the business absorbs the risk

927
00:47:39,260 --> 00:47:42,340
whether the change came from a traditional developer or a citizen maker.

928
00:47:42,340 --> 00:47:44,540
The system does not care who clicked save.

929
00:47:44,540 --> 00:47:46,500
It only reflects whether change was controlled.

930
00:47:46,500 --> 00:47:48,940
This is why solutions matter, versioning matters,

931
00:47:48,940 --> 00:47:51,420
and a defined deployment path matters.

932
00:47:51,420 --> 00:47:54,060
These are not developer rituals imported from somewhere else.

933
00:47:54,060 --> 00:47:57,220
They are how you keep a platform trustworthy once people depend on it.

934
00:47:57,220 --> 00:48:00,340
In power platform terms, that means packaging components properly

935
00:48:00,340 --> 00:48:04,300
and moving them between development, test, and production in a predictable way.

936
00:48:04,300 --> 00:48:07,300
Because if you do not package change, you cannot govern change.

937
00:48:07,300 --> 00:48:09,900
And if you cannot govern change, you cannot scale confidence.

938
00:48:09,900 --> 00:48:13,460
I've seen teams move quickly for months by editing apps directly where they run.

939
00:48:13,460 --> 00:48:17,020
It feels efficient, right up until the moment a field rename breaks a flow

940
00:48:17,020 --> 00:48:21,580
or a rushed fix solves one pain while creating three hidden ones downstream.

941
00:48:21,580 --> 00:48:26,140
Then everyone suddenly wants documentation, rollback, and testing after the failure has already happened.

942
00:48:26,140 --> 00:48:29,540
But those things only work well when they exist before the incident.

943
00:48:29,540 --> 00:48:30,620
That is the hard lesson.

944
00:48:30,620 --> 00:48:33,540
Delivery speed without release discipline creates downtime debt.

945
00:48:33,540 --> 00:48:34,980
You may not see that debt in month one,

946
00:48:34,980 --> 00:48:38,220
but you feel it in month nine when production changes become stressful

947
00:48:38,220 --> 00:48:40,100
and support teams lose confidence.

948
00:48:40,100 --> 00:48:43,820
Business owners start saying, "Please do not touch anything until after quarter end,

949
00:48:43,820 --> 00:48:46,820
which is a sign that the operating model has become defensive."

950
00:48:46,820 --> 00:48:49,940
That is usually the sign that trust in releases has already been damaged.

951
00:48:49,940 --> 00:48:51,500
So what does a better path look like?

952
00:48:51,500 --> 00:48:55,180
Build in development, validate in test, and promote to production intentionally.

953
00:48:55,180 --> 00:48:58,580
Use versioning so you know what changed and use managed release paths

954
00:48:58,580 --> 00:49:00,260
so rollback stays possible.

955
00:49:00,260 --> 00:49:03,460
Treat apps, flows, and schema as one moving asset,

956
00:49:03,460 --> 00:49:06,660
not as disconnected edits scattered across makers and environments.

957
00:49:06,660 --> 00:49:09,860
That is what turns low code from convenience into infrastructure.

958
00:49:09,860 --> 00:49:12,780
And there is another point leaders should hear clearly.

959
00:49:12,780 --> 00:49:16,420
Low code without ALM does not stay simpler than custom code.

960
00:49:16,420 --> 00:49:19,900
It often recreates the same fragility with friendlier screens.

961
00:49:19,900 --> 00:49:22,540
Hidden logic, undocumented dependencies,

962
00:49:22,540 --> 00:49:26,660
and personal knowledge sitting inside one builder's head create a single point of failure.

963
00:49:26,660 --> 00:49:29,180
It just arrived wearing a productivity story.

964
00:49:29,180 --> 00:49:32,100
So if your platform is already supporting live operations,

965
00:49:32,100 --> 00:49:34,540
ALM is not optional maturity for later.

966
00:49:34,540 --> 00:49:36,780
It is the condition for making change safe now

967
00:49:36,780 --> 00:49:38,740
because once the business depends on the app,

968
00:49:38,740 --> 00:49:41,340
every update already carries operational risk.

969
00:49:41,340 --> 00:49:44,340
The only real question is whether your release model acknowledges that risk

970
00:49:44,340 --> 00:49:46,580
or keeps pretending every edit is harmless.

971
00:49:46,580 --> 00:49:49,820
Why model driven apps reveal the value of dataverse fastest?

972
00:49:49,820 --> 00:49:53,220
Once you have ALM under control, the next hurdle is purely practical.

973
00:49:53,220 --> 00:49:55,820
You have to make the value of dataverse visible quickly

974
00:49:55,820 --> 00:50:00,620
or the organization will keep treating it like an expensive, abstract platform choice.

975
00:50:00,620 --> 00:50:02,300
For most enterprise teams I work with,

976
00:50:02,300 --> 00:50:05,180
the fastest way to bridge that gap is through model driven apps.

977
00:50:05,180 --> 00:50:05,900
And why is that?

978
00:50:05,900 --> 00:50:09,020
It's because model driven apps start exactly where the real work starts

979
00:50:09,020 --> 00:50:10,300
with the data model itself.

980
00:50:10,300 --> 00:50:11,500
While that sounds simple,

981
00:50:11,500 --> 00:50:14,780
it fundamentally shifts the conversation from the very first day.

982
00:50:14,780 --> 00:50:17,860
In a canvas app, you can actually hide a weak structure for a long time

983
00:50:17,860 --> 00:50:18,980
by designing around it.

984
00:50:18,980 --> 00:50:23,580
You might build a polished screen or use complex formulas to mask inconsistencies,

985
00:50:23,580 --> 00:50:27,300
making fragmented data sources feel coherent for a single user session.

986
00:50:27,300 --> 00:50:28,740
That flexibility has its place,

987
00:50:28,740 --> 00:50:30,460
but it often delays the moment of truth

988
00:50:30,460 --> 00:50:33,380
while the foundation stays messy underneath a pretty interface.

989
00:50:33,380 --> 00:50:36,820
Model driven apps take the opposite approach, they expose the model.

990
00:50:36,820 --> 00:50:38,900
Forms are generated from tables,

991
00:50:38,900 --> 00:50:43,380
views emerge from relationships and dashboards pull from that same govern structure.

992
00:50:43,380 --> 00:50:46,860
Because the business logic sits right next to the record instead of being scattered

993
00:50:46,860 --> 00:50:49,180
across screen behaviors, the app becomes useful,

994
00:50:49,180 --> 00:50:50,740
the moment the model is strong.

995
00:50:50,740 --> 00:50:51,820
If the model is weak,

996
00:50:51,820 --> 00:50:53,700
that failure becomes visible immediately,

997
00:50:53,700 --> 00:50:55,780
which is actually a massive system advantage.

998
00:50:55,780 --> 00:50:58,340
The platform stops letting us confuse a nice interface

999
00:50:58,340 --> 00:50:59,980
with actual operational quality.

1000
00:50:59,980 --> 00:51:02,140
This is why I tell leadership that model driven apps

1001
00:51:02,140 --> 00:51:04,180
reveal the truth of dataverse fastest.

1002
00:51:04,180 --> 00:51:07,340
They force everyone to confront the factors that actually determine scale,

1003
00:51:07,340 --> 00:51:10,020
like whether the business has agreed on entities, ownership,

1004
00:51:10,020 --> 00:51:13,780
and roles clearly enough for the platform to generate a usable surface.

1005
00:51:13,780 --> 00:51:15,940
Once those structural pieces are in place,

1006
00:51:15,940 --> 00:51:19,780
the system handles the heavy lifting without the usual custom coding effort.

1007
00:51:19,780 --> 00:51:22,500
You get standardized forms for updating records and views

1008
00:51:22,500 --> 00:51:25,740
that ensure every team is looking at the same filtered reality.

1009
00:51:25,740 --> 00:51:28,300
By layering in business rules and process flows,

1010
00:51:28,300 --> 00:51:32,020
the app starts guiding human behavior instead of just displaying empty fields.

1011
00:51:32,020 --> 00:51:34,380
That is where the value becomes concrete for the business.

1012
00:51:34,380 --> 00:51:36,020
It isn't about a flashy UI,

1013
00:51:36,020 --> 00:51:38,900
it's about the operating model finally showing up on the screen.

1014
00:51:38,900 --> 00:51:43,140
When a request has a clear status and every owner has a defined responsibility,

1015
00:51:43,140 --> 00:51:46,780
the app starts behaving exactly how the business process was meant to function.

1016
00:51:46,780 --> 00:51:49,700
Most enterprise teams don't actually need infinite interface freedom.

1017
00:51:49,700 --> 00:51:51,020
They need consistency.

1018
00:51:51,020 --> 00:51:53,660
They need a repeatable surface for record-heavy work

1019
00:51:53,660 --> 00:51:56,180
that functions across every department and device.

1020
00:51:56,180 --> 00:51:58,020
If your process depends on people rooting

1021
00:51:58,020 --> 00:51:59,780
and updating structured records all day,

1022
00:51:59,780 --> 00:52:03,500
these apps usually fit that reality much better than people expect.

1023
00:52:03,500 --> 00:52:05,300
There is another reason this shift matters.

1024
00:52:05,300 --> 00:52:07,300
It effectively ends the obsession with UI.

1025
00:52:07,300 --> 00:52:09,180
I'm not saying the user experience is irrelevant,

1026
00:52:09,180 --> 00:52:12,100
but model-driven apps change where your team spends its energy.

1027
00:52:12,100 --> 00:52:14,860
Instead of arguing for three weeks about button placement

1028
00:52:14,860 --> 00:52:16,860
while the data model remains vague,

1029
00:52:16,860 --> 00:52:19,820
the team has to make hard structural decisions early on.

1030
00:52:19,820 --> 00:52:22,860
They have to define the tables, the valid state transitions,

1031
00:52:22,860 --> 00:52:25,060
and the specific roles that need access.

1032
00:52:25,060 --> 00:52:27,180
That discipline might feel a bit slower at the start,

1033
00:52:27,180 --> 00:52:30,100
but it removes a massive amount of confusion down the road.

1034
00:52:30,100 --> 00:52:33,260
The app becomes a perfect mirror of your architectural clarity.

1035
00:52:33,260 --> 00:52:34,420
If that sounds a little rigid,

1036
00:52:34,420 --> 00:52:37,260
that's actually a good thing for most enterprise environments.

1037
00:52:37,260 --> 00:52:39,820
Service processes, case management, and approval chains

1038
00:52:39,820 --> 00:52:41,060
aren't designed playgrounds.

1039
00:52:41,060 --> 00:52:44,020
They are coordination systems where consistency and compliance

1040
00:52:44,020 --> 00:52:45,940
matter more than visual novelty.

1041
00:52:45,940 --> 00:52:47,660
When you can show a leader the same record

1042
00:52:47,660 --> 00:52:49,420
through different roles, demonstrating

1043
00:52:49,420 --> 00:52:51,700
how permissions in history emerge from one model,

1044
00:52:51,700 --> 00:52:52,820
the conversation changes.

1045
00:52:52,820 --> 00:52:54,620
It stops being about the cost of storage

1046
00:52:54,620 --> 00:52:57,100
and starts being about how to run shared operations

1047
00:52:57,100 --> 00:52:59,980
without rebuilding logic in every single app.

1048
00:52:59,980 --> 00:53:02,620
Canvas flexibility versus data versus control.

1049
00:53:02,620 --> 00:53:04,300
But Canvas apps still matter,

1050
00:53:04,300 --> 00:53:06,700
and this is where many people turn a good architectural question

1051
00:53:06,700 --> 00:53:07,660
into a false choice.

1052
00:53:07,660 --> 00:53:09,940
They ask if Canvas is better than data versus,

1053
00:53:09,940 --> 00:53:11,260
but those aren't competing layers.

1054
00:53:11,260 --> 00:53:13,260
One is a way to shape a specific experience

1055
00:53:13,260 --> 00:53:15,420
while the other is a way to govern the truth.

1056
00:53:15,420 --> 00:53:17,220
If we confuse those two jobs, we end up

1057
00:53:17,220 --> 00:53:18,660
blaming the front end for problems

1058
00:53:18,660 --> 00:53:20,620
that were actually created in the back end.

1059
00:53:20,620 --> 00:53:23,780
Canvas apps feel fast because they are incredibly fast to start.

1060
00:53:23,780 --> 00:53:26,300
You can plug into SharePoint, Excel, or SQL Server,

1061
00:53:26,300 --> 00:53:27,820
and immediately shape an experience

1062
00:53:27,820 --> 00:53:30,060
around a specific task or a mobile device.

1063
00:53:30,060 --> 00:53:31,980
For a field worker who needs a simple flow

1064
00:53:31,980 --> 00:53:34,300
or a frontline team that needs a tailored screen,

1065
00:53:34,300 --> 00:53:36,100
Canvas is often the right call.

1066
00:53:36,100 --> 00:53:39,420
But that same strength creates a significant structural risk.

1067
00:53:39,420 --> 00:53:42,260
When a Canvas app connects to a dozen different sources,

1068
00:53:42,260 --> 00:53:44,260
the logic starts to spread out and thin.

1069
00:53:44,260 --> 00:53:46,260
Security is suddenly split between the source,

1070
00:53:46,260 --> 00:53:48,580
the app sharing settings and individual formulas,

1071
00:53:48,580 --> 00:53:50,660
while validation might live in a specific control

1072
00:53:50,660 --> 00:53:51,860
or nowhere at all.

1073
00:53:51,860 --> 00:53:53,820
A record might look unified to the user,

1074
00:53:53,820 --> 00:53:56,060
but underneath the hood, it's being assembled

1075
00:53:56,060 --> 00:53:59,100
from systems that completely disagree on access or meaning.

1076
00:53:59,100 --> 00:54:00,660
Now map that to how we work today.

1077
00:54:00,660 --> 00:54:03,100
A team builds a beautiful app on a SharePoint list

1078
00:54:03,100 --> 00:54:04,140
and an Excel file.

1079
00:54:04,140 --> 00:54:05,900
And because it looks great, leadership

1080
00:54:05,900 --> 00:54:07,660
assumes the architecture is sound.

1081
00:54:07,660 --> 00:54:10,420
What they are actually seeing is interface quality compensating

1082
00:54:10,420 --> 00:54:11,780
for a weak foundation.

1083
00:54:11,780 --> 00:54:14,140
The screen looks coherent, so the underlying structure

1084
00:54:14,140 --> 00:54:16,100
escapes the scrutiny it deserves.

1085
00:54:16,100 --> 00:54:18,460
This is why I always say that most app failures

1086
00:54:18,460 --> 00:54:19,660
don't start on the screen.

1087
00:54:19,660 --> 00:54:20,740
They start in the model.

1088
00:54:20,740 --> 00:54:23,780
If your data shape is weak, the flexibility of a Canvas app

1089
00:54:23,780 --> 00:54:26,300
can hide that weakness much longer than a model-driven

1090
00:54:26,300 --> 00:54:27,020
app would.

1091
00:54:27,020 --> 00:54:28,980
You can patch over problems with collections

1092
00:54:28,980 --> 00:54:30,180
and local workarounds.

1093
00:54:30,180 --> 00:54:32,420
But every one of those moves your business logic

1094
00:54:32,420 --> 00:54:34,460
into a place where it's harder to govern.

1095
00:54:34,460 --> 00:54:36,740
From a system perspective, that is in flexibility,

1096
00:54:36,740 --> 00:54:38,540
it's just distributed fragility.

1097
00:54:38,540 --> 00:54:40,900
This is exactly where dataverse connected Canvas apps

1098
00:54:40,900 --> 00:54:42,100
become interesting.

1099
00:54:42,100 --> 00:54:44,020
Once the app sits on top of dataverse,

1100
00:54:44,020 --> 00:54:45,860
the user experience stays tailored,

1101
00:54:45,860 --> 00:54:48,260
but the policy layer moves down into the platform

1102
00:54:48,260 --> 00:54:49,180
where it belongs.

1103
00:54:49,180 --> 00:54:51,820
Security roles still apply and relationships still

1104
00:54:51,820 --> 00:54:54,380
carry context, which means the app no longer

1105
00:54:54,380 --> 00:54:56,700
has to carry the full burden of maintaining order

1106
00:54:56,700 --> 00:54:57,340
by itself.

1107
00:54:57,340 --> 00:54:59,860
That changes the entire operating shape of your solution.

1108
00:54:59,860 --> 00:55:01,540
You still get the custom interaction

1109
00:55:01,540 --> 00:55:04,300
and the role-specific design, but now the record underneath

1110
00:55:04,300 --> 00:55:05,740
has one governed definition.

1111
00:55:05,740 --> 00:55:08,380
This is the hybrid reality I recommend most.

1112
00:55:08,380 --> 00:55:10,980
Use Canvas where the experience is the priority,

1113
00:55:10,980 --> 00:55:13,940
but use dataverse where truth and control are required.

1114
00:55:13,940 --> 00:55:15,940
Let the front end stay flexible, but never

1115
00:55:15,940 --> 00:55:18,300
let that flexibility dictate the meaning

1116
00:55:18,300 --> 00:55:20,260
of your underlying business objects.

1117
00:55:20,260 --> 00:55:22,660
This matters for security more than most teams realize.

1118
00:55:22,660 --> 00:55:24,860
Canvas apps pulling from external sources

1119
00:55:24,860 --> 00:55:27,100
create a scattered security posture,

1120
00:55:27,100 --> 00:55:29,420
but dataverse narrows that spread significantly.

1121
00:55:29,420 --> 00:55:32,220
The user still sees the tailored interface they want,

1122
00:55:32,220 --> 00:55:35,380
but the access is grounded in a consistent manageable layer.

1123
00:55:35,380 --> 00:55:37,460
I'm not arguing against using Canvas apps.

1124
00:55:37,460 --> 00:55:39,260
I'm arguing against using Canvas Freedom

1125
00:55:39,260 --> 00:55:41,500
as a substitute for architectural discipline.

1126
00:55:41,500 --> 00:55:43,220
Canvas is for shaping the interaction.

1127
00:55:43,220 --> 00:55:45,180
Dataverse is for shaping the control.

1128
00:55:45,180 --> 00:55:46,420
When you make them work together,

1129
00:55:46,420 --> 00:55:49,740
you get a custom experience sitting on top of governed data.

1130
00:55:49,740 --> 00:55:53,020
The app can move fast without forcing the model to fragment,

1131
00:55:53,020 --> 00:55:55,540
and that is how you build a real operational backbone

1132
00:55:55,540 --> 00:55:57,460
instead of just another local app.

1133
00:55:57,460 --> 00:56:00,700
Scenario one shadow app chaos to one operational model.

1134
00:56:00,700 --> 00:56:02,740
Let's make this concrete because these concepts

1135
00:56:02,740 --> 00:56:05,220
stop feeling theoretical the moment you look at how business

1136
00:56:05,220 --> 00:56:07,500
processes actually grow in the real world.

1137
00:56:07,500 --> 00:56:09,780
A team hits a snag, and it's usually

1138
00:56:09,780 --> 00:56:11,900
a very real, very frustrating problem

1139
00:56:11,900 --> 00:56:13,780
where work is buried in email threads,

1140
00:56:13,780 --> 00:56:16,060
and nobody can see the status of anything.

1141
00:56:16,060 --> 00:56:18,180
Approvals take forever to move.

1142
00:56:18,180 --> 00:56:20,380
And by the time the end of the month rolls around,

1143
00:56:20,380 --> 00:56:22,700
reporting has to be stitched together manually

1144
00:56:22,700 --> 00:56:23,940
from five different places.

1145
00:56:23,940 --> 00:56:27,300
So someone does the sensible thing and creates an Excel tracker

1146
00:56:27,300 --> 00:56:29,700
to keep the head above water, then they move it to a share

1147
00:56:29,700 --> 00:56:31,500
point list because the team is growing,

1148
00:56:31,500 --> 00:56:34,740
and eventually a power app appears to make data entry easier

1149
00:56:34,740 --> 00:56:38,420
while a flow starts sending out automated approval emails.

1150
00:56:38,420 --> 00:56:40,420
None of this starts as bad architecture,

1151
00:56:40,420 --> 00:56:43,620
but rather as local problem solving under intense pressure.

1152
00:56:43,620 --> 00:56:45,100
And for a while, it actually works.

1153
00:56:45,100 --> 00:56:46,860
That is exactly why this pattern is so dangerous

1154
00:56:46,860 --> 00:56:49,460
because success arrives long before structure does.

1155
00:56:49,460 --> 00:56:52,580
Now, map out the typical expansion of that success.

1156
00:56:52,580 --> 00:56:55,060
One team uses the tracker, but then another department

1157
00:56:55,060 --> 00:56:58,100
wants their own custom fields, a manager demands a dashboard,

1158
00:56:58,100 --> 00:57:00,660
and finance insists on adding one more approval state.

1159
00:57:00,660 --> 00:57:02,500
Someone eventually adds a second list

1160
00:57:02,500 --> 00:57:03,900
because the permissions are getting awkward.

1161
00:57:03,900 --> 00:57:06,700
So attachments go to a document library

1162
00:57:06,700 --> 00:57:09,460
while the actual conversation stays trapped in email.

1163
00:57:09,460 --> 00:57:11,060
The app points to some of the data

1164
00:57:11,060 --> 00:57:12,660
while the report points to the rest,

1165
00:57:12,660 --> 00:57:14,580
and while everyone believes they are working

1166
00:57:14,580 --> 00:57:17,020
on the same process, structurally they are not.

1167
00:57:17,020 --> 00:57:19,020
They are navigating several partial realities

1168
00:57:19,020 --> 00:57:21,700
that only appear connected because the people inside the system

1169
00:57:21,700 --> 00:57:23,660
keep compensating for the gaps manually.

1170
00:57:23,660 --> 00:57:25,660
This is what I call shadow app chaos.

1171
00:57:25,660 --> 00:57:28,300
It isn't chaos because the app is hidden in some dramatic way,

1172
00:57:28,300 --> 00:57:31,460
but because the operating model itself is hidden from view.

1173
00:57:31,460 --> 00:57:33,820
The business can no longer see where the truth lives,

1174
00:57:33,820 --> 00:57:35,180
who has the right to change it,

1175
00:57:35,180 --> 00:57:37,780
or which specific object is actually authoritative.

1176
00:57:37,780 --> 00:57:39,980
Work continues, but the trust holding it all together

1177
00:57:39,980 --> 00:57:40,820
starts thinning out.

1178
00:57:40,820 --> 00:57:43,620
You can usually spot this phase of the cycle pretty quickly.

1179
00:57:43,620 --> 00:57:46,460
People start asking which file is the current version.

1180
00:57:46,460 --> 00:57:49,220
They spend the first 10 minutes of meetings comparing exports.

1181
00:57:49,220 --> 00:57:51,220
Approvals get rechecked in chat because the system

1182
00:57:51,220 --> 00:57:51,980
isn't trusted.

1183
00:57:51,980 --> 00:57:53,860
Reports require a full reconciliation

1184
00:57:53,860 --> 00:57:56,660
before anyone feels comfortable sharing them upward.

1185
00:57:56,660 --> 00:57:58,500
Nobody wants to delete the old tracker

1186
00:57:58,500 --> 00:58:01,340
because nobody fully trusts the new one to hold the weight.

1187
00:58:01,340 --> 00:58:03,340
That last point is the one that really matters.

1188
00:58:03,340 --> 00:58:05,020
If you cannot retire your old tools,

1189
00:58:05,020 --> 00:58:07,980
then your new system hasn't actually become the system yet.

1190
00:58:07,980 --> 00:58:10,860
This is where many organizations think they need a better interface

1191
00:58:10,860 --> 00:58:13,780
when what they actually need is a single operational model

1192
00:58:13,780 --> 00:58:14,980
to ground the work.

1193
00:58:14,980 --> 00:58:17,740
They need one dataverse model with one definition

1194
00:58:17,740 --> 00:58:20,300
of entities where requests, customers, cases,

1195
00:58:20,300 --> 00:58:23,220
and status transitions live in relation to each other.

1196
00:58:23,220 --> 00:58:25,140
These things shouldn't be copied between tools,

1197
00:58:25,140 --> 00:58:27,820
but modeled once and then surfaced through the right app

1198
00:58:27,820 --> 00:58:28,340
experience.

1199
00:58:28,340 --> 00:58:31,540
That shift changes much more than just where you store your data.

1200
00:58:31,540 --> 00:58:33,620
It removes entire categories of coordination

1201
00:58:33,620 --> 00:58:35,300
work that used to drain your time.

1202
00:58:35,300 --> 00:58:38,500
The request automatically points to the right customer record.

1203
00:58:38,500 --> 00:58:41,580
The approval state is defined once for everyone.

1204
00:58:41,580 --> 00:58:43,940
Ownership is visible directly in the record.

1205
00:58:43,940 --> 00:58:45,540
Automation runs from the same source

1206
00:58:45,540 --> 00:58:48,020
that the reporting reads, security controls access

1207
00:58:48,020 --> 00:58:50,020
without forcing you to create duplicates.

1208
00:58:50,020 --> 00:58:53,260
Now the process is no longer held together by memory and goodwill,

1209
00:58:53,260 --> 00:58:55,300
but by a structure designed to sustain it.

1210
00:58:55,300 --> 00:58:57,860
I have seen teams who thought they were building a better app

1211
00:58:57,860 --> 00:58:59,820
when what they were really doing was removing

1212
00:58:59,820 --> 00:59:02,300
11 competing truths and replacing them

1213
00:59:02,300 --> 00:59:04,060
with one governed process backbone.

1214
00:59:04,060 --> 00:59:05,540
That is the real win for the business.

1215
00:59:05,540 --> 00:59:08,860
It isn't about prettier screens or more automation in isolation,

1216
00:59:08,860 --> 00:59:12,540
but about having fewer places where the business can contradict itself.

1217
00:59:12,540 --> 00:59:14,180
Once that happens, the difference is obvious

1218
00:59:14,180 --> 00:59:16,300
even without looking at the statistics.

1219
00:59:16,300 --> 00:59:19,700
Before the shift, every exception required a deep investigation.

1220
00:59:19,700 --> 00:59:22,980
But after, the record already carries the context you need.

1221
00:59:22,980 --> 00:59:25,820
Before reporting was a negotiation between departments,

1222
00:59:25,820 --> 00:59:29,540
but now it's just a projection of the same operational data everyone sees.

1223
00:59:29,540 --> 00:59:32,580
Before every process change created a new side system,

1224
00:59:32,580 --> 00:59:34,420
but now changes are made in one model

1225
00:59:34,420 --> 00:59:36,420
and inherited across the entire solution.

1226
00:59:36,420 --> 00:59:38,300
The emotional shift is just as important.

1227
00:59:38,300 --> 00:59:40,940
People stop feeling like they need to maintain private safety nets

1228
00:59:40,940 --> 00:59:43,940
and they start trusting the live record instead of rebuilding context

1229
00:59:43,940 --> 00:59:44,860
from their inboxes.

1230
00:59:44,860 --> 00:59:48,180
They stop keeping parallel notes just in case the system fails them.

1231
00:59:48,180 --> 00:59:50,620
That isn't just a story about user adoption,

1232
00:59:50,620 --> 00:59:54,100
but a sign that the system has started absorbing complexity

1233
00:59:54,100 --> 00:59:56,620
instead of pushing it outward onto the people.

1234
00:59:56,620 --> 00:59:59,820
If you want to find the right first use case for data verse,

1235
00:59:59,820 --> 01:00:02,180
don't start where the excitement is loudest.

1236
01:00:02,180 --> 01:00:04,500
Start where the shadow systems are already multiplying

1237
01:00:04,500 --> 01:00:06,620
and where the team has one process

1238
01:00:06,620 --> 01:00:09,060
but five different places that pretend to run it.

1239
01:00:09,060 --> 01:00:11,380
Start where reporting requires a translator

1240
01:00:11,380 --> 01:00:13,180
and approvals require detective work

1241
01:00:13,180 --> 01:00:16,380
because that is the moment where data verse stops looking like a technical upgrade.

1242
01:00:16,380 --> 01:00:18,820
It starts looking like relief.

1243
01:00:18,820 --> 01:00:22,740
Scenario two, why AI fails without structured grounding.

1244
01:00:22,740 --> 01:00:24,900
This same pattern becomes even more obvious

1245
01:00:24,900 --> 01:00:26,820
the moment AI enters the picture

1246
01:00:26,820 --> 01:00:30,220
because a lot of organizations are hitting a new frustration curve right now.

1247
01:00:30,220 --> 01:00:32,300
They connect co-pilot experiment with agents

1248
01:00:32,300 --> 01:00:35,420
and ask natural language questions across their business data

1249
01:00:35,420 --> 01:00:39,740
only to act surprised when the answers feel shallow or unreliable.

1250
01:00:39,740 --> 01:00:41,980
The first instinct is usually to blame the prompts,

1251
01:00:41,980 --> 01:00:43,580
the model quality or the user training,

1252
01:00:43,580 --> 01:00:46,180
but in most cases that isn't where the failure is happening.

1253
01:00:46,180 --> 01:00:48,220
The failure starts much lower in the stack.

1254
01:00:48,220 --> 01:00:51,380
AI simply does not reason well over a scattered operational truth.

1255
01:00:51,380 --> 01:00:54,140
If your underlying data is spread across files, lists,

1256
01:00:54,140 --> 01:00:55,980
and inconsistent status values,

1257
01:00:55,980 --> 01:00:57,980
then the model isn't sitting on business context.

1258
01:00:57,980 --> 01:00:59,180
It is sitting on fragments.

1259
01:00:59,180 --> 01:01:01,460
It can still generate language and sound very helpful,

1260
01:01:01,460 --> 01:01:03,860
but sound and structure are not the same thing.

1261
01:01:03,860 --> 01:01:05,140
When the structure is weak,

1262
01:01:05,140 --> 01:01:08,860
the AI's confidence rises much faster than its actual accuracy.

1263
01:01:08,860 --> 01:01:11,060
That is a dangerous combination for any business.

1264
01:01:11,060 --> 01:01:14,780
If you look closely, AI disappointment is often just a data architecture story

1265
01:01:14,780 --> 01:01:17,180
wearing an interface story as a disguise.

1266
01:01:17,180 --> 01:01:19,580
Leaders often say the assistant isn't intelligent enough

1267
01:01:19,580 --> 01:01:21,980
when what they really mean is that their information

1268
01:01:21,980 --> 01:01:24,380
doesn't exist in a usable operational shape.

1269
01:01:24,380 --> 01:01:26,780
The model cannot infer what the business never bothered

1270
01:01:26,780 --> 01:01:28,380
to model clearly in the first place.

1271
01:01:28,380 --> 01:01:31,780
This is why dataverse matters so much in the next phase of the Microsoft stack.

1272
01:01:31,780 --> 01:01:34,300
It isn't because AI magically lives inside it,

1273
01:01:34,300 --> 01:01:38,300
but because dataverse gives AI something much more useful than sheer volume.

1274
01:01:38,300 --> 01:01:39,300
It gives its structure.

1275
01:01:39,300 --> 01:01:41,180
It provides tables with defined meaning,

1276
01:01:41,180 --> 01:01:42,780
relationships that carry context

1277
01:01:42,780 --> 01:01:47,380
and a governed operational layer that an agent or co-pilot can reason over without ambiguity.

1278
01:01:47,380 --> 01:01:48,580
And that difference is massive.

1279
01:01:48,580 --> 01:01:51,380
A customer record by itself is just a row in a table.

1280
01:01:51,380 --> 01:01:54,380
A customer related to cases, approvals, tasks, and history

1281
01:01:54,380 --> 01:01:56,180
starts becoming actual context.

1282
01:01:56,180 --> 01:01:58,180
That is the level where AI finally gets useful

1283
01:01:58,180 --> 01:02:01,180
because usefulness doesn't come from having more text alone.

1284
01:02:01,180 --> 01:02:05,580
It comes from having a model that preserves how things actually belong together in the real world.

1285
01:02:05,580 --> 01:02:07,780
Dataverse provides that through relational structure,

1286
01:02:07,780 --> 01:02:11,780
which is exactly what weak file-based estates usually fail to provide for the user.

1287
01:02:11,780 --> 01:02:14,980
They store facts, but they do not hold meaning together consistently.

1288
01:02:14,980 --> 01:02:16,980
Microsoft's own direction makes this very clear.

1289
01:02:16,980 --> 01:02:21,980
Dataverse is being used as the central operational source for co-pilot and custom agent scenarios,

1290
01:02:21,980 --> 01:02:26,580
including experiences where users can summarize records and move directly into actions.

1291
01:02:26,580 --> 01:02:30,980
That only works well when the data underneath is coherent enough to ground the interaction,

1292
01:02:30,980 --> 01:02:35,780
otherwise the AI layer just inherits the same contradictions the humans were already struggling with.

1293
01:02:35,780 --> 01:02:38,180
When I hear teams say that AI is not ready,

1294
01:02:38,180 --> 01:02:40,180
I usually translate that a bit differently in my head.

1295
01:02:40,180 --> 01:02:42,580
The AI may be ready, but your operating data is not.

1296
01:02:42,580 --> 01:02:44,580
That is a very different diagnosis for a business leader

1297
01:02:44,580 --> 01:02:47,180
because one leads to prompt workshops and tool shopping

1298
01:02:47,180 --> 01:02:49,980
while the other leads to model design and ownership clarity.

1299
01:02:49,980 --> 01:02:53,180
One is a cosmetic fix, but the other is a structural solution.

1300
01:02:53,180 --> 01:02:57,180
This is where a lot of co-pilot ambition quietly collides with business reality.

1301
01:02:57,180 --> 01:03:00,380
Organizations want conversational access to their operations.

1302
01:03:00,380 --> 01:03:03,780
But those operations were never designed as one trustworthy model.

1303
01:03:03,780 --> 01:03:05,980
They were assembled over time through convenience,

1304
01:03:05,980 --> 01:03:11,380
and AI exposes that weakness fast because weak grounding stops hiding the moment you ask for reasoning.

1305
01:03:11,380 --> 01:03:13,980
The system can only answer from what it can actually trust.

1306
01:03:13,980 --> 01:03:19,180
If you want better AI outcomes, do not start by asking how to make the assistance sound smarter.

1307
01:03:19,180 --> 01:03:22,380
Start by asking whether your business objects are defined clearly enough

1308
01:03:22,380 --> 01:03:25,980
that an assistant can tell what belongs to what without guessing.

1309
01:03:25,980 --> 01:03:28,980
Because AI is only as intelligent as the structure it sits on,

1310
01:03:28,980 --> 01:03:33,180
once AI connects to that structure, another design question shows up immediately.

1311
01:03:33,180 --> 01:03:37,180
Where should the operational truth live, and where should the broader analytics happen

1312
01:03:37,180 --> 01:03:40,180
without overloading the system that runs the work?

1313
01:03:40,180 --> 01:03:43,180
Dataverse as the operational core, not the analytics warehouse.

1314
01:03:43,180 --> 01:03:47,580
This is the exact moment where many teams accidentally create a second architecture problem

1315
01:03:47,580 --> 01:03:50,180
right after they've finished solving the first one.

1316
01:03:50,180 --> 01:03:52,980
They finally get their operations centralized in Dataverse

1317
01:03:52,980 --> 01:03:55,180
and suddenly everything starts working the way it should.

1318
01:03:55,180 --> 01:03:58,580
The records have actual structure, your automation runs cleaner,

1319
01:03:58,580 --> 01:04:01,180
and your AI finally has solid grounding to work from.

1320
01:04:01,180 --> 01:04:04,580
But then someone in the room asks that very familiar question.

1321
01:04:04,580 --> 01:04:05,580
This is great.

1322
01:04:05,580 --> 01:04:09,180
So can we just use Dataverse for all our reporting, our entire history,

1323
01:04:09,180 --> 01:04:11,580
and every future data need we might ever have?

1324
01:04:11,580 --> 01:04:13,980
It sounds efficient and it definitely sounds tidy.

1325
01:04:13,980 --> 01:04:15,980
But if you look at it from a system perspective,

1326
01:04:15,980 --> 01:04:18,380
that move confuses two very different jobs.

1327
01:04:18,380 --> 01:04:20,780
Running your day-to-day operations is one job.

1328
01:04:20,780 --> 01:04:23,980
Analyzing those operations at scale is something else entirely.

1329
01:04:23,980 --> 01:04:27,780
Dataverse is built specifically to support your operational layer,

1330
01:04:27,780 --> 01:04:31,580
which means it excels at transactions, structured records,

1331
01:04:31,580 --> 01:04:33,180
and managing process states.

1332
01:04:33,180 --> 01:04:36,980
It handles relationships and security while acting as the living system

1333
01:04:36,980 --> 01:04:40,980
where your people create, update, and root the data they need to actually do their work.

1334
01:04:40,980 --> 01:04:42,780
That is what the system is designed to do.

1335
01:04:42,780 --> 01:04:46,580
It holds the current truth that your business is actively using right now.

1336
01:04:46,580 --> 01:04:49,580
However, the moment leaders try to turn that operational store

1337
01:04:49,580 --> 01:04:51,580
into a universal analytics warehouse,

1338
01:04:51,580 --> 01:04:54,780
they start loading the wrong expectations onto the platform.

1339
01:04:54,780 --> 01:04:58,780
The reason this fails is that analytics asks fundamentally different questions.

1340
01:04:58,780 --> 01:05:01,980
Analytics isn't just asking what is true in this moment.

1341
01:05:01,980 --> 01:05:05,980
It wants to know what changed over time across massive volumes of data,

1342
01:05:05,980 --> 01:05:07,980
how patents evolved over years,

1343
01:05:07,980 --> 01:05:11,380
and how that data joins with finance, web, or external systems.

1344
01:05:11,380 --> 01:05:14,380
Those are broad projection questions, not operational ones.

1345
01:05:14,380 --> 01:05:17,780
When you force one single platform to do every job at once,

1346
01:05:17,780 --> 01:05:20,180
one of those jobs is going to start suffering.

1347
01:05:20,180 --> 01:05:23,380
The much cleaner design is to separate your data by its purpose.

1348
01:05:23,380 --> 01:05:25,980
You should let dataverse run the actual work,

1349
01:05:25,980 --> 01:05:29,580
while letting another layer carry the heavy lifting of analytical projection.

1350
01:05:29,580 --> 01:05:33,780
In the Microsoft ecosystem, this usually means using Azure Synapse link

1351
01:05:33,780 --> 01:05:36,180
or fabric link to move your data into an environment

1352
01:05:36,180 --> 01:05:38,180
built for history and cross-source modeling.

1353
01:05:38,180 --> 01:05:41,780
This allows for deep reporting without putting all that technical pressure back

1354
01:05:41,780 --> 01:05:43,980
on the live store that's trying to run your business.

1355
01:05:43,980 --> 01:05:46,580
This separation isn't just about following architecture trends

1356
01:05:46,580 --> 01:05:48,380
or duplicating data for fun.

1357
01:05:48,380 --> 01:05:50,180
It is a matter of workload discipline.

1358
01:05:50,180 --> 01:05:53,180
Your operational system needs to stay responsive and trustworthy

1359
01:05:53,180 --> 01:05:55,580
because it's tied directly to your business processes.

1360
01:05:55,580 --> 01:05:59,980
Meanwhile, your analytical system needs room for bigger joins and time-based thinking.

1361
01:05:59,980 --> 01:06:02,180
These needs are related, but they are not the same.

1362
01:06:02,180 --> 01:06:04,380
If you treat your operational core like a warehouse,

1363
01:06:04,380 --> 01:06:05,780
you're asking it to carry patents.

1364
01:06:05,780 --> 01:06:06,980
It was never meant to handle.

1365
01:06:06,980 --> 01:06:10,980
And that's usually when people start blaming dataverse for things that aren't its fault.

1366
01:06:10,980 --> 01:06:13,980
I see this happen most often when teams expect every single report

1367
01:06:13,980 --> 01:06:18,580
to read directly from the live store with zero latency and no architecture for high-change volumes.

1368
01:06:18,580 --> 01:06:21,380
Analytical pipelines have their own specific behaviors.

1369
01:06:21,380 --> 01:06:24,180
While synops and fabric links support near real-time patterns,

1370
01:06:24,180 --> 01:06:27,580
the standard expectation is usually a 15-minute sync cadence

1371
01:06:27,580 --> 01:06:31,180
rather than some magical instant reflection across every report.

1372
01:06:31,180 --> 01:06:34,580
In high-volume situations, those delays can even stretch a bit further.

1373
01:06:34,580 --> 01:06:36,980
Leaders need to stop asking for everything at once

1374
01:06:36,980 --> 01:06:38,780
and start thinking in business terms.

1375
01:06:38,780 --> 01:06:42,180
You have to decide what needs the live operational truth right now

1376
01:06:42,180 --> 01:06:46,980
and what can accept a governed analytical lag in exchange for better scale.

1377
01:06:46,980 --> 01:06:50,580
That is a much more productive conversation than trying to force one platform

1378
01:06:50,580 --> 01:06:52,780
to satisfy two conflicting instincts.

1379
01:06:52,780 --> 01:06:56,580
There is also a real cost and complexity dimension to consider here

1380
01:06:56,580 --> 01:07:00,180
forcing an operational store to satisfy every reporting pattern

1381
01:07:00,180 --> 01:07:02,380
creates pressure in all the wrong places

1382
01:07:02,380 --> 01:07:05,980
while analytical links come with their own storage and governance choices.

1383
01:07:05,980 --> 01:07:07,980
Fabric might simplify the experience

1384
01:07:07,980 --> 01:07:09,980
while synops offers more engineering control,

1385
01:07:09,980 --> 01:07:11,980
but the point isn't which one sounds newer.

1386
01:07:11,980 --> 01:07:15,980
The point is choosing the right projection layer for the specific job you're trying to do.

1387
01:07:15,980 --> 01:07:18,780
Good architecture separates systems by their purpose

1388
01:07:18,780 --> 01:07:20,380
not by what's currently trending.

1389
01:07:20,380 --> 01:07:22,780
If dataverse is your operational backbone,

1390
01:07:22,780 --> 01:07:24,780
then you need to treat it like a backbone.

1391
01:07:24,780 --> 01:07:27,380
Let it carry the live records, the process states,

1392
01:07:27,380 --> 01:07:29,980
and the automation triggers that actually run the business.

1393
01:07:29,980 --> 01:07:32,980
Then project that data outward into analytical layers

1394
01:07:32,980 --> 01:07:35,980
when your questions become larger, slower, or more historical.

1395
01:07:35,980 --> 01:07:38,380
By doing this, the business gets the best of both worlds,

1396
01:07:38,380 --> 01:07:40,980
a trustworthy operational core and a reporting layer

1397
01:07:40,980 --> 01:07:42,580
built for actual analysis.

1398
01:07:42,580 --> 01:07:47,180
Rather than one overloaded foundation trying to pretend those two things are the same.

1399
01:07:47,180 --> 01:07:50,380
Audit history, retention, and the cost of remembering everything.

1400
01:07:50,380 --> 01:07:53,980
That same logic of separation shows up again when we talk about audit history.

1401
01:07:53,980 --> 01:07:56,580
The moment dataverse becomes your operational core,

1402
01:07:56,580 --> 01:07:58,580
a new instinct usually kicks in,

1403
01:07:58,580 --> 01:08:00,980
the desire to keep everything forever.

1404
01:08:00,980 --> 01:08:03,980
Now that you can finally see who changed what and when they did it,

1405
01:08:03,980 --> 01:08:05,580
that instinct feels like safety.

1406
01:08:05,580 --> 01:08:07,980
It provides accountability, helps with investigations,

1407
01:08:07,980 --> 01:08:09,580
and supports your compliance needs.

1408
01:08:09,580 --> 01:08:11,580
Essentially it gives the platform a memory,

1409
01:08:11,580 --> 01:08:12,580
but memories never free.

1410
01:08:12,580 --> 01:08:16,380
If you look closely, your audit strategy is actually a design choice

1411
01:08:16,380 --> 01:08:18,180
about what the business needs to remember,

1412
01:08:18,180 --> 01:08:19,980
how long it needs to remember it,

1413
01:08:19,980 --> 01:08:22,380
and what you're willing to pay for that privilege.

1414
01:08:22,380 --> 01:08:25,380
Dataverse auditing tracks changes across your tables,

1415
01:08:25,380 --> 01:08:27,980
but those logs are stored in premium log capacity.

1416
01:08:27,980 --> 01:08:32,780
This matters because auditing isn't just a nice to have feature running invisibly in the background.

1417
01:08:32,780 --> 01:08:34,780
It consumes a specific storage category.

1418
01:08:34,780 --> 01:08:36,980
And if you turn it on for everything without a plan,

1419
01:08:36,980 --> 01:08:40,780
your costs will start rising quietly while you assume you're just being responsible.

1420
01:08:40,780 --> 01:08:42,780
This is exactly where teams run into trouble.

1421
01:08:42,780 --> 01:08:45,380
They start treating auditing like an all or nothing moral decision.

1422
01:08:45,380 --> 01:08:47,980
The fear is that if you don't audit everything forever,

1423
01:08:47,980 --> 01:08:50,180
you're risking a total loss of accountability.

1424
01:08:50,180 --> 01:08:53,380
But that framing is far too simple for how real operations work.

1425
01:08:53,380 --> 01:08:55,580
Some records carry heavy regulatory weight,

1426
01:08:55,580 --> 01:08:58,580
while other changes only matter for short term troubleshooting.

1427
01:08:58,580 --> 01:09:02,180
Some tables update so constantly that they create massive log volumes

1428
01:09:02,180 --> 01:09:04,180
with almost no long term value.

1429
01:09:04,180 --> 01:09:06,180
If you don't distinguish between these patterns,

1430
01:09:06,180 --> 01:09:07,980
the system will still capture the history,

1431
01:09:07,980 --> 01:09:10,980
but you'll be paying to remember low value noise

1432
01:09:10,980 --> 01:09:13,380
at the same price as high value evidence.

1433
01:09:13,380 --> 01:09:16,180
That isn't governance. That is just undifferentiated retention.

1434
01:09:16,180 --> 01:09:17,380
As that log volume grows,

1435
01:09:17,380 --> 01:09:20,780
the consequences eventually move beyond just being a financial issue.

1436
01:09:20,780 --> 01:09:23,380
Heavy auditing on frequently updated entities

1437
01:09:23,380 --> 01:09:26,180
can add storage pressure and make your backups much heavier.

1438
01:09:26,180 --> 01:09:28,780
Cleanup becomes harder, and your actual visibility drops

1439
01:09:28,780 --> 01:09:30,580
because the platform is recording more data

1440
01:09:30,580 --> 01:09:32,980
than your organization can ever realistically use.

1441
01:09:32,980 --> 01:09:36,180
The question has to shift from, should we audit to something better?

1442
01:09:36,180 --> 01:09:38,380
What specific memory has enough business value

1443
01:09:38,380 --> 01:09:40,380
to justify premium retention?

1444
01:09:40,380 --> 01:09:42,380
That is the conversation leaders should be having

1445
01:09:42,380 --> 01:09:46,180
for some tables like HR data or sensitive security approvals,

1446
01:09:46,180 --> 01:09:48,180
long retention makes perfect sense.

1447
01:09:48,180 --> 01:09:50,580
You might need years of history for legal reasons.

1448
01:09:50,580 --> 01:09:52,580
For other tables, a shorter retention period

1449
01:09:52,580 --> 01:09:53,780
is the more responsible choice

1450
01:09:53,780 --> 01:09:55,980
because the value is an operational debugging,

1451
01:09:55,980 --> 01:09:57,380
not permanent evidence.

1452
01:09:57,380 --> 01:10:00,180
Microsoft's tools now support more selective approaches,

1453
01:10:00,180 --> 01:10:02,180
including specific retention policies

1454
01:10:02,180 --> 01:10:03,980
and table level deletion options.

1455
01:10:03,980 --> 01:10:06,380
We are no longer stuck with one blunt policy

1456
01:10:06,380 --> 01:10:08,980
if we are willing to think structurally about our data.

1457
01:10:08,980 --> 01:10:11,580
This is where architecture discipline becomes vital again.

1458
01:10:11,580 --> 01:10:13,380
Your audit history should stay close enough

1459
01:10:13,380 --> 01:10:15,580
to your operations to provide traceability,

1460
01:10:15,580 --> 01:10:18,980
but not every analysis task needs to live inside dataverse forever.

1461
01:10:18,980 --> 01:10:22,580
You can use export paths like Azure Synapse Link

1462
01:10:22,580 --> 01:10:25,580
to move that audit data into a better environment

1463
01:10:25,580 --> 01:10:27,980
for long term review or lower cost storage.

1464
01:10:27,980 --> 01:10:29,980
This doesn't mean you don't have to make decisions.

1465
01:10:29,980 --> 01:10:31,380
It just means you have more options

1466
01:10:31,380 --> 01:10:33,380
than simply storing everything in premium capacity

1467
01:10:33,380 --> 01:10:35,580
and hoping the finance department never notices.

1468
01:10:35,580 --> 01:10:37,180
Because eventually, finance will notice,

1469
01:10:37,180 --> 01:10:38,380
by the time they do,

1470
01:10:38,380 --> 01:10:40,980
the wrong habits might already be embedded in your system.

1471
01:10:40,980 --> 01:10:42,180
I would frame audit retention

1472
01:10:42,180 --> 01:10:44,580
the same way I frame every other dataverse decision

1473
01:10:44,580 --> 01:10:45,780
by its purpose.

1474
01:10:45,780 --> 01:10:48,180
Use auditing where traceability reduces your risk

1475
01:10:48,180 --> 01:10:50,180
or helps you explain system behavior.

1476
01:10:50,180 --> 01:10:51,580
Keep that retention long

1477
01:10:51,580 --> 01:10:54,180
where the legal or operational value truly demands it

1478
01:10:54,180 --> 01:10:56,180
but keep it short where the value decays quickly.

1479
01:10:56,180 --> 01:10:57,980
You need to monitor which tables

1480
01:10:57,980 --> 01:10:59,580
are eating up your log capacity

1481
01:10:59,580 --> 01:11:00,980
and treat selective auditing

1482
01:11:00,980 --> 01:11:03,380
as a form of discipline rather than a compromise.

1483
01:11:03,380 --> 01:11:05,180
If you remember nothing else from this section,

1484
01:11:05,180 --> 01:11:06,180
remember this.

1485
01:11:06,180 --> 01:11:08,180
Accountability is incredibly valuable

1486
01:11:08,180 --> 01:11:10,780
but unmanage memory quickly becomes architecture dead.

1487
01:11:10,780 --> 01:11:13,980
The platform has the capability to remember almost everything.

1488
01:11:13,980 --> 01:11:15,980
That does not mean your business should be

1489
01:11:15,980 --> 01:11:18,180
paying to keep everything in the exact same way.

1490
01:11:18,180 --> 01:11:19,580
And that brings us to the objection

1491
01:11:19,580 --> 01:11:21,780
that almost always shows up at this point.

1492
01:11:21,780 --> 01:11:23,980
Once leaders see the need for premium storage,

1493
01:11:23,980 --> 01:11:25,980
premium governance and premium discipline,

1494
01:11:25,980 --> 01:11:27,980
they ask the question everyone eventually asks

1495
01:11:27,980 --> 01:11:29,980
isn't that averse just too expensive?

1496
01:11:29,980 --> 01:11:32,780
Dataverse is expensive and that is the wrong first question.

1497
01:11:32,780 --> 01:11:33,980
Now we come to the objection

1498
01:11:33,980 --> 01:11:36,380
that usually arrives with a certain tone of confidence.

1499
01:11:36,380 --> 01:11:37,780
Dataverse is expensive.

1500
01:11:37,780 --> 01:11:39,780
To be fair, that statement isn't exactly wrong.

1501
01:11:39,780 --> 01:11:42,580
When you compare it to Excel, SharePoint lists

1502
01:11:42,580 --> 01:11:45,180
or other tools people already feel they've paid for,

1503
01:11:45,180 --> 01:11:48,180
Dataverse often introduces a much more visible cost line.

1504
01:11:48,180 --> 01:11:50,180
You have to think about premium licensing,

1505
01:11:50,180 --> 01:11:52,380
capacity planning and specific choices

1506
01:11:52,380 --> 01:11:54,380
for database, file and log storage.

1507
01:11:54,380 --> 01:11:55,980
If you only look at the entry price,

1508
01:11:55,980 --> 01:11:58,780
Dataverse can look like the more expensive answer very quickly.

1509
01:11:58,780 --> 01:12:01,980
But here is the thing, entry price is not the same as system cost.

1510
01:12:01,980 --> 01:12:04,380
That distinction matters because most organizations

1511
01:12:04,380 --> 01:12:06,180
do not actually suffer from cheap tools

1512
01:12:06,180 --> 01:12:09,180
but they do suffer from the expensive compensation required

1513
01:12:09,180 --> 01:12:10,980
to make those cheap tools work.

1514
01:12:10,980 --> 01:12:12,980
You see it in extra reconciliation manual controls,

1515
01:12:12,980 --> 01:12:15,380
duplicate records and awkward permission workarounds.

1516
01:12:15,380 --> 01:12:17,780
There are reporting delays, fragile automations

1517
01:12:17,780 --> 01:12:20,180
and constant cleanup projects that eventually lead

1518
01:12:20,180 --> 01:12:21,580
to massive migration projects

1519
01:12:21,580 --> 01:12:24,980
once the process finally outgrows its original foundation.

1520
01:12:24,980 --> 01:12:27,980
Those costs rarely show up as a single license line

1521
01:12:27,980 --> 01:12:30,180
and that is exactly why leaders underestimate them.

1522
01:12:30,180 --> 01:12:32,780
So when somebody tells me that Dataverse is expensive,

1523
01:12:32,780 --> 01:12:34,580
my first response is usually to ask

1524
01:12:34,580 --> 01:12:36,980
what stage of the life cycle they are talking about.

1525
01:12:36,980 --> 01:12:38,580
Compared to the first week, it might be.

1526
01:12:38,580 --> 01:12:40,380
Compared to year two, it often isn't.

1527
01:12:40,380 --> 01:12:42,180
This is the pattern most teams miss.

1528
01:12:42,180 --> 01:12:43,780
SharePoint and Excel feel cheap

1529
01:12:43,780 --> 01:12:45,380
because the platform friction is low

1530
01:12:45,380 --> 01:12:47,580
and the spend is already hidden inside your broader

1531
01:12:47,580 --> 01:12:49,780
Microsoft 365 licensing.

1532
01:12:49,780 --> 01:12:51,280
But as the business process grows,

1533
01:12:51,280 --> 01:12:53,680
the cost shape changes and the organization starts

1534
01:12:53,680 --> 01:12:55,380
paying in labor instead of licensing.

1535
01:12:55,380 --> 01:12:57,780
Labor is where architecture debt gets very expensive,

1536
01:12:57,780 --> 01:13:00,580
very fast because every week structural choice begins

1537
01:13:00,580 --> 01:13:03,780
demanding human attention just to keep the process coherent.

1538
01:13:03,780 --> 01:13:05,180
You aren't actually saving money.

1539
01:13:05,180 --> 01:13:08,380
You are just shifting cost from licenses to complexity.

1540
01:13:08,380 --> 01:13:10,180
That is why cost first comparisons

1541
01:13:10,180 --> 01:13:12,080
can be so misleading for a business.

1542
01:13:12,080 --> 01:13:13,780
They often compare one visible cost

1543
01:13:13,780 --> 01:13:15,480
against a collection of invisible costs

1544
01:13:15,480 --> 01:13:17,380
that sit in different budgets, different teams

1545
01:13:17,380 --> 01:13:18,680
and different kinds of pain.

1546
01:13:18,680 --> 01:13:20,680
Support feels it, operations feels it

1547
01:13:20,680 --> 01:13:22,580
and the people inside the system feel it every day.

1548
01:13:22,580 --> 01:13:25,880
But the finance view may still say the cheaper tool won.

1549
01:13:25,880 --> 01:13:28,280
From a system perspective, that is a measurement problem

1550
01:13:28,280 --> 01:13:29,580
rather than a proof point.

1551
01:13:29,580 --> 01:13:32,280
Now I'm not arguing that data versus always the right answer

1552
01:13:32,280 --> 01:13:33,380
because it isn't.

1553
01:13:33,380 --> 01:13:37,280
If your use case is small, flat and unlikely to grow in complexity,

1554
01:13:37,280 --> 01:13:39,880
then using SharePoint lists may be perfectly reasonable.

1555
01:13:39,880 --> 01:13:41,180
The research supports that.

1556
01:13:41,180 --> 01:13:43,580
SharePoint fits simple collaboration well

1557
01:13:43,580 --> 01:13:46,480
and comes without additional licensing in many setups.

1558
01:13:46,480 --> 01:13:48,980
So this isn't a morality play where every list is wrong

1559
01:13:48,980 --> 01:13:50,780
and every premium table is wise.

1560
01:13:50,780 --> 01:13:51,980
The real question is pressure.

1561
01:13:51,980 --> 01:13:54,980
What happens when the process needs stronger relationships

1562
01:13:54,980 --> 01:13:58,780
row-level security, server-side logic or cleaner delegation?

1563
01:13:58,780 --> 01:14:01,780
What happens when the list becomes an app, then a workflow

1564
01:14:01,780 --> 01:14:04,180
and then a reporting source that leadership relies on

1565
01:14:04,180 --> 01:14:05,180
for big decisions?

1566
01:14:05,180 --> 01:14:07,380
That is where the cost conversation needs to mature

1567
01:14:07,380 --> 01:14:09,780
because the business is no longer just buying storage.

1568
01:14:09,780 --> 01:14:12,880
It is choosing what kind of failure it wants to pay for.

1569
01:14:12,880 --> 01:14:14,880
You can pay more upfront for structure

1570
01:14:14,880 --> 01:14:16,680
or you can pay later for rework

1571
01:14:16,680 --> 01:14:18,380
and later is almost always more expensive.

1572
01:14:18,380 --> 01:14:20,180
Migration is a perfect example of this.

1573
01:14:20,180 --> 01:14:22,980
Many teams start in SharePoint because it is fast

1574
01:14:22,980 --> 01:14:25,080
but then they move to Dataverse one scale

1575
01:14:25,080 --> 01:14:27,380
and security needs finally catch up with them.

1576
01:14:27,380 --> 01:14:29,380
That second move is not just a data move,

1577
01:14:29,380 --> 01:14:32,180
it is a full redesign where relationships need to be rebuilt

1578
01:14:32,180 --> 01:14:33,780
and logic needs to be relocated.

1579
01:14:33,780 --> 01:14:36,580
Apps need to be reconnected and reports need to be updated,

1580
01:14:36,580 --> 01:14:39,380
which means the cheap start often becomes the expensive middle.

1581
01:14:39,380 --> 01:14:40,980
That is the wrong kind of economy.

1582
01:14:40,980 --> 01:14:43,180
A better cost question sounds more like this.

1583
01:14:43,180 --> 01:14:45,780
Which foundation reduces downstream complexity

1584
01:14:45,780 --> 01:14:47,780
for the process we actually expect to run?

1585
01:14:47,780 --> 01:14:49,380
If the answer includes automation,

1586
01:14:49,380 --> 01:14:51,980
you can trust and data quality you can sustain.

1587
01:14:51,980 --> 01:14:54,380
Then Dataverse may be the more economical decision

1588
01:14:54,380 --> 01:14:56,380
even when the license line is higher.

1589
01:14:56,380 --> 01:14:58,780
Because being economical is not the same as being cheap.

1590
01:14:58,780 --> 01:15:00,180
Cheap, low as entry friction,

1591
01:15:00,180 --> 01:15:02,180
economical, low as life cycle friction.

1592
01:15:02,180 --> 01:15:04,180
If leaders ask that second question early enough,

1593
01:15:04,180 --> 01:15:06,980
they avoid one of the most common regrets in the power platform

1594
01:15:06,980 --> 01:15:09,180
which is building something popular on a foundation

1595
01:15:09,180 --> 01:15:12,980
that could never really carry the weight once success arrived.

1596
01:15:12,980 --> 01:15:15,780
The four decisions leaders need to make before scaling.

1597
01:15:15,780 --> 01:15:17,780
If leaders want to avoid that year two regret,

1598
01:15:17,780 --> 01:15:19,380
they need to make four decisions early.

1599
01:15:19,380 --> 01:15:22,780
And I mean early enough that the platform still has a defined shape.

1600
01:15:22,780 --> 01:15:24,380
Once apps spread across teams,

1601
01:15:24,380 --> 01:15:26,980
every delayed decision returns later as rework

1602
01:15:26,980 --> 01:15:29,180
or friction over things that should have been defined

1603
01:15:29,180 --> 01:15:30,380
before the growth happened.

1604
01:15:30,380 --> 01:15:33,380
The first decision is ownership of the data model.

1605
01:15:33,380 --> 01:15:35,380
Who decides what the core entities mean

1606
01:15:35,380 --> 01:15:36,980
and how do conflicts get resolved

1607
01:15:36,980 --> 01:15:39,180
when different departments want different definitions?

1608
01:15:39,180 --> 01:15:41,180
This is where it becomes an executive call.

1609
01:15:41,180 --> 01:15:43,780
If ownership stays vague, teams will still move forward

1610
01:15:43,780 --> 01:15:45,180
but they will move forward in parallel

1611
01:15:45,180 --> 01:15:47,980
with local meanings and shortcuts that feel harmless

1612
01:15:47,980 --> 01:15:50,980
until you're reporting an automation, start disagreeing.

1613
01:15:50,980 --> 01:15:53,580
One customer with three meanings and four versions of status

1614
01:15:53,580 --> 01:15:54,580
is not a data issue.

1615
01:15:54,580 --> 01:15:57,380
It is a leadership gap showing up in a table structure.

1616
01:15:57,380 --> 01:15:59,380
The second decision is your environment strategy.

1617
01:15:59,380 --> 01:16:00,780
Where can people build?

1618
01:16:00,780 --> 01:16:01,780
Where can they test?

1619
01:16:01,780 --> 01:16:04,380
And where can the business actually depend on what was built?

1620
01:16:04,380 --> 01:16:05,380
This sounds operational

1621
01:16:05,380 --> 01:16:07,580
but it decides whether innovation becomes repeatable

1622
01:16:07,580 --> 01:16:09,380
or just leaves messy traces everywhere.

1623
01:16:09,380 --> 01:16:11,580
If leaders allow the default environment

1624
01:16:11,580 --> 01:16:15,180
to become the place where serious apps quietly accumulate,

1625
01:16:15,180 --> 01:16:16,380
they aren't choosing agility.

1626
01:16:16,380 --> 01:16:17,980
They are choosing weak visibility

1627
01:16:17,980 --> 01:16:19,780
and support problems that arrive late.

1628
01:16:19,780 --> 01:16:21,380
Whereas a clean environment strategy

1629
01:16:21,380 --> 01:16:24,780
gives useful work a safe route to become trusted.

1630
01:16:24,780 --> 01:16:26,580
The third decision is the access model.

1631
01:16:26,580 --> 01:16:28,780
You don't do this after the first permission crisis

1632
01:16:28,780 --> 01:16:30,580
or after duplicates have already spread.

1633
01:16:30,580 --> 01:16:31,380
You do it before.

1634
01:16:31,380 --> 01:16:35,180
Who needs to see which records at what level and under what role?

1635
01:16:35,180 --> 01:16:36,580
If that isn't designed early,

1636
01:16:36,580 --> 01:16:39,180
the organization starts compensating in all the wrong places.

1637
01:16:39,180 --> 01:16:41,180
Private copies appear hidden lists appear

1638
01:16:41,180 --> 01:16:43,180
and sensitive fields get moved elsewhere

1639
01:16:43,180 --> 01:16:46,180
because the original model cannot support controlled visibility.

1640
01:16:46,180 --> 01:16:47,980
Then people say the platform got messy

1641
01:16:47,980 --> 01:16:49,980
but the mess actually started

1642
01:16:49,980 --> 01:16:52,580
when security was treated as a later enhancement

1643
01:16:52,580 --> 01:16:54,580
instead of a core part of the model.

1644
01:16:54,580 --> 01:16:56,580
Weak access design fragments truth

1645
01:16:56,580 --> 01:16:58,980
while strong access design lets one record serve

1646
01:16:58,980 --> 01:17:00,980
many roles without multiplying into copies.

1647
01:17:00,980 --> 01:17:02,780
The fourth decision is ALM

1648
01:17:02,780 --> 01:17:04,780
or application lifecycle management.

1649
01:17:04,780 --> 01:17:06,380
How does change move into production?

1650
01:17:06,380 --> 01:17:07,380
Who approves it?

1651
01:17:07,380 --> 01:17:09,380
And how do we recover when a release causes damage?

1652
01:17:09,380 --> 01:17:11,380
This is the decision leaders often postpone

1653
01:17:11,380 --> 01:17:13,580
because early growth feels manageable.

1654
01:17:13,580 --> 01:17:15,780
A few makers and a few apps feel personal

1655
01:17:15,780 --> 01:17:18,580
enough that informal change still seems acceptable.

1656
01:17:18,580 --> 01:17:20,580
But once the business depends on those assets

1657
01:17:20,580 --> 01:17:23,980
that informal change turns into operational risk very quickly.

1658
01:17:23,980 --> 01:17:26,980
If there is no release path before production matters

1659
01:17:26,980 --> 01:17:28,380
then production becomes the place

1660
01:17:28,380 --> 01:17:30,980
where design testing and repair all happen at once.

1661
01:17:30,980 --> 01:17:34,780
That isn't speed, it is just avoidable risk disguised as momentum.

1662
01:17:34,780 --> 01:17:36,780
The reason I group these four together is simple.

1663
01:17:36,780 --> 01:17:38,580
They are not technical admin choices

1664
01:17:38,580 --> 01:17:40,180
sitting below your strategy.

1665
01:17:40,180 --> 01:17:41,380
They are the control points

1666
01:17:41,380 --> 01:17:43,780
that decide whether the platform grows as infrastructure

1667
01:17:43,780 --> 01:17:46,580
or grows as local improvisation with some branding on top.

1668
01:17:46,580 --> 01:17:48,180
Ownership prevents semantic drift,

1669
01:17:48,180 --> 01:17:50,180
environment strategy prevents sprawl,

1670
01:17:50,180 --> 01:17:51,980
access design prevents duplication,

1671
01:17:51,980 --> 01:17:53,780
ALM prevents release fragility.

1672
01:17:53,780 --> 01:17:54,980
If you ignore any one of those,

1673
01:17:54,980 --> 01:17:58,180
the failure mode shows up exactly where you would expect.

1674
01:17:58,180 --> 01:18:00,780
Without an owner, teams reinvent the same entities

1675
01:18:00,780 --> 01:18:03,180
and without boundaries, your assets scatter.

1676
01:18:03,180 --> 01:18:05,380
No access design means truth splits into copies

1677
01:18:05,380 --> 01:18:06,780
and without a lifecycle path,

1678
01:18:06,780 --> 01:18:08,780
every update carries hidden risk.

1679
01:18:08,780 --> 01:18:10,980
The platform may still look productive from the outside

1680
01:18:10,980 --> 01:18:13,180
but internally it starts absorbing complexity

1681
01:18:13,180 --> 01:18:14,380
in all the wrong places.

1682
01:18:14,380 --> 01:18:16,780
So before anyone asks which app to build next,

1683
01:18:16,780 --> 01:18:18,780
leaders should ask four planer questions

1684
01:18:18,780 --> 01:18:20,780
who owns the model, where does change happen,

1685
01:18:20,780 --> 01:18:22,780
who sees what, how does change move safely.

1686
01:18:22,780 --> 01:18:24,380
Once those decisions are made,

1687
01:18:24,380 --> 01:18:27,180
dataverse stops looking like a premium product choice

1688
01:18:27,180 --> 01:18:29,180
and starts looking like what it actually is,

1689
01:18:29,180 --> 01:18:31,180
infrastructure for shared operations.

1690
01:18:31,180 --> 01:18:33,580
When that clicks, adoption gets much simpler

1691
01:18:33,580 --> 01:18:36,180
because the conversation shifts away from features

1692
01:18:36,180 --> 01:18:38,980
and toward the places where the current pain already proves

1693
01:18:38,980 --> 01:18:41,180
the foundation is too weak.

1694
01:18:41,180 --> 01:18:43,380
What adoption should look like in the real world?

1695
01:18:43,380 --> 01:18:45,180
Once those four decisions are in place,

1696
01:18:45,180 --> 01:18:46,980
we have to face the reality of adoption.

1697
01:18:46,980 --> 01:18:48,980
I want to talk about what this actually looks like

1698
01:18:48,980 --> 01:18:50,180
in a real organization,

1699
01:18:50,180 --> 01:18:51,780
not what you see on a vendor slide

1700
01:18:51,780 --> 01:18:53,180
or in a proof-of-concept workshop.

1701
01:18:53,180 --> 01:18:55,380
We need to move past the platform strategy decks

1702
01:18:55,380 --> 01:18:58,380
that confuse high-level enthusiasm with actual readiness.

1703
01:18:58,380 --> 01:19:00,180
Healthy adoption should always start

1704
01:19:00,180 --> 01:19:02,980
where pressure is already exposing structural fragility.

1705
01:19:02,980 --> 01:19:05,180
It shouldn't start where the loudest person in the room

1706
01:19:05,180 --> 01:19:07,180
wants a new app and it definitely shouldn't start

1707
01:19:07,180 --> 01:19:09,380
just because a demo would look nice for leadership.

1708
01:19:09,380 --> 01:19:11,580
You need to look for the places where the current process

1709
01:19:11,580 --> 01:19:14,380
is showing you that the foundation can no longer carry the load.

1710
01:19:14,380 --> 01:19:17,380
Usually that means a process defined by a cross-team friction,

1711
01:19:17,380 --> 01:19:20,780
endless manual work and a total lack of trust in the current data.

1712
01:19:20,780 --> 01:19:23,580
You will see a visible delay between taking an action

1713
01:19:23,580 --> 01:19:26,780
and making a decision because people are constantly checking each other's numbers

1714
01:19:26,780 --> 01:19:28,380
before every meeting.

1715
01:19:28,380 --> 01:19:30,780
Approvals drift through inboxes for days

1716
01:19:30,780 --> 01:19:33,380
because nobody fully trusts the live state of the project

1717
01:19:33,380 --> 01:19:35,780
and reporting requires a translation layer

1718
01:19:35,780 --> 01:19:38,780
because no one can point to a single record

1719
01:19:38,780 --> 01:19:40,380
and call it the truth.

1720
01:19:40,380 --> 01:19:41,780
That is your starting point.

1721
01:19:41,780 --> 01:19:44,980
Adoption works best when data verse solves a structural pain

1722
01:19:44,980 --> 01:19:47,180
that people are already feeling in their daily lives.

1723
01:19:47,180 --> 01:19:49,980
If you start with novelty, people might admire the platform for a moment

1724
01:19:49,980 --> 01:19:52,580
but they will inevitably go back to their old behaviors

1725
01:19:52,580 --> 01:19:54,180
once the excitement fades.

1726
01:19:54,180 --> 01:19:55,180
When you start with pressure,

1727
01:19:55,180 --> 01:19:56,980
the platform earns immediate credibility

1728
01:19:56,980 --> 01:19:58,780
because it removes a burden that was already

1729
01:19:58,780 --> 01:20:01,180
costing the company time, trust and control.

1730
01:20:01,180 --> 01:20:03,180
The order of operations here matters

1731
01:20:03,180 --> 01:20:04,980
much more than most teams realize.

1732
01:20:04,980 --> 01:20:07,980
First, you build the model, then you design the app surface.

1733
01:20:07,980 --> 01:20:10,180
Then you layer in the automation.

1734
01:20:10,180 --> 01:20:12,380
Finally, you create the analytics projection.

1735
01:20:12,380 --> 01:20:13,580
If you reverse that order,

1736
01:20:13,580 --> 01:20:15,580
you simply end up with the same old broken patterns

1737
01:20:15,580 --> 01:20:17,180
wearing slightly better tools.

1738
01:20:17,180 --> 01:20:18,580
Teams often rush to screens

1739
01:20:18,580 --> 01:20:20,580
because screens are tangible and easy to show off

1740
01:20:20,580 --> 01:20:22,780
but then they end up automating around weak records

1741
01:20:22,780 --> 01:20:25,180
and reporting on top of ambiguous meanings.

1742
01:20:25,180 --> 01:20:27,980
Later on, they discover they build a lot of speed

1743
01:20:27,980 --> 01:20:30,180
on top of a foundation that is drifting away

1744
01:20:30,180 --> 01:20:32,580
which is a disaster that is completely avoidable

1745
01:20:32,580 --> 01:20:33,980
if the model comes first.

1746
01:20:33,980 --> 01:20:35,380
In a healthy adoption path,

1747
01:20:35,380 --> 01:20:38,180
the first question is never about what the app should look like.

1748
01:20:38,180 --> 01:20:40,180
Instead, we ask, what are the core entities?

1749
01:20:40,180 --> 01:20:41,580
Who actually owns them?

1750
01:20:41,580 --> 01:20:42,980
How do they relate to one another?

1751
01:20:42,980 --> 01:20:44,580
What states are considered valid?

1752
01:20:44,580 --> 01:20:46,180
Who has the authority to change what?

1753
01:20:46,180 --> 01:20:47,980
Where does the authoritative record live?

1754
01:20:47,980 --> 01:20:50,180
These are slower harder questions to answer at the start

1755
01:20:50,180 --> 01:20:52,180
but they reduce downstream negotiation

1756
01:20:52,180 --> 01:20:53,380
and conflict dramatically.

1757
01:20:53,380 --> 01:20:54,380
Once the model is clear,

1758
01:20:54,380 --> 01:20:55,980
the app becomes much simpler to build,

1759
01:20:55,980 --> 01:20:57,580
automation becomes safer to trigger

1760
01:20:57,580 --> 01:21:00,180
and analytics becomes a projection of governed operations

1761
01:21:00,180 --> 01:21:01,380
instead of a desperate attempt

1762
01:21:01,380 --> 01:21:03,580
to reconstruct them after the fact.

1763
01:21:03,580 --> 01:21:05,380
Visible wins are important

1764
01:21:05,380 --> 01:21:09,780
but the wrong kind of win creates a culture that will eventually fail.

1765
01:21:09,780 --> 01:21:13,780
If your first success story is that you build a cool app in two days,

1766
01:21:13,780 --> 01:21:17,180
the organization learns that speed is more important than structure.

1767
01:21:17,180 --> 01:21:19,780
A much better visible win sounds like cycle times dropping

1768
01:21:19,780 --> 01:21:21,780
because approvals no longer wait in email

1769
01:21:21,780 --> 01:21:22,780
or duplicates falling

1770
01:21:22,780 --> 01:21:25,780
because one record replaced five different trackers.

1771
01:21:25,780 --> 01:21:27,180
When audit readiness improves

1772
01:21:27,180 --> 01:21:29,180
because the change history was already there,

1773
01:21:29,180 --> 01:21:30,780
site systems start to disappear

1774
01:21:30,780 --> 01:21:33,180
because the operational model became trustworthy enough

1775
01:21:33,180 --> 01:21:34,180
to retire them.

1776
01:21:34,180 --> 01:21:36,180
That is adoption grounded in business reality.

1777
01:21:36,180 --> 01:21:39,580
The people inside the system do not need to love dataverse as a product.

1778
01:21:39,580 --> 01:21:43,380
They just need to trust the system more than the manual workarounds

1779
01:21:43,380 --> 01:21:45,380
they built to survive before it existed.

1780
01:21:45,380 --> 01:21:48,380
Trust grows when the first use case is chosen with extreme care.

1781
01:21:48,380 --> 01:21:51,380
You should pick one process that already spans multiple teams

1782
01:21:51,380 --> 01:21:54,580
specifically one where ownership and status have become so ambiguous

1783
01:21:54,580 --> 01:21:56,380
that people are forced to compensate manually.

1784
01:21:56,380 --> 01:21:59,580
When the cost of not fixing the model is already visible to everyone,

1785
01:21:59,580 --> 01:22:00,780
you solve it deeply enough

1786
01:22:00,780 --> 01:22:03,580
that the business feels a physical difference in how work moves.

1787
01:22:03,580 --> 01:22:06,580
It is about how the system functions, not just how the app looks.

1788
01:22:06,580 --> 01:22:10,780
This is why I avoid rolling out dataverse as a broad abstract initiative.

1789
01:22:10,780 --> 01:22:13,180
Saying we are adopting dataverse across the enterprise,

1790
01:22:13,180 --> 01:22:14,180
sounds ambitious,

1791
01:22:14,180 --> 01:22:17,380
but it doesn't actually tell anyone which pain point is being removed.

1792
01:22:17,380 --> 01:22:19,380
Adoption scales much better

1793
01:22:19,380 --> 01:22:21,980
through one structurally important process at a time

1794
01:22:21,980 --> 01:22:24,580
where each success proves that better data foundations

1795
01:22:24,580 --> 01:22:25,980
reduce the cost of coordination.

1796
01:22:25,980 --> 01:22:27,580
That proof compounds over time.

1797
01:22:27,580 --> 01:22:29,380
One process gains a governed model

1798
01:22:29,380 --> 01:22:31,780
and then another team sees the reporting get cleaner.

1799
01:22:31,780 --> 01:22:34,780
Another group sees permissions handled without duplicate lists

1800
01:22:34,780 --> 01:22:38,180
and soon another sees automation running from a single trusted record.

1801
01:22:38,180 --> 01:22:39,980
The conversation eventually changes from

1802
01:22:39,980 --> 01:22:43,580
why are we paying for this to which process should we move next?

1803
01:22:43,580 --> 01:22:45,180
That is what healthy adoption looks like.

1804
01:22:45,180 --> 01:22:48,380
It isn't feature theatre or apps brawl with a premium label.

1805
01:22:48,380 --> 01:22:51,780
It is a structural improvement that people can feel in their daily work

1806
01:22:51,780 --> 01:22:54,380
and leadership can recognize in the bottom line.

1807
01:22:54,380 --> 01:22:55,980
If you want a practical next step,

1808
01:22:55,980 --> 01:23:00,180
I suggest you audit one live process that currently runs across a mess of lists,

1809
01:23:00,180 --> 01:23:01,780
spreadsheets and inboxes.

1810
01:23:01,780 --> 01:23:02,780
Map out the entities,

1811
01:23:02,780 --> 01:23:05,180
the ownership, the access rules and the handoffs

1812
01:23:05,180 --> 01:23:07,180
before anyone even mentions a screen or a button.

1813
01:23:07,180 --> 01:23:08,980
You need to ask one hard question,

1814
01:23:08,980 --> 01:23:11,780
where does the truth live and who is allowed to change it?

1815
01:23:11,780 --> 01:23:15,580
Pick the use case where a poor structure is already slowing down the work

1816
01:23:15,580 --> 01:23:19,380
or blocking trust because that is where dataverse will prove its value the fastest.

1817
01:23:19,380 --> 01:23:21,580
Once the data foundation finally holds,

1818
01:23:21,580 --> 01:23:24,780
your apps automation and AI will stop fighting each other.

1819
01:23:24,780 --> 01:23:27,780
They will start compounding instead because the business finally put

1820
01:23:27,780 --> 01:23:30,380
one governed operational model underneath all of them.

1821
01:23:30,380 --> 01:23:34,580
If you audited your human connection systems the same way you audit your technical infrastructure,

1822
01:23:34,580 --> 01:23:35,580
what would you find?

1823
01:23:35,580 --> 01:23:37,980
Is your current system designed to sustain the business

1824
01:23:37,980 --> 01:23:40,580
or is it slowly draining your resources over time?

1825
01:23:40,580 --> 01:23:42,780
So let me leave you with the shift that matters most.

1826
01:23:42,780 --> 01:23:45,380
Dataverse is not just a storage upgrade for your data.

1827
01:23:45,380 --> 01:23:48,580
It is an operating model decision and once you see that clearly

1828
01:23:48,580 --> 01:23:52,580
a lot of confusing platform debates start collapsing into one simpler question.

1829
01:23:52,580 --> 01:23:58,980
Can your foundation carry shared business reality without forcing people to compensate around it every day?

1830
01:23:58,980 --> 01:24:01,180
Excel and SharePoint lists are not bad tools

1831
01:24:01,180 --> 01:24:03,980
but they are often asked to do work they were never shaped to carry

1832
01:24:03,980 --> 01:24:06,980
while they lower entry friction and feel efficient at first.

1833
01:24:06,980 --> 01:24:09,780
These tools also raise structural fragility under pressure

1834
01:24:09,780 --> 01:24:12,380
because the business keeps adding coordination costs

1835
01:24:12,380 --> 01:24:14,380
where the data layer should have absorbed them.

1836
01:24:14,380 --> 01:24:17,380
And that is why this conversation matters so much now.

1837
01:24:17,380 --> 01:24:20,580
Power apps, power automate reporting, governance and co-pilot

1838
01:24:20,580 --> 01:24:23,380
do not sit above the foundation in some abstract way.

1839
01:24:23,380 --> 01:24:24,380
They depend on it.

1840
01:24:24,380 --> 01:24:27,180
If the structure underneath is weak, every capability above it

1841
01:24:27,180 --> 01:24:29,980
gets more expensive, less trustworthy and harder to scale.

1842
01:24:29,980 --> 01:24:32,780
The app may still launch and the automation may still run

1843
01:24:32,780 --> 01:24:36,780
but the business will keep paying a hidden cost just to hold the whole thing together.

1844
01:24:36,780 --> 01:24:38,780
So audit one process differently this week.

1845
01:24:38,780 --> 01:24:40,580
Do not look at it as a workflow diagram.

1846
01:24:40,580 --> 01:24:41,780
Look at it as architecture.

1847
01:24:41,780 --> 01:24:44,580
Look at the entities, the ownership model and the access rules

1848
01:24:44,580 --> 01:24:47,580
to see where truth splits and duplication starts.

1849
01:24:47,580 --> 01:24:50,980
When you find places where people keep rebuilding context by hand

1850
01:24:50,980 --> 01:24:53,580
you will realize the friction probably is not random.

1851
01:24:53,580 --> 01:24:54,980
It is a system outcome.

1852
01:24:54,980 --> 01:24:57,980
If this kind of thinking helps you translate power platform decisions

1853
01:24:57,980 --> 01:24:59,980
into business reality, subscribe to the channel.

1854
01:24:59,980 --> 01:25:02,180
Leave a review if you are listening on the podcast

1855
01:25:02,180 --> 01:25:04,180
and connect with me, Miracopeters on LinkedIn.

1856
01:25:04,180 --> 01:25:07,180
Tell me what should come next, dataverse, power apps,

1857
01:25:07,180 --> 01:25:09,980
co-pilot, governance or the failure patterns you keep seeing

1858
01:25:09,980 --> 01:25:11,780
inside your own Microsoft estate.

1859
01:25:11,780 --> 01:25:13,580
Every app already depends on a foundation.

1860
01:25:13,580 --> 01:25:16,380
The only question is whether that foundation can still hold

1861
01:25:16,380 --> 01:25:18,380
when the business finally starts relying on it.