From Tables to Strategy: What Smart Dataverse Models Really Mean for the Future of Business Apps

1
00:00:00,000 --> 00:00:05,120
This episode was inspired by Bülent Altinsoy, a Microsoft MVP, who ran a four hour technical

2
00:00:05,120 --> 00:00:08,160
dataverse deep dive workshop at M365Con.

3
00:00:08,160 --> 00:00:13,040
Net, he stayed in the mechanics, tables, relationships, security solutions, the parts teams rush

4
00:00:13,040 --> 00:00:15,320
through because they want the app on the screen.

5
00:00:15,320 --> 00:00:19,720
This episode sits above that, most teams don't fail because power apps is low code.

6
00:00:19,720 --> 00:00:22,960
They fail because they treat data like a temporary inconvenience.

7
00:00:22,960 --> 00:00:25,880
Something to clean up after the demo, dataverse isn't a magic database.

8
00:00:25,880 --> 00:00:30,360
Its Microsoft quietly offering you a way to model reality with enough discipline that automation

9
00:00:30,360 --> 00:00:32,680
and AI can survive contact with production.

10
00:00:32,680 --> 00:00:36,880
This isn't about features, it's about why the model underneath becomes strategy, whether

11
00:00:36,880 --> 00:00:38,960
you intended it or not.

12
00:00:38,960 --> 00:00:41,520
Why low code data keeps failing in production?

13
00:00:41,520 --> 00:00:45,600
The comfortable story is that low code fails because makers don't know governance.

14
00:00:45,600 --> 00:00:47,280
That's not the failure mode.

15
00:00:47,280 --> 00:00:50,840
Low code data fails in production because the first version of the model is usually a lie

16
00:00:50,840 --> 00:00:54,600
that everyone agrees to, temporarily, so they can ship something.

17
00:00:54,600 --> 00:00:58,560
At first delivery patents create a very specific kind of debt, meaning debt.

18
00:00:58,560 --> 00:01:02,240
You get columns like status, owner, nodes, type and other.

19
00:01:02,240 --> 00:01:05,920
You get a single table that quietly becomes the dumping ground for three different business

20
00:01:05,920 --> 00:01:06,920
concepts.

21
00:01:06,920 --> 00:01:10,720
You get lookups that exist because the UI needed a drop down, not because the organization

22
00:01:10,720 --> 00:01:13,120
agreed on what the relationship actually means.

23
00:01:13,120 --> 00:01:14,320
And in week one, it works.

24
00:01:14,320 --> 00:01:17,640
The form loads, the flow triggers, the canvas app feels like progress.

25
00:01:17,640 --> 00:01:19,920
The leadership slide deck has a screenshot.

26
00:01:19,920 --> 00:01:21,480
Everyone relaxes.

27
00:01:21,480 --> 00:01:22,960
Then production happens.

28
00:01:22,960 --> 00:01:24,320
Not the go live date.

29
00:01:24,320 --> 00:01:30,280
In production, time, volume, edge cases, mergers, audits, new teams, new apps, new integrations.

30
00:01:30,280 --> 00:01:34,880
That's when the model stops being a convenient container and becomes an argument, the system

31
00:01:34,880 --> 00:01:37,000
has to resolve thousands of times a day.

32
00:01:37,000 --> 00:01:38,680
Here's what most people miss.

33
00:01:38,680 --> 00:01:40,440
Scaling doesn't just multiply transactions.

34
00:01:40,440 --> 00:01:42,400
It multiplies contradictions.

35
00:01:42,400 --> 00:01:46,320
If your model doesn't encode meaning, every downstream consumer invents meaning, your power

36
00:01:46,320 --> 00:01:48,640
automate flow invents one interpretation.

37
00:01:48,640 --> 00:01:52,160
Your reporting model invents another, the model driven app form invents a third, and

38
00:01:52,160 --> 00:01:54,120
now your organization isn't automating.

39
00:01:54,120 --> 00:01:56,160
It's negotiating with itself through software.

40
00:01:56,160 --> 00:01:58,720
This is why the it works phase is dangerous.

41
00:01:58,720 --> 00:02:00,560
Early success isn't proof you modeled well.

42
00:02:00,560 --> 00:02:02,720
It's proof you haven't hit the hard questions yet.

43
00:02:02,720 --> 00:02:08,400
Belend Altenzoy, a Microsoft MVP, puts it cleanly in his Dataverse workshop at M365

44
00:02:08,400 --> 00:02:09,400
con.

45
00:02:09,400 --> 00:02:12,520
Net, architecture is a story, not a snapshot.

46
00:02:12,520 --> 00:02:15,960
That line matters because most teams treat the model like a snapshot.

47
00:02:15,960 --> 00:02:19,040
Whatever shape the data needed to be in for today's screen.

48
00:02:19,040 --> 00:02:20,840
But architecture behaves like a story.

49
00:02:20,840 --> 00:02:25,340
The plot keeps moving, new characters appear, and the decisions you locked in during the

50
00:02:25,340 --> 00:02:29,000
pilot become the rules the system enforces in year two.

51
00:02:29,000 --> 00:02:32,440
And when you try to retrofit structure later, you don't pay in one place.

52
00:02:32,440 --> 00:02:33,440
You pay everywhere.

53
00:02:33,440 --> 00:02:34,800
Schema churn becomes your tax.

54
00:02:34,800 --> 00:02:35,800
You rename a column.

55
00:02:35,800 --> 00:02:36,800
Now you break a flow.

56
00:02:36,800 --> 00:02:37,800
You update the flow.

57
00:02:37,800 --> 00:02:38,800
Now you break a report.

58
00:02:38,800 --> 00:02:39,800
You update the report.

59
00:02:39,800 --> 00:02:40,960
Now you break the integration.

60
00:02:40,960 --> 00:02:42,280
You patch the integration.

61
00:02:42,280 --> 00:02:46,080
Now your environment layering and solutions are messy, so deployments get risky.

62
00:02:46,080 --> 00:02:49,400
So teams start just making the fits directly in production.

63
00:02:49,400 --> 00:02:52,240
Which means now you're not doing ALM, you're doing archaeology.

64
00:02:52,240 --> 00:02:55,440
This is how low code turns into high maintenance.

65
00:02:55,440 --> 00:02:57,920
And the core reason is almost always the same.

66
00:02:57,920 --> 00:03:00,560
The model never stabilized around business concepts.

67
00:03:00,560 --> 00:03:02,760
It stabilized around delivery pressure.

68
00:03:02,760 --> 00:03:07,520
The foundational misunderstanding is that data modeling is optional until later.

69
00:03:07,520 --> 00:03:08,520
It isn't.

70
00:03:08,520 --> 00:03:11,760
In Dataverse and really in any platform that wants to be enterprise grade, the model is

71
00:03:11,760 --> 00:03:14,320
the control plane for everything downstream.

72
00:03:14,320 --> 00:03:19,280
Security, behavior, integration, reporting, and now AI grounding.

73
00:03:19,280 --> 00:03:21,200
State models don't just create bad data.

74
00:03:21,200 --> 00:03:25,360
They create conditional chaos because every exception becomes an entropy generator.

75
00:03:25,360 --> 00:03:28,840
You add just one extra status value because the stakeholder needed it.

76
00:03:28,840 --> 00:03:32,880
You add just one extra column because a workflow didn't fit the existing structure.

77
00:03:32,880 --> 00:03:37,960
You add just one environment because dev, test, prod is too much ceremony.

78
00:03:37,960 --> 00:03:39,280
Each one feels small.

79
00:03:39,280 --> 00:03:41,360
Over time policies drift away.

80
00:03:41,360 --> 00:03:42,600
Naming drifts.

81
00:03:42,600 --> 00:03:43,960
Relationship behavior drifts.

82
00:03:43,960 --> 00:03:47,880
And then the system still runs, but you are no longer operating a deterministic security

83
00:03:47,880 --> 00:03:48,920
and data model.

84
00:03:48,920 --> 00:03:50,840
You're operating a probabilistic one.

85
00:03:50,840 --> 00:03:52,360
That's what production feels like.

86
00:03:52,360 --> 00:03:54,120
Not broken, just unpredictable.

87
00:03:54,120 --> 00:03:57,560
And this is why SharePoint lists keep showing up as the early substrate.

88
00:03:57,560 --> 00:03:59,240
They're fast, familiar, and cheap.

89
00:03:59,240 --> 00:04:01,280
They also train teams into flat thinking.

90
00:04:01,280 --> 00:04:05,520
You can get surprisingly far with flat thinking right up until the organization tries to ask

91
00:04:05,520 --> 00:04:10,080
cross-cutting questions, enforce ownership, or introduce AI that needs context.

92
00:04:10,080 --> 00:04:14,520
At that point, your list-based database collapses into duct tape and thresholds.

93
00:04:14,520 --> 00:04:18,280
And then the migration happens under stress during audit findings.

94
00:04:18,280 --> 00:04:21,400
Or when the next strategic initiative needs a real system of truth.

95
00:04:21,400 --> 00:04:24,360
So the real problem isn't that low-code teams move too fast.

96
00:04:24,360 --> 00:04:26,520
It's that they move fast without deciding what's true.

97
00:04:26,520 --> 00:04:30,480
And dataverse, when used properly, is Microsoft trying to force that decision earlier,

98
00:04:30,480 --> 00:04:31,720
while it's still cheap.

99
00:04:31,720 --> 00:04:35,960
Because once you have three apps, ten flows, five reports, and one copilot agent depending

100
00:04:35,960 --> 00:04:38,680
on your model, changing meaning is no longer refactoring.

101
00:04:38,680 --> 00:04:40,840
It's rewriting history.

102
00:04:40,840 --> 00:04:43,040
That distinction matters.

103
00:04:43,040 --> 00:04:45,440
And it leads directly to the next point.

104
00:04:45,440 --> 00:04:48,520
Dataverse is not a database in the way most people mean it.

105
00:04:48,520 --> 00:04:50,120
It's a semantics engine.

106
00:04:50,120 --> 00:04:51,400
Dataverse is not a database.

107
00:04:51,400 --> 00:04:53,120
It's a business semantics engine.

108
00:04:53,120 --> 00:04:57,120
Most organizations approach dataverse like it's just a nicer place to store rows.

109
00:04:57,120 --> 00:04:58,520
That mental model is convenient.

110
00:04:58,520 --> 00:05:00,360
It is also wrong.

111
00:05:00,360 --> 00:05:02,800
A database stores facts.

112
00:05:02,800 --> 00:05:08,440
Dataverse stores facts plus meaning, relationships, ownership, security boundaries, metadata,

113
00:05:08,440 --> 00:05:13,440
and life cycle behavior that travel with the data across apps, automation, and increasingly

114
00:05:13,440 --> 00:05:14,440
AI.

115
00:05:14,440 --> 00:05:17,920
That distinction matters because once you treat dataverse like just storage, you start

116
00:05:17,920 --> 00:05:20,320
stripping out the exact parts that make it valuable.

117
00:05:20,320 --> 00:05:23,040
You push logic into power automate because it feels easier.

118
00:05:23,040 --> 00:05:26,240
You treat relationships like optional because the form still loads without them.

119
00:05:26,240 --> 00:05:29,520
You ignore security design because we'll add roles later.

120
00:05:29,520 --> 00:05:33,880
And then you end up with the same chaos you had before just with a different price tag.

121
00:05:33,880 --> 00:05:36,880
In architectural terms, dataverse is a business semantics engine.

122
00:05:36,880 --> 00:05:39,760
It takes the messy human version of your business.

123
00:05:39,760 --> 00:05:44,160
Things like customer, case, approval, asset, contract, exception.

124
00:05:44,160 --> 00:05:47,480
And forces you to encode those as durable primitives.

125
00:05:47,480 --> 00:05:49,000
Tables aren't UI scaffolding.

126
00:05:49,000 --> 00:05:50,640
Columns aren't random fields.

127
00:05:50,640 --> 00:05:51,920
Relationships aren't navigation links.

128
00:05:51,920 --> 00:05:55,200
Their commitments about what your organization believes is true.

129
00:05:55,200 --> 00:05:56,800
Think of dataverse like a compiler.

130
00:05:56,800 --> 00:05:58,200
You write intent and structure.

131
00:05:58,200 --> 00:06:01,480
Nouns attributes constraints in relationships.

132
00:06:01,480 --> 00:06:04,920
Dataverse compiles that into consistent behavior across the platform.

133
00:06:04,920 --> 00:06:05,920
Model driven apps.

134
00:06:05,920 --> 00:06:06,920
Canvas apps.

135
00:06:06,920 --> 00:06:07,920
Power automate.

136
00:06:07,920 --> 00:06:08,920
Power pages.

137
00:06:08,920 --> 00:06:11,720
And now agents that need grounded context.

138
00:06:11,720 --> 00:06:14,400
If you don't compile intent, every consumer interprets it.

139
00:06:14,400 --> 00:06:18,000
That's the difference between a model that scales and a model that drifts.

140
00:06:18,000 --> 00:06:21,080
This is why Blendt keeps repeating that it's not about the license.

141
00:06:21,080 --> 00:06:22,800
It's the language underneath.

142
00:06:22,800 --> 00:06:25,640
The license conversation is always louder because it's easy.

143
00:06:25,640 --> 00:06:27,160
Meaning is quieter because it's work.

144
00:06:27,160 --> 00:06:30,160
But meaning is what you're actually buying when you adopt dataverse.

145
00:06:30,160 --> 00:06:31,960
Dataverse has built in gravity.

146
00:06:31,960 --> 00:06:35,760
It nudges teams toward consistent definitions because the platform rewards it.

147
00:06:35,760 --> 00:06:37,800
If you define an ownership model,

148
00:06:37,800 --> 00:06:41,760
security can be expressed in roles rather than in tribal rules.

149
00:06:41,760 --> 00:06:46,440
If you define relationships properly, model driven apps stop being fragile screen flows and

150
00:06:46,440 --> 00:06:48,680
become different views over the same truth.

151
00:06:48,680 --> 00:06:52,720
If you name things consistently and add descriptions, you don't just help humans.

152
00:06:52,720 --> 00:06:56,760
You reduce ambiguity for every system that depends on metadata including copilot and

153
00:06:56,760 --> 00:06:58,040
agentec tooling.

154
00:06:58,040 --> 00:07:00,640
And if you don't do those things, dataverse doesn't break immediately.

155
00:07:00,640 --> 00:07:02,000
It does something worse.

156
00:07:02,000 --> 00:07:05,960
It lets you succeed just enough to scale the mistake because the platform is strong enough

157
00:07:05,960 --> 00:07:08,040
to carry a weak model for a while.

158
00:07:08,040 --> 00:07:11,520
And then when you reach the point where multiple apps converge on the same schema, the lack

159
00:07:11,520 --> 00:07:13,640
of semantics turns into friction.

160
00:07:13,640 --> 00:07:18,600
In consistent reporting, unpredictable security, integration confusion and AI that can't

161
00:07:18,600 --> 00:07:21,720
retrieve meaning because you never made it explicit.

162
00:07:21,720 --> 00:07:22,720
Here's the weird part.

163
00:07:22,720 --> 00:07:25,280
Dataverse isn't trying to make building apps harder.

164
00:07:25,280 --> 00:07:27,800
It's trying to make building reality unavoidable.

165
00:07:27,800 --> 00:07:31,800
That's why the feature set feels opinionated compared to a simple list or a generic SQL

166
00:07:31,800 --> 00:07:32,800
table.

167
00:07:32,800 --> 00:07:35,560
You get solutions and environments because deployment is part of meaning.

168
00:07:35,560 --> 00:07:39,320
You get role-based security and ownership because access is part of meaning.

169
00:07:39,320 --> 00:07:41,040
You get relationship behavior.

170
00:07:41,040 --> 00:07:44,960
Parental, referential restricted because data integrity is part of meaning.

171
00:07:44,960 --> 00:07:48,760
Those relationship behavior sound like implementation detail until your in-production

172
00:07:48,760 --> 00:07:52,920
and someone asks if we delete the parent what happens to the child records.

173
00:07:52,920 --> 00:07:57,480
If your answer is it depends, that's not flexibility, that's unbounded risk.

174
00:07:57,480 --> 00:08:02,920
And dataverse is built to make those risks explicit early when you can still decide intentionally.

175
00:08:02,920 --> 00:08:05,200
For leaders, this is the strategic shift.

176
00:08:05,200 --> 00:08:07,840
Dataability becomes a platform capability, not a heroic effort.

177
00:08:07,840 --> 00:08:11,880
A good dataverse model is how an organization scales shared language.

178
00:08:11,880 --> 00:08:15,360
It's how a new app can be built without renegotiating what customer means.

179
00:08:15,360 --> 00:08:19,840
It's how a new integration can map to stable identifiers instead of fragile strings.

180
00:08:19,840 --> 00:08:23,520
It's how an audit question can be answered by structure, not by a meeting.

181
00:08:23,520 --> 00:08:27,680
So when people say dataverse is a database, what they're really saying is, we plan to use

182
00:08:27,680 --> 00:08:31,760
it like storage and storage is never the hard part, meaning is.

183
00:08:31,760 --> 00:08:36,400
Once you accept that dataverse is a semantics engine, you also accept the consequence.

184
00:08:36,400 --> 00:08:37,400
Modeling isn't busy work.

185
00:08:37,400 --> 00:08:40,960
It's how you encode intent so the platform can enforce it at scale.

186
00:08:40,960 --> 00:08:43,360
And that leads to the next uncomfortable truth.

187
00:08:43,360 --> 00:08:49,640
If modeling encodes intent, then modeling is leadership work, whether you admit it or not.

188
00:08:49,640 --> 00:08:51,920
Why data modeling is a leadership topic?

189
00:08:51,920 --> 00:08:54,840
Most organizations pretend data modeling is a technical detail.

190
00:08:54,840 --> 00:08:59,240
That's convenient because it means leadership can focus on delivery dates, adoption numbers,

191
00:08:59,240 --> 00:09:00,800
and licensing spreadsheets.

192
00:09:00,800 --> 00:09:03,400
While someone else handles the data.

193
00:09:03,400 --> 00:09:07,400
That delegation is the original sin because the model isn't an implementation detail.

194
00:09:07,400 --> 00:09:11,560
It's a set of decisions about what the business is, what it cares about, and what it's willing

195
00:09:11,560 --> 00:09:12,560
to enforce.

196
00:09:12,560 --> 00:09:16,160
Those are leadership decisions even when they're made silently by whoever built the first

197
00:09:16,160 --> 00:09:17,760
table on a Friday afternoon.

198
00:09:17,760 --> 00:09:18,840
And here's the part people hate.

199
00:09:18,840 --> 00:09:20,240
The model will outlive the app.

200
00:09:20,240 --> 00:09:24,080
Apps get rewritten, screens get redesigned, power automate, flows get replaced, but the

201
00:09:24,080 --> 00:09:25,800
data model becomes sediment.

202
00:09:25,800 --> 00:09:27,200
It accumulates assumptions.

203
00:09:27,200 --> 00:09:31,400
It becomes the shared substrate everyone builds on even when nobody admits their building

204
00:09:31,400 --> 00:09:32,400
on it.

205
00:09:32,400 --> 00:09:36,760
So when leaders treat modeling as something the makers do, what they're really doing is outsourcing

206
00:09:36,760 --> 00:09:41,560
the definition of reality and then they act surprised when reality becomes ungovernable.

207
00:09:41,560 --> 00:09:43,400
This is the uncomfortable truth.

208
00:09:43,400 --> 00:09:47,240
Governance, compliance, and auditability aren't layers you bolt on later.

209
00:09:47,240 --> 00:09:50,760
They emerge from structure or they don't exist if you want predictable behavior under

210
00:09:50,760 --> 00:09:55,560
stress and audit, a breach, a regulatory request, a merger, then you need the system to

211
00:09:55,560 --> 00:09:59,880
answer questions deterministically, who owns this record, who can see it, who changed

212
00:09:59,880 --> 00:10:04,240
it, what does approved mean, what does closed mean, what happens when the parent is removed,

213
00:10:04,240 --> 00:10:06,640
those questions don't get answered by policy memos.

214
00:10:06,640 --> 00:10:10,560
They get answered by the authorization graph, the relationship behavior, the constraints,

215
00:10:10,560 --> 00:10:13,320
and the metadata you encoded or fail to encode.

216
00:10:13,320 --> 00:10:16,800
That distinction matters because it explains why so many governance initiatives feel like

217
00:10:16,800 --> 00:10:17,800
theatre.

218
00:10:17,800 --> 00:10:21,680
They write documents, they build slide decks, they create committees, but the platform

219
00:10:21,680 --> 00:10:24,520
keeps operating according to the model, not the memo.

220
00:10:24,520 --> 00:10:28,880
If you always win when intent is not enforced by design, so if leaders want fewer incidents

221
00:10:28,880 --> 00:10:32,860
and fewer two AM war rooms, they don't need more governance documents, they need fewer

222
00:10:32,860 --> 00:10:34,280
ambiguous models.

223
00:10:34,280 --> 00:10:39,600
And that means leadership has to take ownership of a simple but brutal responsibility, naming

224
00:10:39,600 --> 00:10:42,240
and defining the core concepts of the business.

225
00:10:42,240 --> 00:10:48,160
Not the app features, the nouns, customer, vendor, request, case, asset, policy, exception,

226
00:10:48,160 --> 00:10:51,240
approval, department, project.

227
00:10:51,240 --> 00:10:55,120
If those words mean different things to different teams, dataverse will faithfully scale that

228
00:10:55,120 --> 00:10:57,320
confusion across every app you build.

229
00:10:57,320 --> 00:11:00,160
It doesn't fix organizational ambiguity, it amplifies it.

230
00:11:00,160 --> 00:11:04,080
That's why good model scale clarity, bad model scale meetings.

231
00:11:04,080 --> 00:11:07,960
Because when the model is clear, teams stop arguing about what a thing is.

232
00:11:07,960 --> 00:11:11,120
They can argue about what to do with it, which is at least productive.

233
00:11:11,120 --> 00:11:14,880
When the model is vague, every meeting turns into a translation exercise.

234
00:11:14,880 --> 00:11:19,720
People spend time negotiating semantics instead of executing, and once AI enters the picture,

235
00:11:19,720 --> 00:11:21,880
the cost of semantic drift becomes visible.

236
00:11:21,880 --> 00:11:23,800
Humans can compensate for ambiguity.

237
00:11:23,800 --> 00:11:25,320
They remember context.

238
00:11:25,320 --> 00:11:30,360
They know that status, exo, other really means waiting on procurement because they were

239
00:11:30,360 --> 00:11:32,680
in the meeting when it was decided.

240
00:11:32,680 --> 00:11:34,000
Agents don't have that meeting memory.

241
00:11:34,000 --> 00:11:38,120
They have whatever you made explicit in the model, plus whatever your metadata implies.

242
00:11:38,120 --> 00:11:41,360
If you didn't define ownership, you can't reliably enforce access.

243
00:11:41,360 --> 00:11:44,320
If you didn't define relationships, you can't reliably retrieve context.

244
00:11:44,320 --> 00:11:48,520
If you didn't define stable identifiers, you can't reliably integrate without brittle

245
00:11:48,520 --> 00:11:49,520
string matching.

246
00:11:49,520 --> 00:11:54,000
So, leadership's job becomes less about approving apps and more about enforcing assumptions

247
00:11:54,000 --> 00:11:55,000
at scale.

248
00:11:55,000 --> 00:11:57,640
And no, that does not mean leaders should micromanage table design.

249
00:11:57,640 --> 00:12:02,560
It means leaders should demand clarity and then fund the work to encode that clarity.

250
00:12:02,560 --> 00:12:06,200
This is where most organizations fall into the delegation trap.

251
00:12:06,200 --> 00:12:11,080
They ask a team to build an app, but they don't ask anyone to define the system of truth.

252
00:12:11,080 --> 00:12:13,760
They don't appoint an accountable owner for the data model.

253
00:12:13,760 --> 00:12:16,680
They don't decide what gets standardized and what stays local.

254
00:12:16,680 --> 00:12:19,600
They don't decide which concepts are global and which are contextual.

255
00:12:19,600 --> 00:12:22,800
So the team makes those decisions implicitly under delivery pressure.

256
00:12:22,800 --> 00:12:27,480
And later, the organization pays for them explicitly under operational pressure.

257
00:12:27,480 --> 00:12:30,960
If you want a simple leadership test for Dataverse, ask who owns the model.

258
00:12:30,960 --> 00:12:32,840
Not who built the app, who owns the model.

259
00:12:32,840 --> 00:12:35,560
If the answer is IT, that usually means nobody.

260
00:12:35,560 --> 00:12:38,680
If the answer is the makers, that means chaos with good intentions.

261
00:12:38,680 --> 00:12:43,120
If the answer is the business, but nobody can name a specific role with authority, that

262
00:12:43,120 --> 00:12:44,120
means meetings.

263
00:12:44,120 --> 00:12:45,880
A real owner makes the model a product.

264
00:12:45,880 --> 00:12:47,840
They defend it, they evolve it deliberately.

265
00:12:47,840 --> 00:12:49,280
They resist entropy generators.

266
00:12:49,280 --> 00:12:53,080
They align environments, solutions and releases to protect stability.

267
00:12:53,080 --> 00:12:56,000
Because in Dataverse, the model is the strategy surface.

268
00:12:56,000 --> 00:12:59,720
And leadership either shapes it on purpose or inherits it by accident.

269
00:12:59,720 --> 00:13:03,600
From tables to business concepts, what a table really represents.

270
00:13:03,600 --> 00:13:06,800
Everything gets simpler when you stop treating a table like storage and start treating it

271
00:13:06,800 --> 00:13:08,000
like a statement.

272
00:13:08,000 --> 00:13:12,120
Every table is a business decision, not a technical one, a decision.

273
00:13:12,120 --> 00:13:16,920
When you create a table, you're declaring this thing exists in our world, it has a life cycle,

274
00:13:16,920 --> 00:13:21,000
it has owners, it has rules, and we intend to ask questions about it later.

275
00:13:21,000 --> 00:13:24,720
And when you don't create a table, when you hide the concept inside a text field, a choice

276
00:13:24,720 --> 00:13:28,320
column or worse, a spreadsheet, you're declaring the opposite.

277
00:13:28,320 --> 00:13:29,840
This concept is optional.

278
00:13:29,840 --> 00:13:33,120
We won't protect it, we won't govern it, we won't reason over it.

279
00:13:33,120 --> 00:13:35,320
That's why modeling isn't about being tidy.

280
00:13:35,320 --> 00:13:38,520
It's about choosing what reality your platform is allowed to remember.

281
00:13:38,520 --> 00:13:41,640
Most teams start from screens, because screens are visible.

282
00:13:41,640 --> 00:13:44,120
You can point to a form and say, "Look, progress."

283
00:13:44,120 --> 00:13:46,200
You can demo a button and call it value.

284
00:13:46,200 --> 00:13:51,240
So the model becomes a reflection of UI needs, one table per screen, one column per input,

285
00:13:51,240 --> 00:13:53,400
one lookup, because the drop down needed it.

286
00:13:53,400 --> 00:13:57,640
That screen driven modeling, and it always collapses under time, because the UI is the most

287
00:13:57,640 --> 00:13:59,600
volatile part of the system.

288
00:13:59,600 --> 00:14:04,280
People change forms constantly, new fields, new sections, new views, new, just one more

289
00:14:04,280 --> 00:14:05,280
requirements.

290
00:14:05,280 --> 00:14:08,040
If your model mirrors screens, you guarantee schema churn.

291
00:14:08,040 --> 00:14:11,280
And schema churn is how you create operational debt in dataverse, because every

292
00:14:11,280 --> 00:14:16,640
downstream artifact attaches to schema, flows, reports, integrations, business rules, plugins,

293
00:14:16,640 --> 00:14:19,040
agents, and yes, security assumptions.

294
00:14:19,040 --> 00:14:22,200
Everything clicked for a lot of teams when they realize the simple distinction.

295
00:14:22,200 --> 00:14:26,040
Tables are nouns, processes are verbs.

296
00:14:26,040 --> 00:14:29,440
A table should represent a business noun that exists across time.

297
00:14:29,440 --> 00:14:34,560
Customer, case, contract, asset, policy, approval, exception, invoice, claim.

298
00:14:34,560 --> 00:14:35,560
Those are durable concepts.

299
00:14:35,560 --> 00:14:39,000
A process should be expressed as behavior around those nouns.

300
00:14:39,000 --> 00:14:43,320
Validations, rooting, notifications, calculations, and state changes.

301
00:14:43,320 --> 00:14:46,560
The foundational mistake is when teams store verbs as columns.

302
00:14:46,560 --> 00:14:51,360
They create fields like step one completed, step two completed, approval number three,

303
00:14:51,360 --> 00:14:55,840
current approver, previous approver, escalation reason, escalation reason two.

304
00:14:55,840 --> 00:14:56,840
That's not modeling.

305
00:14:56,840 --> 00:14:59,800
That's an abandoned workflow engine trapped inside a table.

306
00:14:59,800 --> 00:15:05,040
It feels fast until you need to change the process, because now your schema is your workflow.

307
00:15:05,040 --> 00:15:06,280
Dataverse will let you do this.

308
00:15:06,280 --> 00:15:08,960
Dataverse will also make you regret it, because processes change more frequently.

309
00:15:08,960 --> 00:15:10,240
Then nouns.

310
00:15:10,240 --> 00:15:14,520
If you bake the process into the table schema, you force breaking changes every time the business

311
00:15:14,520 --> 00:15:16,200
learns something new.

312
00:15:16,200 --> 00:15:20,400
If you keep the noun clean and express the process through related entities, like approvals,

313
00:15:20,400 --> 00:15:25,920
assignments, decisions, exceptions, you get a model that can evolve without rewriting history.

314
00:15:25,920 --> 00:15:27,680
Columns are commitments.

315
00:15:27,680 --> 00:15:29,960
A column is not a place to put data.

316
00:15:29,960 --> 00:15:30,960
It's a promise.

317
00:15:30,960 --> 00:15:31,960
We will keep this true.

318
00:15:31,960 --> 00:15:32,960
We will validate it.

319
00:15:32,960 --> 00:15:34,960
We will secure it and we will query it.

320
00:15:34,960 --> 00:15:37,160
That means every column should earn its existence.

321
00:15:37,160 --> 00:15:40,600
If you add a column, because someone asked for it in a meeting, but nobody can say what

322
00:15:40,600 --> 00:15:43,640
decision will be made from it, that column becomes future confusion.

323
00:15:43,640 --> 00:15:47,320
It becomes a place where people put different interpretations and then AI has to guess which

324
00:15:47,320 --> 00:15:48,840
interpretation is correct.

325
00:15:48,840 --> 00:15:50,880
And relationships are reality.

326
00:15:50,880 --> 00:15:53,680
Relationships are the part that most teams treat like plumbing, because in the UI they look

327
00:15:53,680 --> 00:15:55,280
like navigation links.

328
00:15:55,280 --> 00:16:00,400
But a relationship is you, writing the business story in cardinalities and behavior.

329
00:16:00,400 --> 00:16:01,800
One too many is structure.

330
00:16:01,800 --> 00:16:03,120
One customer has many cases.

331
00:16:03,120 --> 00:16:04,600
One contract has many amendments.

332
00:16:04,600 --> 00:16:06,520
One project has many tasks.

333
00:16:06,520 --> 00:16:09,400
Many to many is policy when the association itself matters.

334
00:16:09,400 --> 00:16:12,480
People and skills, users and roles, products and categories.

335
00:16:12,480 --> 00:16:15,760
When you need to govern the relationship, not just reference it, the relationship becomes

336
00:16:15,760 --> 00:16:17,320
its own first class concept.

337
00:16:17,320 --> 00:16:21,440
The weird part is that this is where low code doesn't mean low thinking becomes brutally

338
00:16:21,440 --> 00:16:22,440
true.

339
00:16:22,440 --> 00:16:25,120
Because datavers will happily let you build apps with a weak model.

340
00:16:25,120 --> 00:16:29,480
It will also happily scale your weak model into five apps, ten flows and a co-pilot agent

341
00:16:29,480 --> 00:16:31,040
that answers with a shrug.

342
00:16:31,040 --> 00:16:33,640
So here's the mental move that changes everything.

343
00:16:33,640 --> 00:16:38,040
When you sketch a table, don't ask, what fields do we need on the form?

344
00:16:38,040 --> 00:16:39,040
Ask.

345
00:16:39,040 --> 00:16:42,480
What thing exists in our business even when no one is looking at the screen?

346
00:16:42,480 --> 00:16:44,160
If it exists, it deserves a noun.

347
00:16:44,160 --> 00:16:46,280
If it has a life cycle, it deserves a table.

348
00:16:46,280 --> 00:16:50,040
If it relates to other things, it deserves relationships that encode that truth.

349
00:16:50,040 --> 00:16:54,320
And once you model nouns instead of screens, you discover where the leverage actually is.

350
00:16:54,320 --> 00:16:56,720
Not in more columns in relationships.

351
00:16:56,720 --> 00:16:57,720
Relationships.

352
00:16:57,720 --> 00:16:58,920
How the organization actually works.

353
00:16:58,920 --> 00:17:00,720
Not how the UI looks.

354
00:17:00,720 --> 00:17:04,200
Relationships are where dataverse stops being tables and fields and starts behaving like

355
00:17:04,200 --> 00:17:05,200
an organization.

356
00:17:05,200 --> 00:17:07,880
Most teams treat relationships as a UI convenience.

357
00:17:07,880 --> 00:17:10,440
I need to drop down here, so I'll add a look up.

358
00:17:10,440 --> 00:17:11,440
That's not a relationship.

359
00:17:11,440 --> 00:17:13,400
That's a form control with a database behind it.

360
00:17:13,400 --> 00:17:16,560
A real relationship is an assertion about reality.

361
00:17:16,560 --> 00:17:17,840
What depends on what?

362
00:17:17,840 --> 00:17:19,200
What can exist alone?

363
00:17:19,200 --> 00:17:20,440
What gets deleted?

364
00:17:20,440 --> 00:17:21,680
What gets reassigned?

365
00:17:21,680 --> 00:17:22,760
What gets shared?

366
00:17:22,760 --> 00:17:24,000
And what gets inherited?

367
00:17:24,000 --> 00:17:28,560
In other words, how your organization actually works when nobody is looking at the screen.

368
00:17:28,560 --> 00:17:30,920
This is why relationships become the differentiator.

369
00:17:30,920 --> 00:17:32,120
They don't just connect data.

370
00:17:32,120 --> 00:17:33,440
They create context.

371
00:17:33,440 --> 00:17:37,960
Context is what makes reporting sane, integration stable and AI answers coherent.

372
00:17:37,960 --> 00:17:40,040
Without relationships, every query is blind.

373
00:17:40,040 --> 00:17:42,840
With relationships, the platform can navigate meaning.

374
00:17:42,840 --> 00:17:45,200
One too many relationships are the backbone of structure.

375
00:17:45,200 --> 00:17:46,400
One customer, many cases.

376
00:17:46,400 --> 00:17:47,720
One project, many tasks.

377
00:17:47,720 --> 00:17:48,720
One continent.

378
00:17:48,720 --> 00:17:49,720
Many countries.

379
00:17:49,720 --> 00:17:51,080
Boulin's simple workshop example.

380
00:17:51,080 --> 00:17:55,040
It sounds like dataverse 101, but it's the same pattern that decides whether your system

381
00:17:55,040 --> 00:17:58,360
behaves deterministically or degenerates into interpretation.

382
00:17:58,360 --> 00:18:01,600
One too many isn't just about navigation, it's about integrity.

383
00:18:01,600 --> 00:18:05,520
If a country belongs to exactly one continent, you shouldn't represent that with a text field

384
00:18:05,520 --> 00:18:09,200
called continent name and hope everyone spells Europe the same way.

385
00:18:09,200 --> 00:18:13,200
You represent it with a relationship that makes the association explicit, enforceable

386
00:18:13,200 --> 00:18:14,200
and queryable.

387
00:18:14,200 --> 00:18:17,840
Now the platform can do what platforms do, prevent contradictions, support consistent

388
00:18:17,840 --> 00:18:21,720
filtering, and reuse the same structure across multiple apps.

389
00:18:21,720 --> 00:18:24,280
And then there's the part most teams skip.

390
00:18:24,280 --> 00:18:25,280
Relationship behavior.

391
00:18:25,280 --> 00:18:27,280
And calls this out directly.

392
00:18:27,280 --> 00:18:29,080
Relationships aren't just connections.

393
00:18:29,080 --> 00:18:30,600
Behavior matters.

394
00:18:30,600 --> 00:18:34,920
Dataverse forces you to decide what happens when the parent changes or disappears.

395
00:18:34,920 --> 00:18:38,280
Referential, parental, restrict, custom.

396
00:18:38,280 --> 00:18:41,160
These aren't academic settings, they're operational consequences.

397
00:18:41,160 --> 00:18:44,480
If you delete a parent record, do child records get deleted too?

398
00:18:44,480 --> 00:18:47,360
That's parental behavior, in some domains that's correct.

399
00:18:47,360 --> 00:18:50,120
If the parent never existed, the child shouldn't exist.

400
00:18:50,120 --> 00:18:51,680
In other domains it's a disaster.

401
00:18:51,680 --> 00:18:55,000
We deleted the customer, therefore we deleted the cases.

402
00:18:55,000 --> 00:18:56,680
It's a way to lose audit evidence.

403
00:18:56,680 --> 00:19:00,160
If you restrict deletes, you're saying the system will block you until you resolve the

404
00:19:00,160 --> 00:19:01,160
dependency.

405
00:19:01,160 --> 00:19:02,640
That feels annoying in a demo.

406
00:19:02,640 --> 00:19:03,920
In production it's a safety rail.

407
00:19:03,920 --> 00:19:07,600
If you keep it referential, you're saying the link matters, but the child can survive if

408
00:19:07,600 --> 00:19:09,080
the parent is removed.

409
00:19:09,080 --> 00:19:13,760
That's often the right call when the child record is evidence, history or legal artifact.

410
00:19:13,760 --> 00:19:17,000
This is why relationship design is not just data modeling.

411
00:19:17,000 --> 00:19:18,960
It's policy encoded as behavior.

412
00:19:18,960 --> 00:19:22,920
And many too many relationships are where teams either get serious or get sloppy.

413
00:19:22,920 --> 00:19:26,320
Too many is what you use when the relationship itself matters.

414
00:19:26,320 --> 00:19:30,040
People and skills, contracts and clauses, products and categories, agents in the cases

415
00:19:30,040 --> 00:19:31,040
they touched.

416
00:19:31,040 --> 00:19:35,640
This is not a list of tags, this is a business fact that deserves its own life cycle when

417
00:19:35,640 --> 00:19:36,640
it carries meaning.

418
00:19:36,640 --> 00:19:40,640
A common mistake is trying to fake many too many with multiple look up fields.

419
00:19:40,640 --> 00:19:42,720
Vehicle one, vehicle two, vehicle three.

420
00:19:42,720 --> 00:19:44,960
Or a proven one, a proven two, a proven three.

421
00:19:44,960 --> 00:19:48,720
It works until the fourth one exists and the fourth one always exists.

422
00:19:48,720 --> 00:19:52,880
The better mental model is, if the association can have attributes, it's not a link.

423
00:19:52,880 --> 00:19:54,080
It's an entity.

424
00:19:54,080 --> 00:19:59,040
User assigned to case becomes assignment with timestamps, reasons, escalation flags and audit

425
00:19:59,040 --> 00:20:00,040
trail.

426
00:20:00,040 --> 00:20:05,560
Agent touched record becomes agent interaction with state, outcome and confidence.

427
00:20:05,560 --> 00:20:10,360
Now you can query it, secure it, report it and give AI something grounded to retrieve.

428
00:20:10,360 --> 00:20:13,000
This is also where the SharePoint pattern collapses.

429
00:20:13,000 --> 00:20:16,400
SharePoint lookups are not relational integrity, they are references.

430
00:20:16,400 --> 00:20:20,040
And references without behavior create ambiguity at scale.

431
00:20:20,040 --> 00:20:24,660
Different items, duplicated meanings and brittle reporting logic that someone will eventually

432
00:20:24,660 --> 00:20:26,720
fix in Excel.

433
00:20:26,720 --> 00:20:30,520
So the practical rule is simple, model the relationship the way the business would explain

434
00:20:30,520 --> 00:20:31,680
it out loud.

435
00:20:31,680 --> 00:20:37,280
If the explanation includes and when that happens we then the relationship has behavior.

436
00:20:37,280 --> 00:20:41,040
And if you can't explain the relationship clearly, that's your signal, the organization

437
00:20:41,040 --> 00:20:42,920
doesn't agree on reality yet.

438
00:20:42,920 --> 00:20:45,920
Don't hide that disagreement inside a lookup, resolve it.

439
00:20:45,920 --> 00:20:48,840
Because once AI shows up, it will not ask politely.

440
00:20:48,840 --> 00:20:53,480
It will traverse whatever graph you gave it and return whatever story your relationships

441
00:20:53,480 --> 00:20:54,480
imply.

442
00:20:54,480 --> 00:20:58,920
Accurate relationships don't just make apps nicer, they make the organization legible.

443
00:20:58,920 --> 00:21:00,400
Solutions and environments.

444
00:21:00,400 --> 00:21:03,120
Why delivery is an architecture decision?

445
00:21:03,120 --> 00:21:07,600
Once relationships are correct, most teams make the next predictable mistake.

446
00:21:07,600 --> 00:21:10,400
They treat delivery like an operational detail.

447
00:21:10,400 --> 00:21:14,240
They build in whatever environment is convenient, they ship by exporting whatever they remember

448
00:21:14,240 --> 00:21:15,240
to export.

449
00:21:15,240 --> 00:21:19,720
They fix issues by editing production directly because it's faster and then they look confused

450
00:21:19,720 --> 00:21:22,080
when the platform becomes undeployable.

451
00:21:22,080 --> 00:21:25,400
Dataverse doesn't separate delivery from architecture, it makes delivery part of the

452
00:21:25,400 --> 00:21:26,400
model.

453
00:21:26,400 --> 00:21:29,920
Environments are not just places to click around, they are boundaries where different versions

454
00:21:29,920 --> 00:21:32,440
of reality exist at the same time.

455
00:21:32,440 --> 00:21:36,680
Development is where you experiment, test is where you validate the behavior under stress.

456
00:21:36,680 --> 00:21:40,360
Production is where you stop experimenting because the business is paying for stability.

457
00:21:40,360 --> 00:21:44,640
If you blur those boundaries, you don't just risk bugs, you create meaning drift.

458
00:21:44,640 --> 00:21:48,560
Because the schema you're changing is not a neutral object, it is the definition every

459
00:21:48,560 --> 00:21:51,280
app flow report an agent depends on.

460
00:21:51,280 --> 00:21:55,720
When you make changes in production, you're rewriting the rules while the game is in progress.

461
00:21:55,720 --> 00:21:57,760
Boulince Warning here is blunt.

462
00:21:57,760 --> 00:22:00,480
Live development in production never ends well.

463
00:22:00,480 --> 00:22:01,480
Never.

464
00:22:01,480 --> 00:22:05,240
Not because the platform is fragile, but because humans are, people forget what they change,

465
00:22:05,240 --> 00:22:09,280
they forget why they changed it, they leave half finished artifacts in the active layer

466
00:22:09,280 --> 00:22:12,880
and then the next deployment fails because the environment is no longer what you think

467
00:22:12,880 --> 00:22:13,880
it is.

468
00:22:13,880 --> 00:22:15,000
That's where solutions matter.

469
00:22:15,000 --> 00:22:20,040
A solution is not a zip file, it is a transport mechanism for metadata, tables, columns,

470
00:22:20,040 --> 00:22:27,120
relationships, forms, views, apps, flows, security roles, environment variables and now increasingly

471
00:22:27,120 --> 00:22:29,240
copilot and agent components.

472
00:22:29,240 --> 00:22:34,000
And that metadata only detail is the one that keeps hurting people because teams assume

473
00:22:34,000 --> 00:22:36,400
a solution is how you move business data.

474
00:22:36,400 --> 00:22:39,120
It isn't, it's how you move the definition of the system.

475
00:22:39,120 --> 00:22:41,960
The schema, not the rows, the contract, not the content.

476
00:22:41,960 --> 00:22:45,560
So when someone asks, can we just export the solution and we'll have production data too?

477
00:22:45,560 --> 00:22:48,640
The answer is no and the follow up answer is the one nobody likes.

478
00:22:48,640 --> 00:22:51,960
If you build a deployment process, assuming that you didn't build deployment, you build

479
00:22:51,960 --> 00:22:52,960
copying.

480
00:22:52,960 --> 00:22:55,920
This distinction matters because ALM is not a DevOps hobby.

481
00:22:55,920 --> 00:22:57,960
It's how you prevent architectural erosion.

482
00:22:57,960 --> 00:23:00,240
If you can't deploy repeatedly, you can't govern change.

483
00:23:00,240 --> 00:23:03,360
If you can't govern change, your model becomes a moving target.

484
00:23:03,360 --> 00:23:07,160
If your model becomes a moving target, every integration becomes brittle, every report

485
00:23:07,160 --> 00:23:12,160
becomes suspect and every copilot prompt becomes a workaround for schema ambiguity.

486
00:23:12,160 --> 00:23:16,360
Now at the managed versus unmanaged tension, unmanaged solutions are freedom now.

487
00:23:16,360 --> 00:23:21,520
Managed solutions are control later and teams love freedom right up until they need rollback,

488
00:23:21,520 --> 00:23:25,280
auditability and the ability to say this is what's deployed and this is why.

489
00:23:25,280 --> 00:23:28,120
The unmanaged approach leaves you with environment pollution.

490
00:23:28,120 --> 00:23:29,120
Changes stick around.

491
00:23:29,120 --> 00:23:30,720
Active layer overrides become permanent.

492
00:23:30,720 --> 00:23:32,160
You can't cleanly uninstall.

493
00:23:32,160 --> 00:23:34,040
You can't reason about dependencies.

494
00:23:34,040 --> 00:23:38,520
And when something goes wrong, troubleshooting turns into which version of reality is this

495
00:23:38,520 --> 00:23:40,480
environment actually running?

496
00:23:40,480 --> 00:23:43,520
Managed solutions in contrast give you a control deployment surface.

497
00:23:43,520 --> 00:23:47,560
You can version, you can patch, you can uninstall, you can reduce the number of hands modifying

498
00:23:47,560 --> 00:23:49,960
production, you trade convenience for determinism.

499
00:23:49,960 --> 00:23:52,440
Yes, dependency management can become a headache.

500
00:23:52,440 --> 00:23:55,200
Yes, layering can slow you down when you're debugging.

501
00:23:55,200 --> 00:23:57,040
But the alternative is not fast.

502
00:23:57,040 --> 00:23:58,760
The alternative is conditional chaos.

503
00:23:58,760 --> 00:24:01,080
And here's the leadership angle again.

504
00:24:01,080 --> 00:24:03,080
Business and solutions are not engineering ceremony.

505
00:24:03,080 --> 00:24:07,040
They are how you defend meaning over time because every time you allow just this once,

506
00:24:07,040 --> 00:24:10,560
changes in production, you're teaching the organization that intent is optional.

507
00:24:10,560 --> 00:24:14,400
You're teaching them that the model is negotiable and negotiation always accumulates.

508
00:24:14,400 --> 00:24:19,080
So the minimum viable discipline in data verse is simple, a development environment, a test

509
00:24:19,080 --> 00:24:23,080
environment and a production environment, a solution strategy that defines what moves

510
00:24:23,080 --> 00:24:24,080
and how.

511
00:24:24,080 --> 00:24:27,240
And a bias toward managed deployments once you leave experimentation.

512
00:24:27,240 --> 00:24:29,440
If you don't do this, the platform will still run.

513
00:24:29,440 --> 00:24:33,760
It will also quietly convert your system of truth into a system of exceptions.

514
00:24:33,760 --> 00:24:36,920
And the first real wake up call is almost always the same.

515
00:24:36,920 --> 00:24:37,920
SharePoint.

516
00:24:37,920 --> 00:24:41,360
Scenario one, SharePoint to data verse, convenience versus correctness.

517
00:24:41,360 --> 00:24:44,440
Most organizations don't choose SharePoint lists as a database.

518
00:24:44,440 --> 00:24:45,440
They drift into it.

519
00:24:45,440 --> 00:24:46,440
It's already there.

520
00:24:46,440 --> 00:24:47,440
Everyone has access.

521
00:24:47,440 --> 00:24:50,480
Someone can make a list in 10 minutes at a couple columns and suddenly the business feels

522
00:24:50,480 --> 00:24:53,240
like it got an app without asking IT for permission.

523
00:24:53,240 --> 00:24:54,560
That early momentum is real.

524
00:24:54,560 --> 00:24:57,800
It's also the start of a very specific failure pattern.

525
00:24:57,800 --> 00:25:02,320
This becomes the data model and then everyone builds policy on top of convenience.

526
00:25:02,320 --> 00:25:06,240
SharePoint lists feel good enough early because they're optimized for the first week.

527
00:25:06,240 --> 00:25:11,240
Flat data, simple forms, quick views and a UI that trains people to think in columns,

528
00:25:11,240 --> 00:25:12,320
not concepts.

529
00:25:12,320 --> 00:25:17,000
And when the problem is truly a list, tasks, simple intake, lightweight tracking, SharePoint

530
00:25:17,000 --> 00:25:18,360
can be the right substrate.

531
00:25:18,360 --> 00:25:21,680
The problem is what happens when the list stops being a list.

532
00:25:21,680 --> 00:25:24,200
Because the business never keeps it as just a list.

533
00:25:24,200 --> 00:25:25,440
They add relationships.

534
00:25:25,440 --> 00:25:26,760
They add status logic.

535
00:25:26,760 --> 00:25:27,760
They add approvals.

536
00:25:27,760 --> 00:25:29,240
They add security expectations.

537
00:25:29,240 --> 00:25:30,480
They add reporting demands.

538
00:25:30,480 --> 00:25:31,640
They add automation.

539
00:25:31,640 --> 00:25:36,320
And without noticing, they've built a DIY relational database with none of the relational guarantees.

540
00:25:36,320 --> 00:25:40,320
This is where it collapses and it usually collapses in four predictable ways.

541
00:25:40,320 --> 00:25:41,840
First, relational complexity.

542
00:25:41,840 --> 00:25:45,120
The minute you need more than a couple of lookups, you're no longer managing a list.

543
00:25:45,120 --> 00:25:46,960
You're managing a graph badly.

544
00:25:46,960 --> 00:25:51,600
You're storing IDs in text fields, duplicating values to avoid look-up limits and inventing

545
00:25:51,600 --> 00:25:56,120
conventions like Title E's, customer name, project name, year because you need uniqueness

546
00:25:56,120 --> 00:25:57,920
the platform doesn't enforce.

547
00:25:57,920 --> 00:26:01,920
Second, Integrity Gaps, SharePoint will happily let you create often records.

548
00:26:01,920 --> 00:26:06,240
It will let you delete something upstream and leave downstream references pointing to nothing.

549
00:26:06,240 --> 00:26:11,200
It will let people type Europe, EU and Europe, and treat them as three different realities.

550
00:26:11,200 --> 00:26:12,560
The system doesn't know what's true.

551
00:26:12,560 --> 00:26:13,960
It knows what was entered.

552
00:26:13,960 --> 00:26:18,280
Third, scale thresholds and performance ceilings, there are hard limits and soft limits.

553
00:26:18,280 --> 00:26:21,520
And the worst part is that teams discover them mid-flight.

554
00:26:21,520 --> 00:26:22,760
Query thresholds.

555
00:26:22,760 --> 00:26:23,760
View limits.

556
00:26:23,760 --> 00:26:27,800
Indecation problems in Canvas apps, suddenly the simple list turns into a collection of

557
00:26:27,800 --> 00:26:29,080
workarounds.

558
00:26:29,080 --> 00:26:34,360
Index columns, filtered views, segmented lists, and power-automate flows that exist mostly

559
00:26:34,360 --> 00:26:35,880
to dodge the platform.

560
00:26:35,880 --> 00:26:37,840
Fourth, governance ambiguity.

561
00:26:37,840 --> 00:26:41,640
SharePoint can do security, but it's not row-level security with ownership semantics baked

562
00:26:41,640 --> 00:26:43,840
into every record as a structural primitive.

563
00:26:43,840 --> 00:26:46,440
Data versus in data versus ownership isn't an afterthought.

564
00:26:46,440 --> 00:26:47,440
Every row has an owner.

565
00:26:47,440 --> 00:26:48,880
You don't negotiate with it.

566
00:26:48,880 --> 00:26:53,320
That single design choice changes how reliably you can explain, access auditing and

567
00:26:53,320 --> 00:26:54,320
accountability.

568
00:26:54,320 --> 00:26:55,320
And that's the point.

569
00:26:55,320 --> 00:26:57,320
Data versus isn't better because it's more expensive.

570
00:26:57,320 --> 00:26:59,960
It's better because it's opinionated about correctness.

571
00:26:59,960 --> 00:27:03,080
When you move from SharePoint to Dataverse, you're not just moving data.

572
00:27:03,080 --> 00:27:06,240
You're moving from a file-in-list substrate to a business semantics substrate.

573
00:27:06,240 --> 00:27:08,480
You're choosing relationships that enforce meaning.

574
00:27:08,480 --> 00:27:13,200
You're choosing role-based security and ownership models that are native, not improvised.

575
00:27:13,200 --> 00:27:16,280
You're choosing environments and solutions, so change has a life cycle.

576
00:27:16,280 --> 00:27:18,560
Belent frames this in a way that's unusually honest.

577
00:27:18,560 --> 00:27:22,000
Dataverse isn't the answer to everything, but it's the answer when that's what you need.

578
00:27:22,000 --> 00:27:24,920
That line matters because this isn't SharePoint bashing.

579
00:27:24,920 --> 00:27:27,200
It's architectural classification.

580
00:27:27,200 --> 00:27:31,440
If the data is really documents collaboration and a lightweight index, SharePoint is doing

581
00:27:31,440 --> 00:27:32,440
its job.

582
00:27:32,440 --> 00:27:36,680
If the data is operational truth, entities with relationships, life cycle and policy,

583
00:27:36,680 --> 00:27:41,040
then SharePoint is doing cost-play as a database and you're the one maintaining the costume.

584
00:27:41,040 --> 00:27:45,000
The uncomfortable part is when leaders realize how this lesson is learned in the wild.

585
00:27:45,000 --> 00:27:46,600
It's rarely learned during design.

586
00:27:46,600 --> 00:27:49,640
It's learned during audits, incidents or integrations.

587
00:27:49,640 --> 00:27:54,080
Someone asks for a report that spans multiple lists with consistent definitions and suddenly

588
00:27:54,080 --> 00:27:57,320
the team spends weeks reconciling mismatched values.

589
00:27:57,320 --> 00:28:00,000
Someone asks who can see this record and why.

590
00:28:00,000 --> 00:28:05,040
And the answer involves site permissions, list permissions, item permissions and a spreadsheet.

591
00:28:05,040 --> 00:28:08,200
Someone asks co-pilot a simple question and gets nonsense back because the system has

592
00:28:08,200 --> 00:28:11,080
no stable relationships to retrieve context from.

593
00:28:11,080 --> 00:28:13,320
So the migration isn't just moving to dataverse.

594
00:28:13,320 --> 00:28:15,520
It's the point where the organization admits the truth.

595
00:28:15,520 --> 00:28:18,080
The system needs to be correct, not just convenient.

596
00:28:18,080 --> 00:28:21,120
And once you accept that, the next question becomes inevitable.

597
00:28:21,120 --> 00:28:25,560
If the model is the substrate for governance, then governance isn't paperwork, it's design.

598
00:28:25,560 --> 00:28:27,720
And that leads straight into the second scenario.

599
00:28:27,720 --> 00:28:33,320
Audit and compliance readiness, where dataverse stops being optional and starts being survivable.

600
00:28:33,320 --> 00:28:34,320
Scenario 2.

601
00:28:34,320 --> 00:28:36,160
Audit and compliance readiness.

602
00:28:36,160 --> 00:28:37,800
Governance by design.

603
00:28:37,800 --> 00:28:39,720
Audits don't break systems.

604
00:28:39,720 --> 00:28:42,080
They reveal what the system already is.

605
00:28:42,080 --> 00:28:46,640
Most teams treat governance like paperwork, a policy document and access review spreadsheet

606
00:28:46,640 --> 00:28:48,400
will tighten it up later, promise.

607
00:28:48,400 --> 00:28:53,200
Then in order to show up and ask a basic question, who can access this data, what can they do

608
00:28:53,200 --> 00:28:55,280
with it and how do you prove it?

609
00:28:55,280 --> 00:28:57,000
That's when the room goes quiet.

610
00:28:57,000 --> 00:29:01,800
Because the real answer is usually, it depends on whether data lives, which app you used

611
00:29:01,800 --> 00:29:04,800
and whether someone remembered to share the right thing.

612
00:29:04,800 --> 00:29:09,720
Dataverse is built to make that answer boring, predictable, defensible.

613
00:29:09,720 --> 00:29:13,120
Governance in dataverse isn't an extra layer you apply.

614
00:29:13,120 --> 00:29:19,680
It's a set of structural primitives, security roles, privileges, access levels and ownership.

615
00:29:19,680 --> 00:29:24,120
And the difference between users can't see it and users can't do it is not semantics,

616
00:29:24,120 --> 00:29:25,800
that distinction is the audit.

617
00:29:25,800 --> 00:29:29,080
Bülent's keys and rooms analogy works because it reflects the model.

618
00:29:29,080 --> 00:29:31,440
A security role is the key ring.

619
00:29:31,440 --> 00:29:36,600
Privileges are what the key can do, create, read, write, delete, append, assign, share.

620
00:29:36,600 --> 00:29:39,000
Access levels are which rooms those keys open.

621
00:29:39,000 --> 00:29:42,640
Your own records, your team's records, your business unit, parent child business units

622
00:29:42,640 --> 00:29:44,480
or the entire organization.

623
00:29:44,480 --> 00:29:48,520
That means the question, can this user view this table and the question, can this user view

624
00:29:48,520 --> 00:29:49,520
this row?

625
00:29:49,520 --> 00:29:52,000
Are different questions with different mechanisms?

626
00:29:52,000 --> 00:29:54,680
And that matters because auditors will ask both.

627
00:29:54,680 --> 00:29:58,880
The first uncomfortable reality is that dataverse security doesn't negotiate with you.

628
00:29:58,880 --> 00:29:59,880
Every row has an owner.

629
00:29:59,880 --> 00:30:00,880
That's not a suggestion.

630
00:30:00,880 --> 00:30:02,360
It's a structural rule.

631
00:30:02,360 --> 00:30:05,320
And ownership isn't a UI field you can hide and forget.

632
00:30:05,320 --> 00:30:08,280
Ownership is the foundation of row level access.

633
00:30:08,280 --> 00:30:12,160
If your model assumes this data is shared by default, you're already in conflict with

634
00:30:12,160 --> 00:30:16,720
the platform because dataverse assumes data is owned and access is granted through roles

635
00:30:16,720 --> 00:30:17,880
and scope.

636
00:30:17,880 --> 00:30:21,400
In practice, that means two things happen in mature environments.

637
00:30:21,400 --> 00:30:26,200
One, team stop treating security as who needs access to the app and start treating it as who

638
00:30:26,200 --> 00:30:29,200
needs what rights to which tables at which scope.

639
00:30:29,200 --> 00:30:34,800
Two, teams stop assigning roles at Hoc to individuals and start designing access patterns.

640
00:30:34,800 --> 00:30:37,480
Role-based access that maps to real job functions.

641
00:30:37,480 --> 00:30:42,120
And when scale shows up, team-based ownership becomes less of an option and more of a necessity.

642
00:30:42,120 --> 00:30:44,000
Because user ownership is fragile.

643
00:30:44,000 --> 00:30:45,000
People leave.

644
00:30:45,000 --> 00:30:46,000
People move departments.

645
00:30:46,000 --> 00:30:47,000
People go on leave.

646
00:30:47,000 --> 00:30:50,400
If your access model assumes individual owners, you have operational risk baked into your

647
00:30:50,400 --> 00:30:51,640
table design.

648
00:30:51,640 --> 00:30:53,840
Team ownership by contrast survives human churn.

649
00:30:53,840 --> 00:30:54,960
A team can own rows.

650
00:30:54,960 --> 00:30:57,000
A team can carry a security role.

651
00:30:57,000 --> 00:31:00,320
And membership can change without rewriting the ownership story of the data.

652
00:31:00,320 --> 00:31:04,320
This is why dataverse security is actually more of an organizational model than a technical

653
00:31:04,320 --> 00:31:05,320
setting.

654
00:31:05,320 --> 00:31:10,000
It forces you to decide, is this data personal, team-scoped, department-scoped or organization-scoped?

655
00:31:10,000 --> 00:31:12,360
And if you can't answer that, you don't have a governance problem.

656
00:31:12,360 --> 00:31:13,640
You have a definition problem.

657
00:31:13,640 --> 00:31:18,520
Then there's column-level security, which is where most will just hide it, approaches die.

658
00:31:18,520 --> 00:31:20,320
Sometimes it's not the record that sensitive.

659
00:31:20,320 --> 00:31:25,680
It's one field, salary, legal notes, health data, contract terms, disciplinary status.

660
00:31:25,680 --> 00:31:29,480
Dataverse lets you lock down specific columns so that even if someone can read the row, they

661
00:31:29,480 --> 00:31:31,720
still can't see the sensitive value.

662
00:31:31,720 --> 00:31:32,720
That's not a UX trick.

663
00:31:32,720 --> 00:31:34,160
That's enforcement at the data layer.

664
00:31:34,160 --> 00:31:37,280
Now connect this back to the earlier point about SharePoint drift.

665
00:31:37,280 --> 00:31:41,120
In SharePoint, many governance stories depend on where you put data, how you share it and

666
00:31:41,120 --> 00:31:42,640
whether people behave.

667
00:31:42,640 --> 00:31:46,000
In Dataverse, governance is model behavior.

668
00:31:46,000 --> 00:31:50,240
Roads, scopes, owners, and field-level controls.

669
00:31:50,240 --> 00:31:54,760
That's why leaders usually learn this lesson during audit preparation, not during design.

670
00:31:54,760 --> 00:31:58,680
Because governance by design sounds like overhead until the first time you have to prove it.

671
00:31:58,680 --> 00:32:02,440
And once you have to prove it, you realize the real cost isn't the work of setting roles.

672
00:32:02,440 --> 00:32:04,320
The cost is ambiguity.

673
00:32:04,320 --> 00:32:06,680
Ambiguity forces manual controls.

674
00:32:06,680 --> 00:32:09,120
Manual controls force exceptions.

675
00:32:09,120 --> 00:32:12,320
Exceptions generate entropy and entropy is what auditors call risk.

676
00:32:12,320 --> 00:32:16,600
So the strategic point of Dataverse security isn't that it gives you more knobs to turn.

677
00:32:16,600 --> 00:32:18,320
It's that it gives you fewer excuses.

678
00:32:18,320 --> 00:32:21,200
It turns access into a defined, inspecable system.

679
00:32:21,200 --> 00:32:23,280
And once that system is in place, something else happens.

680
00:32:23,280 --> 00:32:27,400
The organization starts depending on that structure, not just for audits, but for everything

681
00:32:27,400 --> 00:32:28,920
that comes next.

682
00:32:28,920 --> 00:32:31,080
Because the next wave isn't compliance, it's AI.

683
00:32:31,080 --> 00:32:33,800
And AI doesn't tolerate ambiguity with polite questions.

684
00:32:33,800 --> 00:32:35,120
It returns an answer anyway.

685
00:32:35,120 --> 00:32:38,080
The AI moment, context retrieval at scale, not magic.

686
00:32:38,080 --> 00:32:42,560
The AI moment is when weak modeling stops being an internal inconvenience and becomes externally

687
00:32:42,560 --> 00:32:43,920
visible failure.

688
00:32:43,920 --> 00:32:46,160
Because AI doesn't understand your business.

689
00:32:46,160 --> 00:32:51,160
It retrieves whatever context your system can supply, then tries to produce a coherent answer.

690
00:32:51,160 --> 00:32:52,160
That's it.

691
00:32:52,160 --> 00:32:56,320
There is no secret layer where co-pilot infers meaning you refuse to define.

692
00:32:56,320 --> 00:32:59,880
So when leaders say we'll add AI later, what they're really saying is we'll ask the most

693
00:32:59,880 --> 00:33:03,960
demanding consumer of our data to work with the least explicit version of it.

694
00:33:03,960 --> 00:33:05,280
It always ends the same way.

695
00:33:05,280 --> 00:33:08,440
The simplest way to frame this is, co-pilot doesn't invent meaning.

696
00:33:08,440 --> 00:33:10,280
It consumes meaning.

697
00:33:10,280 --> 00:33:14,320
And in Dataverse, meaning lives in the model, table names, column names, descriptions,

698
00:33:14,320 --> 00:33:16,560
relationship structure, ownership, and security boundaries.

699
00:33:16,560 --> 00:33:19,240
If those are vague, the AI doesn't get confused.

700
00:33:19,240 --> 00:33:20,320
It does something worse.

701
00:33:20,320 --> 00:33:21,320
It answers anyway.

702
00:33:21,320 --> 00:33:23,440
This is why prompt engineering is not a strategy.

703
00:33:23,440 --> 00:33:25,360
It's a tax you pay for ambiguity.

704
00:33:25,360 --> 00:33:28,400
If your data model is precise, prompts can be simple.

705
00:33:28,400 --> 00:33:31,000
Show me all open cases for this customer.

706
00:33:31,000 --> 00:33:33,880
If your model is mush, prompts turn into legal documents.

707
00:33:33,880 --> 00:33:38,360
When I say case, I mean the service request table, except when type is incident, and ignore

708
00:33:38,360 --> 00:33:44,280
rows where status is other and join on customer name, but only if it's not blank.

709
00:33:44,280 --> 00:33:46,040
That's not AI readiness.

710
00:33:46,040 --> 00:33:47,040
That's coping.

711
00:33:47,040 --> 00:33:50,080
So the new readiness test for Dataverse is brutally simple.

712
00:33:50,080 --> 00:33:54,480
Can your model explain your business to an AI without you standing there to translate?

713
00:33:54,480 --> 00:33:58,960
If the answer is no, then every agent you build will either hallucinate or require escalating

714
00:33:58,960 --> 00:34:00,520
amounts of human supervision.

715
00:34:00,520 --> 00:34:04,280
Human supervision at AI scale is just manual work with extra steps.

716
00:34:04,280 --> 00:34:06,680
This is where relationships stop being nice.

717
00:34:06,680 --> 00:34:11,280
They become retrieval infrastructure, a flat model forces AI to guess which fields belong

718
00:34:11,280 --> 00:34:12,280
together.

719
00:34:12,280 --> 00:34:14,640
A relational model gives AI a navigation graph.

720
00:34:14,640 --> 00:34:19,640
It can move from customer to cases to related approvals to exceptions to the owning team and

721
00:34:19,640 --> 00:34:22,440
retrieve context that matches how the business actually thinks.

722
00:34:22,440 --> 00:34:25,040
That's what people miss when they treat dataverse like storage.

723
00:34:25,040 --> 00:34:26,760
Storage gives you rows.

724
00:34:26,760 --> 00:34:28,440
Relationships give you reasoning pathways.

725
00:34:28,440 --> 00:34:33,560
The moment you add multiple apps, those pathways become the only thing that keeps your ecosystem

726
00:34:33,560 --> 00:34:36,120
from turning into contradictory truths.

727
00:34:36,120 --> 00:34:40,360
Model driven apps, canvas apps, power pages, power automate, co-pilot studio, they all

728
00:34:40,360 --> 00:34:41,960
converge on the same substrate.

729
00:34:41,960 --> 00:34:43,560
So AI is not one more interface.

730
00:34:43,560 --> 00:34:48,400
AI is the first interface that punishes ambiguity instantly in front of everyone.

731
00:34:48,400 --> 00:34:51,080
Now tie this back to Boulin's workshop framing.

732
00:34:51,080 --> 00:34:54,360
Dataverse 101 is quietly AI to her one groundwork.

733
00:34:54,360 --> 00:34:58,160
Not because Dataverse is an AI product, because AI demands the thing Dataverse has

734
00:34:58,160 --> 00:35:03,880
always been trying to force, explicit semantics, even the boring stuff becomes AI critical.

735
00:35:03,880 --> 00:35:07,560
If you didn't name columns consistently, retrieval becomes probabilistic.

736
00:35:07,560 --> 00:35:10,880
If you didn't use descriptions, you lose disambiguation.

737
00:35:10,880 --> 00:35:15,160
If you abuse choice fields to represent entities, you collapse structure into strings.

738
00:35:15,160 --> 00:35:19,120
If you skipped relationship behavior, you created orphaned records that still exist, still

739
00:35:19,120 --> 00:35:21,440
get retrieved and still contaminate answers.

740
00:35:21,440 --> 00:35:24,720
And when AI returns the wrong answer, your users won't blame the data model.

741
00:35:24,720 --> 00:35:25,960
They'll blame the AI.

742
00:35:25,960 --> 00:35:28,520
But the system is behaving exactly as designed.

743
00:35:28,520 --> 00:35:32,560
It's retrieving from an ambiguous substrate and producing plausible output.

744
00:35:32,560 --> 00:35:34,680
That's not a model failure in the AI layer.

745
00:35:34,680 --> 00:35:36,840
That's a modeling failure in the control plane.

746
00:35:36,840 --> 00:35:40,680
This is also where the Dataverse versus SharePoint debate changes shape.

747
00:35:40,680 --> 00:35:41,760
SharePoint can store content.

748
00:35:41,760 --> 00:35:46,120
It can even power decent retrieval in certain Microsoft 365 co-pilot scenarios because

749
00:35:46,120 --> 00:35:48,440
the Microsoft graph does heavy lifting.

750
00:35:48,440 --> 00:35:52,800
But when you build agents that need reliable structured truth ownership, row level security,

751
00:35:52,800 --> 00:35:55,320
relationships that represent business concepts.

752
00:35:55,320 --> 00:35:57,160
Data lists are not a semantics engine.

753
00:35:57,160 --> 00:35:59,600
They're a flat container with references and limits.

754
00:35:59,600 --> 00:36:03,040
So you can absolutely build an agent on top of SharePoint.

755
00:36:03,040 --> 00:36:06,760
You'll just spend the rest of its life explaining what the data really means.

756
00:36:06,760 --> 00:36:10,000
Dataverse shifts that work earlier into the model where it belongs.

757
00:36:10,000 --> 00:36:14,720
The payoff is that once the model is stable, AI retrieval becomes less about prompt gymnastics

758
00:36:14,720 --> 00:36:16,560
and more about asking normal questions.

759
00:36:16,560 --> 00:36:21,920
And that's the future shape of business apps, less UI logic, more semantic substrate with

760
00:36:21,920 --> 00:36:23,560
agents operating on top.

761
00:36:23,560 --> 00:36:26,440
And there's one more escalation that makes this non-negotiable.

762
00:36:26,440 --> 00:36:29,680
Co-pilot chat is mostly about retrieval and summarization.

763
00:36:29,680 --> 00:36:30,680
Agents are different.

764
00:36:30,680 --> 00:36:31,680
Agents create state.

765
00:36:31,680 --> 00:36:32,680
They create decisions.

766
00:36:32,680 --> 00:36:34,360
They create operational records.

767
00:36:34,360 --> 00:36:36,000
They don't just read your model.

768
00:36:36,000 --> 00:36:37,280
They write to it.

769
00:36:37,280 --> 00:36:41,560
And if the model can't hold structured truth over time, your agent doesn't become smart.

770
00:36:41,560 --> 00:36:42,880
It becomes noisy.

771
00:36:42,880 --> 00:36:44,160
That's the next section.

772
00:36:44,160 --> 00:36:45,160
Scenario three.

773
00:36:45,160 --> 00:36:47,200
Agents logging state and long term memory.

774
00:36:47,200 --> 00:36:52,240
Once you move from co-pilot answering questions to agents doing work, the data problem changes

775
00:36:52,240 --> 00:36:53,240
shape.

776
00:36:53,240 --> 00:36:57,720
And chat experience can get away with vague context because the user is still in the loop,

777
00:36:57,720 --> 00:36:59,560
correcting, clarifying and re-asking.

778
00:36:59,560 --> 00:37:01,240
An agent doesn't live in that world.

779
00:37:01,240 --> 00:37:02,760
An agent executes.

780
00:37:02,760 --> 00:37:04,040
It takes actions.

781
00:37:04,040 --> 00:37:05,040
It makes decisions.

782
00:37:05,040 --> 00:37:06,040
It retries.

783
00:37:06,040 --> 00:37:07,040
It escalates.

784
00:37:07,040 --> 00:37:08,040
It hands off.

785
00:37:08,040 --> 00:37:09,040
It keeps going.

786
00:37:09,040 --> 00:37:12,560
That means an agent produces operational data whether you plan for it or not.

787
00:37:12,560 --> 00:37:16,040
And operational data is not the same thing as business data.

788
00:37:16,040 --> 00:37:17,840
Business data is your nouns.

789
00:37:17,840 --> 00:37:18,840
Customer.

790
00:37:18,840 --> 00:37:19,840
Case.

791
00:37:19,840 --> 00:37:20,840
Contract.

792
00:37:20,840 --> 00:37:21,840
Invoice.

793
00:37:21,840 --> 00:37:22,840
Approval.

794
00:37:22,840 --> 00:37:23,840
Act.

795
00:37:23,840 --> 00:37:24,960
What the agent saw.

796
00:37:24,960 --> 00:37:26,200
What it decided.

797
00:37:26,200 --> 00:37:27,200
What it attempted.

798
00:37:27,200 --> 00:37:28,200
What failed.

799
00:37:28,200 --> 00:37:29,200
What it escalated.

800
00:37:29,200 --> 00:37:30,200
What it learned.

801
00:37:30,200 --> 00:37:31,200
What it should remember next time.

802
00:37:31,200 --> 00:37:33,520
If you don't model that explicitly, you still get it.

803
00:37:33,520 --> 00:37:35,200
You just get it in the worst places.

804
00:37:35,200 --> 00:37:36,440
Free text notes.

805
00:37:36,440 --> 00:37:37,640
Message transcripts.

806
00:37:37,640 --> 00:37:38,640
Scattered teams.

807
00:37:38,640 --> 00:37:39,640
Chats.

808
00:37:39,640 --> 00:37:40,640
Random SharePoint lists.

809
00:37:40,640 --> 00:37:44,600
And temporary logs that become permanent because nobody ever decommissions anything.

810
00:37:44,600 --> 00:37:47,920
This is where data verse becomes strategic in a way most teams don't expect.

811
00:37:47,920 --> 00:37:50,320
Data verse is not only where you store the truth.

812
00:37:50,320 --> 00:37:52,280
It becomes where you store the state.

813
00:37:52,280 --> 00:37:55,960
It is the thing agents require to behave consistently across time.

814
00:37:55,960 --> 00:37:57,400
What step is this process on.

815
00:37:57,400 --> 00:37:58,880
What was the last action taken.

816
00:37:58,880 --> 00:37:59,880
Who approved it.

817
00:37:59,880 --> 00:38:00,880
What exception was raised.

818
00:38:00,880 --> 00:38:01,880
What policy was applied.

819
00:38:01,880 --> 00:38:02,880
What input was missing.

820
00:38:02,880 --> 00:38:04,200
What confidence level did we have.

821
00:38:04,200 --> 00:38:06,040
What remediation occurred.

822
00:38:06,040 --> 00:38:09,840
If you don't give an agent structured state, you force it into probabilistic behavior.

823
00:38:09,840 --> 00:38:12,640
It guesses what happened based on what it can retrieve.

824
00:38:12,640 --> 00:38:13,840
That is not intelligence.

825
00:38:13,840 --> 00:38:16,360
That is conditional chaos with better vocabulary.

826
00:38:16,360 --> 00:38:20,080
The simple version is agents need memory and memory needs structure.

827
00:38:20,080 --> 00:38:23,040
In practical terms, the enterprise pattern looks like this.

828
00:38:23,040 --> 00:38:27,920
Agents read from data verse to get context and they write back to data verse to record outcomes.

829
00:38:27,920 --> 00:38:31,720
The model becomes the shared timeline of truth across humans and automation.

830
00:38:31,720 --> 00:38:34,480
You can see the platform pushing in this direction already.

831
00:38:34,480 --> 00:38:38,560
Microsoft's data verse team has been talking publicly about data verse as the data platform

832
00:38:38,560 --> 00:38:43,640
for agents, knowledge retrieval, functions, operational logs, and app experiences where

833
00:38:43,640 --> 00:38:45,840
humans review agent output.

834
00:38:45,840 --> 00:38:47,320
That's not marketing fluff.

835
00:38:47,320 --> 00:38:48,840
That's the inevitable architecture.

836
00:38:48,840 --> 00:38:52,240
This autonomous work without durable state is just repeated mistakes.

837
00:38:52,240 --> 00:38:54,360
Now here's the uncomfortable truth.

838
00:38:54,360 --> 00:38:57,480
Grounding reduces hallucination is a half truth.

839
00:38:57,480 --> 00:39:01,160
Grounding reduces hallucination only to the extent that the ground is stable, structured,

840
00:39:01,160 --> 00:39:02,480
and semantically navigable.

841
00:39:02,480 --> 00:39:06,280
If your model is weak, grounding just makes the agent confidently wrong faster.

842
00:39:06,280 --> 00:39:09,440
That's why agent readiness is not, do we have copilot studio?

843
00:39:09,440 --> 00:39:12,480
It's, can the system hold structured truth over time?

844
00:39:12,480 --> 00:39:15,480
This is where things like functions and reusable logic matter.

845
00:39:15,480 --> 00:39:20,480
A function is basically you extracting a repeatable business decision into a carlable unit.

846
00:39:20,480 --> 00:39:25,320
But a function still needs clean inputs, predictable identifiers, and meaningful relationships,

847
00:39:25,320 --> 00:39:27,320
otherwise you're automating confusion.

848
00:39:27,320 --> 00:39:30,680
And the logging side matters even more than most teams realize.

849
00:39:30,680 --> 00:39:33,000
When an agent fails, you need to know why.

850
00:39:33,000 --> 00:39:35,440
Not emotionally mechanically, what record did it operate on?

851
00:39:35,440 --> 00:39:36,680
What permissions did it have?

852
00:39:36,680 --> 00:39:38,480
What relationship path did it traverse?

853
00:39:38,480 --> 00:39:39,480
What rule blocked it?

854
00:39:39,480 --> 00:39:40,800
What environment was it in?

855
00:39:40,800 --> 00:39:42,440
What version of the solution was deployed?

856
00:39:42,440 --> 00:39:43,560
What data was missing?

857
00:39:43,560 --> 00:39:45,240
What exception pattern is repeating?

858
00:39:45,240 --> 00:39:48,160
If those answers are scattered, you don't have observability.

859
00:39:48,160 --> 00:39:50,920
You have storytelling.

860
00:39:50,920 --> 00:39:54,120
So the agentic future forces a new requirement.

861
00:39:54,120 --> 00:39:58,440
The model must be able to represent process history as data, not as narrative.

862
00:39:58,440 --> 00:40:03,440
That usually means new tables, agent runs, agent decisions, exceptions, approvals, escalations,

863
00:40:03,440 --> 00:40:04,760
human corrections, and outcomes.

864
00:40:04,760 --> 00:40:06,160
It means timestamps and owners.

865
00:40:06,160 --> 00:40:07,640
It means correlation IDs.

866
00:40:07,640 --> 00:40:11,480
It means explicit relationships between an agent's actions and the business record it acted

867
00:40:11,480 --> 00:40:12,480
on.

868
00:40:12,480 --> 00:40:15,640
This can feel like overhead until you operate at scale.

869
00:40:15,640 --> 00:40:18,960
Because the moment you have 10 agents touching the same business process, you'll discover

870
00:40:18,960 --> 00:40:22,720
the same law we've been circling all episodes scale multiplies everything, especially

871
00:40:22,720 --> 00:40:23,720
in consistency.

872
00:40:23,720 --> 00:40:24,920
So what changes for leaders?

873
00:40:24,920 --> 00:40:26,320
The app is no longer the product.

874
00:40:26,320 --> 00:40:28,440
The system of truth is agents will come and go.

875
00:40:28,440 --> 00:40:30,160
UI experiences will evolve.

876
00:40:30,160 --> 00:40:34,440
But the durable competitive advantage will be, can your organization model reality well

877
00:40:34,440 --> 00:40:35,440
enough?

878
00:40:35,440 --> 00:40:37,720
That autonomous work stays aligned with intent?

879
00:40:37,720 --> 00:40:41,760
That's the line between agents that help an agent that create noise.

880
00:40:41,760 --> 00:40:45,600
And once you accept that data versus where both business truth and operational memory live,

881
00:40:45,600 --> 00:40:48,520
the next scenario becomes obvious.

882
00:40:48,520 --> 00:40:51,280
Power platform at scale is not many apps.

883
00:40:51,280 --> 00:40:56,000
It's one model serving many experiences without rewriting itself every quarter.

884
00:40:56,000 --> 00:40:59,880
Scenario four, power platform at scale, one model, many apps.

885
00:40:59,880 --> 00:41:04,800
Power platform at scale is where every comfortable shortcut turns into a recurring incident.

886
00:41:04,800 --> 00:41:09,920
Because the promise stops being we built an app, the promise becomes we built a capability,

887
00:41:09,920 --> 00:41:12,000
capabilities don't live in a canvas screen.

888
00:41:12,000 --> 00:41:14,120
They live in the model at small scale.

889
00:41:14,120 --> 00:41:16,760
Teams can pretend each app is its own universe.

890
00:41:16,760 --> 00:41:21,120
A canvas app over here, a flow over there, a list somewhere, maybe a model driven app later,

891
00:41:21,120 --> 00:41:23,880
people hand wave integration as we'll connect it.

892
00:41:23,880 --> 00:41:25,760
Security as we lock it down.

893
00:41:25,760 --> 00:41:27,640
Reporting as power BI can figure it out.

894
00:41:27,640 --> 00:41:30,640
It feels manageable because the blast radius is small.

895
00:41:30,640 --> 00:41:33,240
Then the organization does what organizations always do.

896
00:41:33,240 --> 00:41:34,440
It repeats the pattern.

897
00:41:34,440 --> 00:41:36,520
A second app needs the same customer concept.

898
00:41:36,520 --> 00:41:38,880
A third app needs the same approval concept.

899
00:41:38,880 --> 00:41:40,800
A fourth app needs the same status concept.

900
00:41:40,800 --> 00:41:42,840
And suddenly you aren't building apps anymore.

901
00:41:42,840 --> 00:41:45,360
You're building a platform whether you admit it or not.

902
00:41:45,360 --> 00:41:47,800
This is where data verse reveals what it really is.

903
00:41:47,800 --> 00:41:50,800
A shared schema that multiple experiences converge on.

904
00:41:50,800 --> 00:41:55,920
Model driven apps canvas apps, power pages, power automate, co-pilot studio, power BI, none

905
00:41:55,920 --> 00:41:57,080
of them are the center.

906
00:41:57,080 --> 00:41:58,080
The model is.

907
00:41:58,080 --> 00:42:01,720
And once you have multiple consumers, the model stops being a background choice and becomes

908
00:42:01,720 --> 00:42:02,800
a scaling interface.

909
00:42:02,800 --> 00:42:06,320
The foundational mistake at scale is building for launch.

910
00:42:06,320 --> 00:42:09,800
Launch driven models optimize for the first UI and the first workflow.

911
00:42:09,800 --> 00:42:14,440
They don't optimize for the fifth app, the tenth flow, the first integration rewrite,

912
00:42:14,440 --> 00:42:17,240
or the first agent that needs context across entities.

913
00:42:17,240 --> 00:42:20,480
So when the next app shows up, the model gets tweaked.

914
00:42:20,480 --> 00:42:22,120
Columns get repurposed.

915
00:42:22,120 --> 00:42:23,680
Relationships get added late.

916
00:42:23,680 --> 00:42:24,960
Naming drifts.

917
00:42:24,960 --> 00:42:26,120
Choices get overloaded.

918
00:42:26,120 --> 00:42:29,080
And because the platform is flexible, it lets you ship.

919
00:42:29,080 --> 00:42:31,400
But the cost shows up as schema churn.

920
00:42:31,400 --> 00:42:34,200
Constant small changes that break things you forgot were dependent.

921
00:42:34,200 --> 00:42:38,240
That's why smart teams treat the data model as the platform, not as an artifact of a single

922
00:42:38,240 --> 00:42:39,240
app.

923
00:42:39,240 --> 00:42:40,240
One model, many apps is the point.

924
00:42:40,240 --> 00:42:44,720
It means you can build a model driven app for internal operations and a power pages portal

925
00:42:44,720 --> 00:42:47,480
for external users, both reading the same truth.

926
00:42:47,480 --> 00:42:52,280
It means you can build a canvas app for mobile scenarios without inventing a parallel schema.

927
00:42:52,280 --> 00:42:56,340
It means power automate flows don't have to translate between different versions of customer

928
00:42:56,340 --> 00:42:57,540
case or contract.

929
00:42:57,540 --> 00:43:01,240
It means reporting is an expression of the model, not a reconciliation project.

930
00:43:01,240 --> 00:43:06,080
And it means you can introduce AI without creating a new abstraction layer to compensate

931
00:43:06,080 --> 00:43:07,840
for a fragmented data story.

932
00:43:07,840 --> 00:43:10,480
That's the leverage, reuse and consistency.

933
00:43:10,480 --> 00:43:13,280
Not as a best practice as a survival mechanism.

934
00:43:13,280 --> 00:43:15,360
Because at scale, the enemy is not missing features.

935
00:43:15,360 --> 00:43:16,680
The enemy is in consistency.

936
00:43:16,680 --> 00:43:18,840
In consistency creates integration rewrites.

937
00:43:18,840 --> 00:43:20,360
It creates security exceptions.

938
00:43:20,360 --> 00:43:21,840
It creates reporting disputes.

939
00:43:21,840 --> 00:43:23,640
It creates AI prompt attacks.

940
00:43:23,640 --> 00:43:25,880
And then teams call it governance overhead.

941
00:43:25,880 --> 00:43:29,520
When the real overhead is relearning the same concept in four different apps.

942
00:43:29,520 --> 00:43:33,000
This is also where standards stop being bureaucracy and start being speed.

943
00:43:33,000 --> 00:43:35,640
A stable naming scheme becomes a multiplier.

944
00:43:35,640 --> 00:43:36,800
Descriptions become a multiplier.

945
00:43:36,800 --> 00:43:39,080
A clear ownership pattern becomes a multiplier.

946
00:43:39,080 --> 00:43:42,120
A relationship first approach becomes a multiplier.

947
00:43:42,120 --> 00:43:44,040
Solutions and environments become a multiplier.

948
00:43:44,040 --> 00:43:49,080
Because the organization can add new apps without forcing a remodel of reality every time.

949
00:43:49,080 --> 00:43:52,400
Blendsline, data verse gives meaning to the data you keep.

950
00:43:52,400 --> 00:43:53,600
Lands differently here.

951
00:43:53,600 --> 00:43:55,560
At scale, meaning is not philosophical.

952
00:43:55,560 --> 00:43:56,560
It's operational.

953
00:43:56,560 --> 00:43:59,440
Meaning is what prevents the fifth app from breaking the first app.

954
00:43:59,440 --> 00:44:03,800
Meaning is what lets the sixth flow reuse the same relationships without inventing new

955
00:44:03,800 --> 00:44:04,800
joins.

956
00:44:04,800 --> 00:44:08,520
Meaning is what makes an agent retrieve the right context without you hand holding it.

957
00:44:08,520 --> 00:44:10,280
And this is where the paradox shows up.

958
00:44:10,280 --> 00:44:13,680
Teams that obsess over delivery speed at the start move slower later.

959
00:44:13,680 --> 00:44:17,160
Teams that invest in modeling intent early move faster forever.

960
00:44:17,160 --> 00:44:20,360
Not because they're more mature, because they reduce their degrees of freedom.

961
00:44:20,360 --> 00:44:23,160
They constrain the system into predictable shapes.

962
00:44:23,160 --> 00:44:25,280
They made the platform boring in the right places.

963
00:44:25,280 --> 00:44:28,680
So when an executive asks why are we spending time on the model?

964
00:44:28,680 --> 00:44:31,880
The correct answer is because this is the only part that can scale.

965
00:44:31,880 --> 00:44:32,880
Screens don't scale.

966
00:44:32,880 --> 00:44:33,880
People don't scale.

967
00:44:33,880 --> 00:44:34,880
Meetings don't scale.

968
00:44:34,880 --> 00:44:35,880
A coherent model scales.

969
00:44:35,880 --> 00:44:39,560
And once you're operating one model across many apps, you start seeing the failure modes

970
00:44:39,560 --> 00:44:40,560
early.

971
00:44:40,560 --> 00:44:41,560
You can spot them.

972
00:44:41,560 --> 00:44:42,560
You can name them.

973
00:44:42,560 --> 00:44:44,400
You can stop them before they become architectural erosion.

974
00:44:44,400 --> 00:44:45,560
That's the next step.

975
00:44:45,560 --> 00:44:49,360
Call out the anti-patterns that leaders must recognize before low-code innovation turns

976
00:44:49,360 --> 00:44:51,600
into high-code cleanup.

977
00:44:51,600 --> 00:44:53,920
Anti-patterns leaders must recognize early.

978
00:44:53,920 --> 00:44:55,920
Every platform has failure modes.

979
00:44:55,920 --> 00:44:58,920
Dataverse just makes them more expensive because it can scale them.

980
00:44:58,920 --> 00:45:03,000
So if leadership wants a real advantage, it isn't more makers or more apps.

981
00:45:03,000 --> 00:45:07,080
It's learning to spot the patterns that quietly turn a semantics engine into a storage

982
00:45:07,080 --> 00:45:09,040
bin with delusions of governance.

983
00:45:09,040 --> 00:45:10,640
These are the anti-patterns.

984
00:45:10,640 --> 00:45:13,920
Name them early, because once they ship, they become political.

985
00:45:13,920 --> 00:45:17,120
First, the one table trap.

986
00:45:17,120 --> 00:45:19,880
We'll start with one table and add columns as we go.

987
00:45:19,880 --> 00:45:22,200
It feels fast because it is fast.

988
00:45:22,200 --> 00:45:26,880
While the table becomes a junk draw for three different nouns, then reporting becomes conditional

989
00:45:26,880 --> 00:45:31,160
logic, security becomes unexplainable and integrations can't tell what a row even is.

990
00:45:31,160 --> 00:45:32,160
That's not an MVP.

991
00:45:32,160 --> 00:45:33,560
That's semantic collapse.

992
00:45:33,560 --> 00:45:36,360
Second, SharePoint as a database.

993
00:45:36,360 --> 00:45:37,920
SharePoint can store lists and files.

994
00:45:37,920 --> 00:45:39,440
It can't enforce reality at scale.

995
00:45:39,440 --> 00:45:44,600
So teams simulate relationships with lookups, repeated values, and compensating flows.

996
00:45:44,600 --> 00:45:48,680
Until thresholds, delegation limits, and audit ambiguity show up, then they don't

997
00:45:48,680 --> 00:45:49,680
migrate.

998
00:45:49,680 --> 00:45:50,680
They optimize the workaround.

999
00:45:50,680 --> 00:45:52,600
Third, Screen-driven modeling.

1000
00:45:52,600 --> 00:45:53,960
The UI becomes the schema.

1001
00:45:53,960 --> 00:45:57,640
You build tables to match the form and the model becomes a screenshot.

1002
00:45:57,640 --> 00:45:59,320
The tell is step-shaped columns.

1003
00:45:59,320 --> 00:46:01,600
Approval two, step three complete.

1004
00:46:01,600 --> 00:46:05,680
Because you embedded a workflow engine inside a table, every process change becomes a schema

1005
00:46:05,680 --> 00:46:06,680
change.

1006
00:46:06,680 --> 00:46:09,240
Fourth, Copy-Paste Environment Syndrome.

1007
00:46:09,240 --> 00:46:14,200
Teams clone broken assumptions across dev, test, prod, and call it ALM.

1008
00:46:14,200 --> 00:46:18,920
Then prod drifts, unmanaged overrides, pile up, and nobody trusts what version means.

1009
00:46:18,920 --> 00:46:21,000
Everything becomes theater.

1010
00:46:21,000 --> 00:46:22,640
You don't refute these with KPIs.

1011
00:46:22,640 --> 00:46:24,640
You refute them with consequences.

1012
00:46:24,640 --> 00:46:29,880
Fewer breaking schema changes after go live, simpler audit answers, less prompt gymnastics

1013
00:46:29,880 --> 00:46:34,000
and new apps, launched without renegotiating what words mean.

1014
00:46:34,000 --> 00:46:36,360
If meaning isn't in the model, it isn't in the system.

1015
00:46:36,360 --> 00:46:38,920
It's in people's heads, and people's heads don't scale.

1016
00:46:38,920 --> 00:46:42,560
And what smart teams do differently, modeling for change?

1017
00:46:42,560 --> 00:46:44,240
Smart teams don't model better.

1018
00:46:44,240 --> 00:46:45,840
They model with a different purpose.

1019
00:46:45,840 --> 00:46:47,400
Most teams model to ship.

1020
00:46:47,400 --> 00:46:49,080
And then the team's model to survive change.

1021
00:46:49,080 --> 00:46:52,280
That distinction matters because dataverse doesn't punish you for launching.

1022
00:46:52,280 --> 00:46:53,760
It punishes you for drifting.

1023
00:46:53,760 --> 00:46:57,720
Over time, your model either stays coherent or it becomes a pile of exceptions that only

1024
00:46:57,720 --> 00:46:59,520
the original builders can interpret.

1025
00:46:59,520 --> 00:47:01,200
So what do smart teams do differently?

1026
00:47:01,200 --> 00:47:02,480
They start with intent, not UI.

1027
00:47:02,480 --> 00:47:05,640
They don't begin with what fields should be on the form.

1028
00:47:05,640 --> 00:47:09,760
They begin with what concepts exist, what do they mean, and what is the smallest set

1029
00:47:09,760 --> 00:47:13,120
of nouns we can standardize without lying to ourselves.

1030
00:47:13,120 --> 00:47:17,240
Then they design relationships to encode those nouns and only then do they build screens

1031
00:47:17,240 --> 00:47:19,960
because screens are consumption, the model is definition.

1032
00:47:19,960 --> 00:47:21,800
Second, they design for additive change.

1033
00:47:21,800 --> 00:47:24,040
Most organizations treat change like a rewrite.

1034
00:47:24,040 --> 00:47:26,840
They refactor schemas because they didn't leave space for evolution.

1035
00:47:26,840 --> 00:47:31,320
Smart teams assume change is constant, so they bias toward patterns that can expand

1036
00:47:31,320 --> 00:47:33,240
without breaking existing meaning.

1037
00:47:33,240 --> 00:47:37,920
That usually means stable identifiers, clear primary names, and columns that don't change

1038
00:47:37,920 --> 00:47:39,560
semantics every quarter.

1039
00:47:39,560 --> 00:47:45,440
If a field starts as department and later becomes cost center, they don't reuse the field.

1040
00:47:45,440 --> 00:47:50,760
They add a new one, deprecate the old, and preserve meaning because reusing fields is

1041
00:47:50,760 --> 00:47:52,640
how you corrupt history.

1042
00:47:52,640 --> 00:47:54,400
Dataverse will store your data forever.

1043
00:47:54,400 --> 00:47:55,680
The model should respect that.

1044
00:47:55,680 --> 00:47:58,600
Third, they treat metadata like a product surface.

1045
00:47:58,600 --> 00:48:00,400
Names are not decoration.

1046
00:48:00,400 --> 00:48:01,440
Descriptions are not optional.

1047
00:48:01,440 --> 00:48:03,320
Choice labels are not good enough.

1048
00:48:03,320 --> 00:48:07,240
If an agent is going to query your model, your metadata is part of the interface contract.

1049
00:48:07,240 --> 00:48:09,400
So smart teams document intent inside the model.

1050
00:48:09,400 --> 00:48:14,160
Table descriptions, column descriptions, meaningful relationship names, and consistent vocabulary.

1051
00:48:14,160 --> 00:48:18,600
They also treat synonyms deliberately where AI will depend on them because customer in one

1052
00:48:18,600 --> 00:48:21,480
team and client in another is not a language problem.

1053
00:48:21,480 --> 00:48:23,040
It's a model problem.

1054
00:48:23,040 --> 00:48:27,600
Fourth, they use constraints as guardrails, not as friction.

1055
00:48:27,600 --> 00:48:31,680
They embrace what dataverse enforces, ownership, security roles, relationship behaviors, and

1056
00:48:31,680 --> 00:48:32,680
environment boundaries.

1057
00:48:32,680 --> 00:48:35,960
They don't try to bypass those because it slows us down.

1058
00:48:35,960 --> 00:48:37,960
They know the bypass becomes permanent.

1059
00:48:37,960 --> 00:48:41,240
So they choose referential versus parental behavior deliberately.

1060
00:48:41,240 --> 00:48:43,960
They restrict deletes where evidence matters.

1061
00:48:43,960 --> 00:48:47,440
They model many to many as an entity when the association has attributes.

1062
00:48:47,440 --> 00:48:50,080
They refuse to hide core concepts inside text.

1063
00:48:50,080 --> 00:48:53,600
This is what enforcing assumptions at scale actually looks like.

1064
00:48:53,600 --> 00:48:56,680
The platform does the enforcement so humans don't have to remember.

1065
00:48:56,680 --> 00:48:59,480
Fifth, they make ILM part of the model strategy.

1066
00:48:59,480 --> 00:49:02,400
They don't treat environments and solutions as release mechanics.

1067
00:49:02,400 --> 00:49:04,360
They treat them as meaning protection.

1068
00:49:04,360 --> 00:49:06,520
Development is where ideas are allowed to be wrong.

1069
00:49:06,520 --> 00:49:08,480
Test is where behavior is validated.

1070
00:49:08,480 --> 00:49:10,520
Production is where meaning becomes contract.

1071
00:49:10,520 --> 00:49:15,480
And solutions are how they transport that contract without letting random changes accumulate in

1072
00:49:15,480 --> 00:49:16,480
the active layer.

1073
00:49:16,480 --> 00:49:20,160
They choose managed deployments once they leave experimentation because the goal is not

1074
00:49:20,160 --> 00:49:21,160
freedom.

1075
00:49:21,160 --> 00:49:22,160
The goal is determinism.

1076
00:49:22,160 --> 00:49:25,480
Six, they build a shared ownership model, not a hero culture.

1077
00:49:25,480 --> 00:49:28,760
They name a model owner, not as a committee, as a role with authority.

1078
00:49:28,760 --> 00:49:30,080
That owner doesn't gatekeep.

1079
00:49:30,080 --> 00:49:31,080
They curate.

1080
00:49:31,080 --> 00:49:32,080
They reduce duplication.

1081
00:49:32,080 --> 00:49:33,400
They kill junk tables.

1082
00:49:33,400 --> 00:49:35,960
They protect core concepts from becoming junk draws.

1083
00:49:35,960 --> 00:49:40,320
They say no to entropy generators and they say yes to changes that preserve meaning.

1084
00:49:40,320 --> 00:49:44,280
This is where leadership actually shows up, not by approving app ideas, by funding the discipline

1085
00:49:44,280 --> 00:49:48,200
that keeps the platform coherent when the org inevitably scales.

1086
00:49:48,200 --> 00:49:51,760
And the final difference is the one most teams don't want to hear.

1087
00:49:51,760 --> 00:49:54,920
Smart teams measure success by how boring the model becomes.

1088
00:49:54,920 --> 00:49:57,640
If the model stops changing every week, that's not stagnation.

1089
00:49:57,640 --> 00:49:58,640
That's stability.

1090
00:49:58,640 --> 00:50:01,360
If new apps can ship without schema churn, that's not luck.

1091
00:50:01,360 --> 00:50:02,360
That's architecture.

1092
00:50:02,360 --> 00:50:05,920
If audits stop being drama and start being routine, that's not because you wrote better

1093
00:50:05,920 --> 00:50:06,920
documents.

1094
00:50:06,920 --> 00:50:09,560
It's because the system behaves predictably under stress.

1095
00:50:09,560 --> 00:50:14,200
But if AI agents can retrieve context without prompt novels, that's not because the agent

1096
00:50:14,200 --> 00:50:15,200
is smarter.

1097
00:50:15,200 --> 00:50:17,600
It's because your model stopped forcing it to guess.

1098
00:50:17,600 --> 00:50:21,120
So if you want the simplest practical move you can make tomorrow, it's this.

1099
00:50:21,120 --> 00:50:24,800
Before you build your next app, write down the nouns, define them.

1100
00:50:24,800 --> 00:50:28,840
Decide ownership, decide relationships, decide what status means, decide which concepts are

1101
00:50:28,840 --> 00:50:31,640
global and which are local, then build screens.

1102
00:50:31,640 --> 00:50:35,560
Because local doesn't reduce thinking, it just accelerates the consequences of not doing

1103
00:50:35,560 --> 00:50:36,560
it.

1104
00:50:36,560 --> 00:50:37,560
Conclusion.

1105
00:50:37,560 --> 00:50:39,880
Build, smarter today or pay later.

1106
00:50:39,880 --> 00:50:42,200
The future isn't built by better apps.

1107
00:50:42,200 --> 00:50:46,520
It's built by better models of reality that can survive audits, scale and AI.

1108
00:50:46,520 --> 00:50:51,760
If you want a grounded reset on the fundamentals, go watch BooLand AltinSoy's Dataverse 101

1109
00:50:51,760 --> 00:50:55,360
session next, then challenge your next app idea.

1110
00:50:55,360 --> 00:51:00,160
Name the business concepts, define the relationships and decide ownership before you design a single

1111
00:51:00,160 --> 00:51:01,160
screen.

1112
00:51:01,160 --> 00:51:05,120
Subscribe for more strategy first breakdowns across Dataverse, Power Platform and

1113
00:51:05,120 --> 00:51:07,680
co-pilot and watch that workshop right after this.