Why Power Platform Is Your Real Automation Layer — Not Custom Code

1
00:00:00,000 --> 00:00:04,240
Every automation request in Dynamics becomes a development request, a new approval path,

2
00:00:04,240 --> 00:00:08,880
a reminder, a team's notification, a document created when a deal changes stage, it lands

3
00:00:08,880 --> 00:00:09,880
in a backlog.

4
00:00:09,880 --> 00:00:12,400
Then someone asks, which developer can pick it up?

5
00:00:12,400 --> 00:00:14,960
That model looks normal, it has existed for years.

6
00:00:14,960 --> 00:00:19,120
But it starts from the wrong question, not what changed in the process, not who needs

7
00:00:19,120 --> 00:00:22,000
to act, not which system needs to know.

8
00:00:22,000 --> 00:00:24,680
It starts with, where do we write the code?

9
00:00:24,680 --> 00:00:27,960
And that's where the automation decision already narrows too early.

10
00:00:27,960 --> 00:00:30,880
More platform should sit between Dynamics and the work around it.

11
00:00:30,880 --> 00:00:34,560
It should handle the signals, decisions, people and connected systems that turn a record

12
00:00:34,560 --> 00:00:36,400
change into a business outcome.

13
00:00:36,400 --> 00:00:39,320
Custom code still has a place, it just shouldn't become the default answer before anyone

14
00:00:39,320 --> 00:00:40,880
understands the process.

15
00:00:40,880 --> 00:00:44,440
If you work with Dynamics and you're trying to make better automation choices, subscribe

16
00:00:44,440 --> 00:00:46,160
to M365FM.

17
00:00:46,160 --> 00:00:49,480
Because the problem usually isn't the tool, it's the model behind the tool.

18
00:00:49,480 --> 00:00:52,480
The old model, Dynamics as an application to customize.

19
00:00:52,480 --> 00:00:54,960
In the old model, Dynamics arrives as a product.

20
00:00:54,960 --> 00:00:59,280
The business starts using it, then the gaps appear, sales wants another rule on an opportunity,

21
00:00:59,280 --> 00:01:02,600
service wants a different case route, finance wants approval before someone can change a

22
00:01:02,600 --> 00:01:07,240
value, operations wants customer data sent somewhere else when a record reaches a certain

23
00:01:07,240 --> 00:01:08,240
status.

24
00:01:08,240 --> 00:01:10,360
Each request can look small on its own.

25
00:01:10,360 --> 00:01:13,960
But teams often treat the application as fixed, every difference in how the business

26
00:01:13,960 --> 00:01:16,360
works needs custom work around the edges.

27
00:01:16,360 --> 00:01:20,520
So the request goes to a developer, a plug-in gets written, a JavaScript file gets attached

28
00:01:20,520 --> 00:01:25,080
to a form, a custom workflow activity appears, an integration service gets built, maybe

29
00:01:25,080 --> 00:01:29,120
a developer adds a web hook or a schedule job or another API endpoint that only one person

30
00:01:29,120 --> 00:01:30,200
really understands.

31
00:01:30,200 --> 00:01:33,640
The work gets delivered, the ticket closes, everyone moves on.

32
00:01:33,640 --> 00:01:35,200
That feels like progress.

33
00:01:35,200 --> 00:01:37,000
But feature completion is a weak measure.

34
00:01:37,000 --> 00:01:40,520
A feature can work perfectly on release day and still create a problem for the next person

35
00:01:40,520 --> 00:01:41,880
who needs to change it.

36
00:01:41,880 --> 00:01:45,760
Because the completed feature doesn't show the full process, it shows one technical response

37
00:01:45,760 --> 00:01:48,440
to one request, at one moment in time.

38
00:01:48,440 --> 00:01:52,920
The business rule now sits inside a plug-in assembly, or inside a script library, or inside

39
00:01:52,920 --> 00:01:56,440
a workflow that calls a custom activity, or split across all of them.

40
00:01:56,440 --> 00:01:58,840
The person asking for the change may know the policy.

41
00:01:58,840 --> 00:02:02,520
The developer may know the code, neither person may see the whole automation.

42
00:02:02,520 --> 00:02:04,280
That gap matters.

43
00:02:04,280 --> 00:02:07,960
A sales leader might say deals above this amount need approval.

44
00:02:07,960 --> 00:02:12,240
Simple enough, but the actual process could depend on the account type, the discount level,

45
00:02:12,240 --> 00:02:16,000
the country, the owner's business unit, and whether legal terms changed after the first

46
00:02:16,000 --> 00:02:17,000
approval.

47
00:02:17,000 --> 00:02:19,920
The conversation begins with code, the team may implement the first version of the rule

48
00:02:19,920 --> 00:02:23,720
before anyone has mapped who owns the policy, who responds, what happens when nobody responds,

49
00:02:23,720 --> 00:02:25,640
or where the decision needs to appear.

50
00:02:25,640 --> 00:02:29,280
The code solves the visible request, the process stays partly invisible.

51
00:02:29,280 --> 00:02:33,240
And most organizations repeat this pattern because custom development looks controlled.

52
00:02:33,240 --> 00:02:36,640
There's a ticket, there's a sprint, there's a release, there's a developer assigned to

53
00:02:36,640 --> 00:02:40,080
the work, but control over delivery isn't the same as control over automation.

54
00:02:40,080 --> 00:02:42,320
A process has a life after deployment.

55
00:02:42,320 --> 00:02:46,240
Policies change, teams reorganize, thresholds move, new regions appear.

56
00:02:46,240 --> 00:02:49,360
Everyone asks for a different escalation route because the old one no longer matches how

57
00:02:49,360 --> 00:02:50,360
work happens.

58
00:02:50,360 --> 00:02:53,600
Now the original feature isn't just a feature, it's part of the operating system of the

59
00:02:53,600 --> 00:02:56,680
business, yet ownership often stays with the build team.

60
00:02:56,680 --> 00:03:01,160
The sales operations team owns the approval policy, the platform team owns dynamics, a developer

61
00:03:01,160 --> 00:03:02,840
owns the code knowledge.

62
00:03:02,840 --> 00:03:04,520
Support owns the incident when it fails.

63
00:03:04,520 --> 00:03:08,120
No one owns the complete behavior from event to decision to action.

64
00:03:08,120 --> 00:03:11,440
That creates a strange setup, the people closest to the process can describe what needs

65
00:03:11,440 --> 00:03:12,440
to change.

66
00:03:12,440 --> 00:03:14,240
But they can't inspect the automation.

67
00:03:14,240 --> 00:03:18,240
The people who can inspect the automation may not know whether the policy still makes sense,

68
00:03:18,240 --> 00:03:21,200
so every small change becomes a translation exercise.

69
00:03:21,200 --> 00:03:24,440
Business explains the outcome, an analyst turns it into requirements.

70
00:03:24,440 --> 00:03:28,800
A developer turns requirements into code, a tester checks what the developer built, then

71
00:03:28,800 --> 00:03:32,320
production receives another technical artifact that someone must remember exists.

72
00:03:32,320 --> 00:03:36,000
This isn't an argument against developers, it's an argument against using developers as

73
00:03:36,000 --> 00:03:39,160
the routing layer for every business process change.

74
00:03:39,160 --> 00:03:42,160
Dynamics has always supported deep extension for good reasons.

75
00:03:42,160 --> 00:03:45,280
Some rules need to run inside the dataverse event pipeline.

76
00:03:45,280 --> 00:03:49,400
Some calculations need precise technical control, some integrations need code because

77
00:03:49,400 --> 00:03:51,280
the surrounding system demands it.

78
00:03:51,280 --> 00:03:55,560
But when every gap triggers the same response, the platform becomes a collection of custom

79
00:03:55,560 --> 00:03:58,960
answers rather than a clear automation system.

80
00:03:58,960 --> 00:04:03,160
You end up with plugins for validation, scripts for user behavior, workflow activities

81
00:04:03,160 --> 00:04:06,440
for background work, integrations for notifications.

82
00:04:06,440 --> 00:04:10,600
Each piece may behave correctly, together they can become difficult to explain, and if you

83
00:04:10,600 --> 00:04:15,280
can't explain why a record triggered work who approved it, what system changed and who

84
00:04:15,280 --> 00:04:19,720
owns the failure you don't have an automation layer, you have accumulated customization.

85
00:04:19,720 --> 00:04:23,000
The next question is what that accumulation produces over time.

86
00:04:23,000 --> 00:04:25,240
The cost nobody put into the business case.

87
00:04:25,240 --> 00:04:30,240
The build cost is easy to see, a project gets funded, a developer estimates the work, someone

88
00:04:30,240 --> 00:04:32,600
approves the budget, then the plugin goes live.

89
00:04:32,600 --> 00:04:36,240
That number ends up in a report, the operating cost goes somewhere else, it lands in support

90
00:04:36,240 --> 00:04:37,240
tickets.

91
00:04:37,240 --> 00:04:40,560
In test cycles, in meetings where people try to work out why an old rule fired.

92
00:04:40,560 --> 00:04:44,540
It lands in the time a senior developer spends reading code they didn't write, because

93
00:04:44,540 --> 00:04:48,280
a sales manager needs one approval threshold changed before next week.

94
00:04:48,280 --> 00:04:51,200
Nobody calls that a custom code project, but it belongs to the same decision.

95
00:04:51,200 --> 00:04:54,920
This is where the business case usually breaks, not because the first build cost was wrong,

96
00:04:54,920 --> 00:04:56,520
because it treated delivery as the cost.

97
00:04:56,520 --> 00:04:58,680
The real cost begins after delivery.

98
00:04:58,680 --> 00:05:01,480
Dynamics changes over time, Microsoft updates the platform.

99
00:05:01,480 --> 00:05:05,280
Your forms change, your tables change, security rolls change, another integration starts

100
00:05:05,280 --> 00:05:06,720
writing to the same record.

101
00:05:06,720 --> 00:05:10,880
A process that looked isolated suddenly sits inside a wider chain of automation.

102
00:05:10,880 --> 00:05:15,200
Now every platform release, solution deployment or schema update creates a question.

103
00:05:15,200 --> 00:05:17,680
Did the custom logic still behave as expected?

104
00:05:17,680 --> 00:05:19,560
That doesn't mean every update breaks code.

105
00:05:19,560 --> 00:05:22,240
It means responsible teams need to test the possibility.

106
00:05:22,240 --> 00:05:24,440
A plugin may rely on a field being present.

107
00:05:24,440 --> 00:05:26,960
A script may assume a form behaves a certain way.

108
00:05:26,960 --> 00:05:31,200
A custom workflow activity may rely on data arriving in a specific order.

109
00:05:31,200 --> 00:05:35,400
The test effort expands because the behavior isn't always visible from the business process.

110
00:05:35,400 --> 00:05:37,120
You need to know the technical path.

111
00:05:37,120 --> 00:05:40,600
And often that knowledge lives with a person, not with the organization.

112
00:05:40,600 --> 00:05:41,800
Consider a simple request.

113
00:05:41,800 --> 00:05:45,600
A commercial director wants to change an approval limit from one amount to another.

114
00:05:45,600 --> 00:05:48,200
The policy changed, nothing technical changed.

115
00:05:48,200 --> 00:05:52,080
But if that limit sits in code, the request turns into development work.

116
00:05:52,080 --> 00:05:55,400
Someone needs to locate the rule, confirm which version runs in production.

117
00:05:55,400 --> 00:05:59,040
Change it safely, test the result, deploy it through the right path, then confirm that

118
00:05:59,040 --> 00:06:02,120
another part of the code doesn't use the same value for a different reason.

119
00:06:02,120 --> 00:06:03,760
The request could take days.

120
00:06:03,760 --> 00:06:08,080
Just because changing a number takes days, because changing a hidden rule safely takes days.

121
00:06:08,080 --> 00:06:09,400
That's developer dependency.

122
00:06:09,400 --> 00:06:11,120
And it doesn't only affect developers.

123
00:06:11,120 --> 00:06:14,840
The business weights, the support team weights, the process owner either works around the old

124
00:06:14,840 --> 00:06:18,560
rule or sends exceptions through email until the change arrives.

125
00:06:18,560 --> 00:06:21,800
Then somebody asks why dynamics feels slow to change.

126
00:06:21,800 --> 00:06:23,800
Dynamics isn't slow, the automation model is.

127
00:06:23,800 --> 00:06:24,920
Documentation should close that gap.

128
00:06:24,920 --> 00:06:26,600
In practice, it often doesn't.

129
00:06:26,600 --> 00:06:29,720
At go live, teams document the original requirements.

130
00:06:29,720 --> 00:06:31,440
They document the solution design.

131
00:06:31,440 --> 00:06:35,280
Maybe they document the assemblies, scripts, endpoints and configuration values.

132
00:06:35,280 --> 00:06:36,280
Then the business changes.

133
00:06:36,280 --> 00:06:38,120
A manager changes the approval route.

134
00:06:38,120 --> 00:06:39,960
A new region needs a different exception.

135
00:06:39,960 --> 00:06:41,240
A policy gets simplified.

136
00:06:41,240 --> 00:06:42,520
The code gets updated.

137
00:06:42,520 --> 00:06:44,360
But the process document stays behind.

138
00:06:44,360 --> 00:06:48,360
Soon, the documentation explains the version of the business that existed six months ago.

139
00:06:48,360 --> 00:06:50,560
The code explains what the system currently does.

140
00:06:50,560 --> 00:06:52,800
Neither one gives a process owner a reliable answer.

141
00:06:52,800 --> 00:06:55,720
So they ask around, does this rule still apply?

142
00:06:55,720 --> 00:06:57,200
Who owns this integration?

143
00:06:57,200 --> 00:06:58,920
Why did the record update?

144
00:06:58,920 --> 00:07:00,200
Can we turn this off?

145
00:07:00,200 --> 00:07:01,680
It's not a technical failure.

146
00:07:01,680 --> 00:07:05,400
It's an ownership failure created by an automation that people can't inspect.

147
00:07:05,400 --> 00:07:06,640
Support teams feel this first.

148
00:07:06,640 --> 00:07:10,640
A user calls because an opportunity changed status unexpectedly.

149
00:07:10,640 --> 00:07:12,120
Or a notification never arrived.

150
00:07:12,120 --> 00:07:14,960
Or an external system received the wrong value.

151
00:07:14,960 --> 00:07:16,120
Support opens the record.

152
00:07:16,120 --> 00:07:17,480
They check the audit history.

153
00:07:17,480 --> 00:07:18,880
They can see something happened.

154
00:07:18,880 --> 00:07:20,720
But they may not see the rule that decided it.

155
00:07:20,720 --> 00:07:24,680
They may not know whether a plug-in ran, whether JavaScript changed a field, whether a custom

156
00:07:24,680 --> 00:07:29,080
workflow activity triggered an integration, or whether another system wrote directly into

157
00:07:29,080 --> 00:07:30,080
data verse.

158
00:07:30,080 --> 00:07:31,080
So the ticket moves.

159
00:07:31,080 --> 00:07:33,080
First line support sends it to the dynamics team.

160
00:07:33,080 --> 00:07:35,120
The dynamics team sends it to the integration team.

161
00:07:35,120 --> 00:07:37,760
The integration team asks the developer to inspect logs.

162
00:07:37,760 --> 00:07:39,520
Meanwhile, the user still needs an answer.

163
00:07:39,520 --> 00:07:41,400
This creates a hidden support model.

164
00:07:41,400 --> 00:07:43,160
The official support process might look clear.

165
00:07:43,160 --> 00:07:47,280
The actual support process depends on finding the person who remembers the automation.

166
00:07:47,280 --> 00:07:48,560
That person becomes a bottleneck.

167
00:07:48,560 --> 00:07:49,560
They may be busy.

168
00:07:49,560 --> 00:07:50,560
They may have moved to another team.

169
00:07:50,560 --> 00:07:51,560
They may have left.

170
00:07:51,560 --> 00:07:53,560
And when they leave, the business doesn't lose just a developer.

171
00:07:53,560 --> 00:07:54,560
It loses the map.

172
00:07:54,560 --> 00:07:58,280
Power Platform doesn't remove the need for design, testing, or support.

173
00:07:58,280 --> 00:07:59,280
That would be a false promise.

174
00:07:59,280 --> 00:08:02,160
A badly designed flow can create confusion too.

175
00:08:02,160 --> 00:08:06,160
But it can place more of the process in a form that process owners, admins, and support

176
00:08:06,160 --> 00:08:07,320
teams can inspect.

177
00:08:07,320 --> 00:08:08,440
They can see the trigger.

178
00:08:08,440 --> 00:08:09,880
They can see the conditions.

179
00:08:09,880 --> 00:08:11,480
They can see the approval branch.

180
00:08:11,480 --> 00:08:13,360
They can see the action that failed.

181
00:08:13,360 --> 00:08:14,960
That changes the operating cost.

182
00:08:14,960 --> 00:08:19,040
Not because nobody needs technical skill, because fewer routine changes begin with a search

183
00:08:19,040 --> 00:08:20,120
through custom code.

184
00:08:20,120 --> 00:08:21,760
So separate two decisions.

185
00:08:21,760 --> 00:08:24,520
The first is whether code can solve the requirement.

186
00:08:24,520 --> 00:08:25,920
Usually it can.

187
00:08:25,920 --> 00:08:29,960
The second is whether code should own that requirement for the next five years.

188
00:08:29,960 --> 00:08:32,160
That decision needs a different standard.

189
00:08:32,160 --> 00:08:33,480
Custom code isn't the enemy.

190
00:08:33,480 --> 00:08:35,240
Custom code still belongs in dynamics.

191
00:08:35,240 --> 00:08:37,400
Some decisions must happen before a record saves.

192
00:08:37,400 --> 00:08:38,760
A user enters a value.

193
00:08:38,760 --> 00:08:40,280
An integration submits an update.

194
00:08:40,280 --> 00:08:42,400
A data import changes a status.

195
00:08:42,400 --> 00:08:46,040
Before a dataverse accepts that change, a rule may need to inspect the data and stop it.

196
00:08:46,040 --> 00:08:47,280
That's a server side boundary.

197
00:08:47,280 --> 00:08:51,520
If a record must never exist in an invalid state, the rule can't wait for an asynchronous

198
00:08:51,520 --> 00:08:52,760
flow to run later.

199
00:08:52,760 --> 00:08:55,440
It needs to run in the dataverse event pipeline.

200
00:08:55,440 --> 00:08:57,560
This is where a plugin can be the right choice.

201
00:08:57,560 --> 00:09:01,640
Take a rule that checks a regulated identifier across related records before a case can move

202
00:09:01,640 --> 00:09:02,640
forward.

203
00:09:02,640 --> 00:09:06,280
Or a rule that prevents a contract from entering an active state when mandatory legal data

204
00:09:06,280 --> 00:09:07,280
is missing.

205
00:09:07,280 --> 00:09:10,080
The record either passes the rule or doesn't save.

206
00:09:10,080 --> 00:09:11,880
That decision needs controlled execution.

207
00:09:11,880 --> 00:09:13,280
Not a notification after the fact.

208
00:09:13,280 --> 00:09:16,520
Not a cleanup process after bad data already entered the system.

209
00:09:16,520 --> 00:09:19,160
And some calculations need the same level of control.

210
00:09:19,160 --> 00:09:24,120
A calculation may depend on several related records, a defined sequence of operations,

211
00:09:24,120 --> 00:09:25,840
and strict handling of failure.

212
00:09:25,840 --> 00:09:29,800
It may need to run once against the right data with a clear result before the next part

213
00:09:29,800 --> 00:09:31,400
of the transaction continues.

214
00:09:31,400 --> 00:09:34,200
You don't build that as a broad flow because flows can build it.

215
00:09:34,200 --> 00:09:38,200
You use the right execution model because the business outcome depends on it.

216
00:09:38,200 --> 00:09:39,840
Volume changes the decision too.

217
00:09:39,840 --> 00:09:42,800
Imagine an integration processing large numbers of records.

218
00:09:42,800 --> 00:09:44,480
Each record creates related work.

219
00:09:44,480 --> 00:09:45,960
Each update triggers checks.

220
00:09:45,960 --> 00:09:47,480
Each check could call other services.

221
00:09:47,480 --> 00:09:51,240
A slow design can create pressure across the whole process.

222
00:09:51,240 --> 00:09:53,680
The answer isn't always right more code.

223
00:09:53,680 --> 00:09:57,480
And high volume performance sensitive operations need deliberate design.

224
00:09:57,480 --> 00:10:01,200
A focused seabass plugin can sometimes perform a narrow piece of work more efficiently

225
00:10:01,200 --> 00:10:04,240
than a long chain of connector calls and repeated record queries.

226
00:10:04,240 --> 00:10:08,600
It gives developers direct control over queries, execution parts, error handling and resource

227
00:10:08,600 --> 00:10:09,600
use.

228
00:10:09,600 --> 00:10:11,200
That is one proper reason to use code.

229
00:10:11,200 --> 00:10:12,440
There's another case.

230
00:10:12,440 --> 00:10:17,080
You may be building something that extends beyond one internal dynamics process, a reusable

231
00:10:17,080 --> 00:10:22,040
component, a custom connector, a PCF control for a specific user experience, a product

232
00:10:22,040 --> 00:10:24,200
capability used across customers.

233
00:10:24,200 --> 00:10:27,360
An external service with its own life cycle and technical contract.

234
00:10:27,360 --> 00:10:28,800
These are software components.

235
00:10:28,800 --> 00:10:33,440
They need software engineering, version control, tests, clear interfaces, people who understand

236
00:10:33,440 --> 00:10:35,120
the technical boundary they own.

237
00:10:35,120 --> 00:10:39,400
Trying to force those into a cloud flow just to avoid code doesn't create a better architecture.

238
00:10:39,400 --> 00:10:40,840
It creates a harder one to operate.

239
00:10:40,840 --> 00:10:42,400
So the argument isn't low code everywhere.

240
00:10:42,400 --> 00:10:43,960
That becomes its own flawed model.

241
00:10:43,960 --> 00:10:45,200
The question is simpler.

242
00:10:45,200 --> 00:10:47,720
Does this requirement need to run inside the transaction?

243
00:10:47,720 --> 00:10:49,520
Does it need strict performance control?

244
00:10:49,520 --> 00:10:52,800
Does it need a technical component that other systems or products consume?

245
00:10:52,800 --> 00:10:56,280
If the answer is yes, code may be the correct layer, but keep it narrow.

246
00:10:56,280 --> 00:10:58,760
A plug-in should do one defined job.

247
00:10:58,760 --> 00:11:00,080
Validate one rule.

248
00:11:00,080 --> 00:11:01,080
Calculate one result.

249
00:11:01,080 --> 00:11:02,320
Apply one control change.

250
00:11:02,320 --> 00:11:06,240
It shouldn't quietly become the place where an entire business process lives.

251
00:11:06,240 --> 00:11:10,200
Once a plug-in starts sending messages, waiting for people creating documents, calling several

252
00:11:10,200 --> 00:11:14,200
external systems and deciding escalations, it has crossed the boundary.

253
00:11:14,200 --> 00:11:15,880
Now it's carrying orchestration work.

254
00:11:15,880 --> 00:11:20,080
When orchestration has different needs, it needs visibility, it needs retries, it needs human

255
00:11:20,080 --> 00:11:24,520
decisions, it needs a clear record of what happened when another system didn't respond.

256
00:11:24,520 --> 00:11:27,200
A focused plug-in also needs proper failure behavior.

257
00:11:27,200 --> 00:11:31,040
If validation fails, return an error that tells the user what to fix, not a vague message

258
00:11:31,040 --> 00:11:32,880
that sends them to support.

259
00:11:32,880 --> 00:11:37,000
If an unexpected technical error occurs, capture enough detail for the team to investigate

260
00:11:37,000 --> 00:11:39,440
without exposing internal information to the user.

261
00:11:39,440 --> 00:11:43,160
Then test it under realistic load, not just one record in a development environment.

262
00:11:43,160 --> 00:11:45,200
Test the record patterns it will see in production.

263
00:11:45,200 --> 00:11:46,760
Test concurrent updates.

264
00:11:46,760 --> 00:11:48,080
Test failure parts.

265
00:11:48,080 --> 00:11:50,520
Test what happens when related data is missing.

266
00:11:50,520 --> 00:11:53,600
Code earns its place through discipline, not through habit.

267
00:11:53,600 --> 00:11:55,560
And that distinction clears up the architecture.

268
00:11:55,560 --> 00:11:58,680
Use code where the dataverse transaction needs code.

269
00:11:58,680 --> 00:12:03,360
Use power platform where the process needs to move across people, systems, time and decisions.

270
00:12:03,360 --> 00:12:07,040
That's the automation layer dynamics teams need to define next.

271
00:12:07,040 --> 00:12:08,040
Reasoning.

272
00:12:08,040 --> 00:12:09,880
The rules between event and action.

273
00:12:09,880 --> 00:12:13,400
An event tells you something changed, but it doesn't say what happens next.

274
00:12:13,400 --> 00:12:15,440
An opportunity reaches a new stage.

275
00:12:15,440 --> 00:12:16,760
A case gets a priority.

276
00:12:16,760 --> 00:12:18,520
A customer record changes owner.

277
00:12:18,520 --> 00:12:19,960
That change needs a reason.

278
00:12:19,960 --> 00:12:22,240
The system decides whether work should start now.

279
00:12:22,240 --> 00:12:24,320
The record either meets the policy or it doesn't.

280
00:12:24,320 --> 00:12:26,400
The process knows who needs to decide.

281
00:12:26,400 --> 00:12:27,760
And the exception path is clear.

282
00:12:27,760 --> 00:12:30,160
This is the layer between the event and the action.

283
00:12:30,160 --> 00:12:31,600
And it has to stay visible.

284
00:12:31,600 --> 00:12:35,440
In most dynamics environments, rules grow one request at a time.

285
00:12:35,440 --> 00:12:39,080
If the discount exceeds this amount, ask for approval.

286
00:12:39,080 --> 00:12:42,960
Unless the customer belongs to this segment, unless the seller has this role, unless

287
00:12:42,960 --> 00:12:45,320
legal already approved the latest terms.

288
00:12:45,320 --> 00:12:47,040
Each condition makes sense on its own.

289
00:12:47,040 --> 00:12:48,920
Together, they become the actual policy.

290
00:12:48,920 --> 00:12:51,880
The problem starts when the policy only lives in technical logic.

291
00:12:51,880 --> 00:12:55,360
A process owner can explain the intended rule, but they can't check whether the system follows

292
00:12:55,360 --> 00:12:59,640
it without asking someone to inspect an assembly script or a hidden configuration chain.

293
00:12:59,640 --> 00:13:01,400
That slows down every conversation.

294
00:13:01,400 --> 00:13:04,600
The process owner asks, why did this deal root to that person?

295
00:13:04,600 --> 00:13:06,400
The answer shouldn't require a code review.

296
00:13:06,400 --> 00:13:09,920
A well-built automation shows the decision path, it shows the threshold.

297
00:13:09,920 --> 00:13:12,320
The owner checked the approval condition, the exception.

298
00:13:12,320 --> 00:13:15,080
Not because every process owner needs to become a maker.

299
00:13:15,080 --> 00:13:17,760
Because they need to validate the policy they own.

300
00:13:17,760 --> 00:13:21,120
Power automate gives teams a visual place for that reasoning.

301
00:13:21,120 --> 00:13:23,080
Conditions branch the process based on record data.

302
00:13:23,080 --> 00:13:25,560
A switch can send different cases through different routes.

303
00:13:25,560 --> 00:13:28,440
Approvals can pause work until the right person responds.

304
00:13:28,440 --> 00:13:32,760
Exception paths can root work to a queue, create a review task, or notify the right team

305
00:13:32,760 --> 00:13:34,800
when the normal route no longer applies.

306
00:13:34,800 --> 00:13:37,440
That's not just easier to build, it's easier to challenge.

307
00:13:37,440 --> 00:13:39,120
And business rules should be challenged.

308
00:13:39,120 --> 00:13:43,000
A rule nobody questions for three years often stops matching the business long before someone

309
00:13:43,000 --> 00:13:45,120
notices, take commercial approvals.

310
00:13:45,120 --> 00:13:49,200
The decision might depend on the opportunity value, but value alone rarely tells the full

311
00:13:49,200 --> 00:13:50,200
story.

312
00:13:50,200 --> 00:13:54,600
The process may also check the account category, deal stage, region, discount percentage, payment

313
00:13:54,600 --> 00:13:58,440
terms, seller ownership, and whether the customer has an unresolved risk issue.

314
00:13:58,440 --> 00:14:00,880
Those conditions don't need to become one giant piece of logic.

315
00:14:00,880 --> 00:14:02,200
They need a clear sequence.

316
00:14:02,200 --> 00:14:04,960
First, confirm the opportunity reach the right stage.

317
00:14:04,960 --> 00:14:07,560
Then check whether the record includes the required data.

318
00:14:07,560 --> 00:14:11,480
After that determine the policy route based on value, risk, and ownership.

319
00:14:11,480 --> 00:14:14,640
If an exception applies, send it to a defined review path.

320
00:14:14,640 --> 00:14:16,720
Otherwise let the standard route continue.

321
00:14:16,720 --> 00:14:19,600
That sequence gives people a way to understand the decision.

322
00:14:19,600 --> 00:14:21,240
It also gives them a way to change it.

323
00:14:21,240 --> 00:14:24,560
A policy owner can see that a regional threshold needs updating.

324
00:14:24,560 --> 00:14:26,800
They can review the impact with the platform team.

325
00:14:26,800 --> 00:14:31,040
The maker can update the rule inside a managed process, test it, and release it through

326
00:14:31,040 --> 00:14:32,400
the proper path.

327
00:14:32,400 --> 00:14:36,840
The change stays connected to the process, rather than disappearing into a technical request.

328
00:14:36,840 --> 00:14:39,360
Now FX extends this model for focused decisions.

329
00:14:39,360 --> 00:14:43,280
It gives makers a formula language for logic that needs more than a simple condition.

330
00:14:43,280 --> 00:14:47,680
You can calculate a value, check data across related records, set a result based on defined

331
00:14:47,680 --> 00:14:51,680
rules, build a clear expression around a business decision, but keep the scope tight.

332
00:14:51,680 --> 00:14:53,280
A formula should express a decision.

333
00:14:53,280 --> 00:14:57,200
It shouldn't turn into a hidden process engine inside one unreadable expression.

334
00:14:57,200 --> 00:14:59,520
If the logic becomes difficult to read, split it.

335
00:14:59,520 --> 00:15:01,800
Name the decision, store the outcome.

336
00:15:01,800 --> 00:15:02,960
Make the next step clear.

337
00:15:02,960 --> 00:15:07,840
The same principle applies whether you use PowerFX, Flow Conditions, Dataverse, Rules, or Code.

338
00:15:07,840 --> 00:15:10,720
People need to see what the automation decided and why.

339
00:15:10,720 --> 00:15:12,880
Risk often creates the most useful structure for this.

340
00:15:12,880 --> 00:15:15,480
A low-risk request can continue without interruption.

341
00:15:15,480 --> 00:15:18,280
A medium-risk request may need a manager's review.

342
00:15:18,280 --> 00:15:22,280
A high-risk request may require several checks, a documented decision, and a different approval

343
00:15:22,280 --> 00:15:23,280
path.

344
00:15:23,280 --> 00:15:24,840
That isn't an arbitrary technical design.

345
00:15:24,840 --> 00:15:27,200
It's the business policy expressed as automation.

346
00:15:27,200 --> 00:15:28,360
Ownership works the same way.

347
00:15:28,360 --> 00:15:30,280
A record owner may handle a normal case.

348
00:15:30,280 --> 00:15:34,280
A team owner may handle a shared workload, a specific business unit may need authority

349
00:15:34,280 --> 00:15:36,360
over certain customers or regions.

350
00:15:36,360 --> 00:15:40,960
The automation can use that context to root work without treating every record as identical,

351
00:15:40,960 --> 00:15:42,600
context decides the root.

352
00:15:42,600 --> 00:15:44,520
Not the screen someone happened to use.

353
00:15:44,520 --> 00:15:46,120
There is still a boundary to protect.

354
00:15:46,120 --> 00:15:48,400
Some rules enforce data integrity at the point of save.

355
00:15:48,400 --> 00:15:51,160
They belong close to the Dataverse transaction.

356
00:15:51,160 --> 00:15:54,800
Other rules decide what happens after the record already meets that standard.

357
00:15:54,800 --> 00:15:56,560
They belong in the automation layer.

358
00:15:56,560 --> 00:15:57,720
Don't mix those jobs.

359
00:15:57,720 --> 00:16:00,560
A required legal value may need to block a record from saving.

360
00:16:00,560 --> 00:16:03,560
A request for legal review can happen after the record saves.

361
00:16:03,560 --> 00:16:04,840
One protects the data.

362
00:16:04,840 --> 00:16:06,960
The other coordinates work around the data.

363
00:16:06,960 --> 00:16:09,760
Keeping that split clear prevents a common design mistake.

364
00:16:09,760 --> 00:16:14,040
Teams try to force every decision into the synchronous path because it feels immediate.

365
00:16:14,040 --> 00:16:17,680
Then the user waits while the system performs work that doesn't need to block them, or

366
00:16:17,680 --> 00:16:22,000
they push strict validation into downstream automation, then discover bad data can enter

367
00:16:22,000 --> 00:16:24,400
the system before anyone reacts.

368
00:16:24,400 --> 00:16:27,880
The system needs the right boundary, enforce what must be true now, then orchestrate what

369
00:16:27,880 --> 00:16:28,880
needs to happen next.

370
00:16:28,880 --> 00:16:31,760
Once the rules produce a decision, the system has worked to do.

371
00:16:31,760 --> 00:16:35,480
That reasoning is still underway, and we're not that far along.

372
00:16:35,480 --> 00:16:38,280
Example, the sales approval that doesn't need a plug-in.

373
00:16:38,280 --> 00:16:39,520
Take a sales approval.

374
00:16:39,520 --> 00:16:41,880
An opportunity reaches a commercial threshold.

375
00:16:41,880 --> 00:16:43,600
Maybe the total value passes a limit.

376
00:16:43,600 --> 00:16:45,200
Maybe the discount becomes too high.

377
00:16:45,200 --> 00:16:46,400
Maybe the payment terms change.

378
00:16:46,400 --> 00:16:47,960
The seller updates the opportunity.

379
00:16:47,960 --> 00:16:49,120
That update is the event.

380
00:16:49,120 --> 00:16:52,040
It doesn't need to become a plug-in just because it triggers work.

381
00:16:52,040 --> 00:16:53,240
Start with the business condition.

382
00:16:53,240 --> 00:16:55,600
The opportunity needs to reach the correct stage.

383
00:16:55,600 --> 00:16:57,640
The seller needs to complete the required fields.

384
00:16:57,640 --> 00:16:59,160
The account needs a defined category.

385
00:16:59,160 --> 00:17:01,720
The commercial values need to match an approval policy.

386
00:17:01,720 --> 00:17:03,360
A flow can check all of that.

387
00:17:03,360 --> 00:17:05,240
Not after somebody emails a manager.

388
00:17:05,240 --> 00:17:07,760
Not after the seller chases an answer through Teams.

389
00:17:07,760 --> 00:17:10,600
The process starts from the record context already in Dynamics.

390
00:17:10,600 --> 00:17:12,800
First, the flow checks the opportunity stage.

391
00:17:12,800 --> 00:17:16,240
A quote still being drafted shouldn't enter a final approval route.

392
00:17:16,240 --> 00:17:18,400
Next, it checks the fields the approval needs.

393
00:17:18,400 --> 00:17:22,200
Discount percentage contract length payment terms, expected revenue.

394
00:17:22,200 --> 00:17:26,560
Any missing information sends the opportunity back to the seller with a clear request.

395
00:17:26,560 --> 00:17:30,120
That stops an approver from receiving a vague task with no basis for a decision.

396
00:17:30,120 --> 00:17:32,040
Then the flow applies the approval policy.

397
00:17:32,040 --> 00:17:35,040
A standard commercial change may root to the sales manager.

398
00:17:35,040 --> 00:17:37,640
A larger discount may need commercial leadership.

399
00:17:37,640 --> 00:17:40,840
A deal with unusual terms may need finance or legal included.

400
00:17:40,840 --> 00:17:44,680
The policy can use the current owner, the account region, the opportunity value, and the

401
00:17:44,680 --> 00:17:45,880
agreed threshold.

402
00:17:45,880 --> 00:17:47,080
This is not a technical trick.

403
00:17:47,080 --> 00:17:48,920
It's the approval model made visible.

404
00:17:48,920 --> 00:17:51,120
The approver receives the request where they work.

405
00:17:51,120 --> 00:17:53,760
For many Dynamics teams, that means Teams.

406
00:17:53,760 --> 00:17:57,840
The request can include the customer name, the opportunity amount, the discount, the terms

407
00:17:57,840 --> 00:18:02,080
that trigger review, a link back to the opportunity they can approve or reject without hunting

408
00:18:02,080 --> 00:18:03,480
through a list of records.

409
00:18:03,480 --> 00:18:05,680
Email can work too.

410
00:18:05,680 --> 00:18:06,960
The point isn't the channel.

411
00:18:06,960 --> 00:18:12,000
The point is that the request reaches the person responsible with enough context to decide.

412
00:18:12,000 --> 00:18:15,280
If the approver rejects it, the flow writes the outcome back to Dynamics.

413
00:18:15,280 --> 00:18:16,520
It records the decision.

414
00:18:16,520 --> 00:18:17,920
It records the response time.

415
00:18:17,920 --> 00:18:21,520
It can store the comment, the opportunity moves to the appropriate status.

416
00:18:21,520 --> 00:18:23,360
The seller receives a message with the result.

417
00:18:23,360 --> 00:18:24,520
No manual update.

418
00:18:24,520 --> 00:18:26,840
No separate spreadsheet tracking approvals.

419
00:18:26,840 --> 00:18:30,560
No uncertainty about whether the decision made it back into the system of record.

420
00:18:30,560 --> 00:18:33,600
If the approver accepts, the same thing happens.

421
00:18:33,600 --> 00:18:35,320
Dynamics receives the outcome.

422
00:18:35,320 --> 00:18:37,280
The seller knows the deal can move forward.

423
00:18:37,280 --> 00:18:38,880
The record shows what happened.

424
00:18:38,880 --> 00:18:40,840
And the approval doesn't disappear into an inbox.

425
00:18:40,840 --> 00:18:44,520
That matters when someone asks later why the deal used a certain discount or why it moved

426
00:18:44,520 --> 00:18:46,000
forward under different terms.

427
00:18:46,000 --> 00:18:49,040
The decision stays connected to the opportunity.

428
00:18:49,040 --> 00:18:51,160
Now consider the part most teams forget.

429
00:18:51,160 --> 00:18:52,800
No response.

430
00:18:52,800 --> 00:18:54,240
A manager gets busy.

431
00:18:54,240 --> 00:18:55,240
They travel.

432
00:18:55,240 --> 00:18:56,640
They miss the team's notification.

433
00:18:56,640 --> 00:18:58,760
The approval sits there.

434
00:18:58,760 --> 00:19:00,440
The seller waits.

435
00:19:00,440 --> 00:19:02,760
Without automation, somebody starts chasing.

436
00:19:02,760 --> 00:19:05,480
First in teams then by email, then through a manager's manager.

437
00:19:05,480 --> 00:19:06,800
That work doesn't improve the deal.

438
00:19:06,800 --> 00:19:09,640
It only compensates for a process with no follow-up path.

439
00:19:09,640 --> 00:19:11,560
A flow can wait for a defined period.

440
00:19:11,560 --> 00:19:13,840
If no response arrives, it sends a reminder.

441
00:19:13,840 --> 00:19:17,960
If the delay continues, it escalates to another owner, a shared approval group, or a defined

442
00:19:17,960 --> 00:19:19,080
backup approver.

443
00:19:19,080 --> 00:19:20,560
The route follows a policy.

444
00:19:20,560 --> 00:19:22,440
Not whoever the seller happens to know.

445
00:19:22,440 --> 00:19:26,040
That change alone removes a lot of informal work from sales operations.

446
00:19:26,040 --> 00:19:29,000
The seller doesn't need to remember every escalation wrote.

447
00:19:29,000 --> 00:19:32,000
The approver doesn't need to rely on a message getting buried.

448
00:19:32,000 --> 00:19:34,560
And the process owner can see where approval is stalled.

449
00:19:34,560 --> 00:19:36,120
Maybe the threshold is too low.

450
00:19:36,120 --> 00:19:38,320
Maybe one person receives too many requests.

451
00:19:38,320 --> 00:19:40,360
Maybe the approval model needs a different route.

452
00:19:40,360 --> 00:19:41,720
Those are business decisions.

453
00:19:41,720 --> 00:19:43,880
The flow gives the team evidence to make them.

454
00:19:43,880 --> 00:19:46,240
A plug-in could trigger part of this process.

455
00:19:46,240 --> 00:19:47,760
Code can call services.

456
00:19:47,760 --> 00:19:49,720
Code can create records.

457
00:19:49,720 --> 00:19:52,480
But that doesn't mean code should own the approval journey.

458
00:19:52,480 --> 00:19:55,520
This work crosses time, people, channels, and record updates.

459
00:19:55,520 --> 00:19:56,520
It needs a visible route.

460
00:19:56,520 --> 00:19:57,680
It needs a clear outcome.

461
00:19:57,680 --> 00:19:59,280
It needs a way to handle silence.

462
00:19:59,280 --> 00:20:00,960
The event pipeline has a different job.

463
00:20:00,960 --> 00:20:05,360
It should protect the record when the record must not save without a rule being met.

464
00:20:05,360 --> 00:20:06,680
Speed means time to change.

465
00:20:06,680 --> 00:20:08,120
Not only milliseconds.

466
00:20:08,120 --> 00:20:10,720
People talk about speed like it only means execution time.

467
00:20:10,720 --> 00:20:14,920
They ask how fast the plug-in ran, how many milliseconds it added to the save, how quickly

468
00:20:14,920 --> 00:20:16,280
the record updated.

469
00:20:16,280 --> 00:20:19,880
Those questions matter, especially when logic runs during a record operation.

470
00:20:19,880 --> 00:20:21,400
A slow plug-in holds up the user.

471
00:20:21,400 --> 00:20:22,480
It increases load.

472
00:20:22,480 --> 00:20:25,560
It creates a poor experience across a busy dynamics environment.

473
00:20:25,560 --> 00:20:27,680
So yes, execution speed matters.

474
00:20:27,680 --> 00:20:28,920
But that's only one kind of speed.

475
00:20:28,920 --> 00:20:30,880
A business process also has a change speed.

476
00:20:30,880 --> 00:20:32,760
A sales policy changes on Monday.

477
00:20:32,760 --> 00:20:34,760
The team needs the new rule working by Wednesday.

478
00:20:34,760 --> 00:20:37,240
A new manager takes responsibility for a region.

479
00:20:37,240 --> 00:20:40,200
An approval route needs to change before the next large deal arrives.

480
00:20:40,200 --> 00:20:43,400
A compliance team changes the conditions that require review.

481
00:20:43,400 --> 00:20:45,600
How long until the automation reflects that change?

482
00:20:45,600 --> 00:20:46,920
That's the speed the business feels.

483
00:20:46,920 --> 00:20:49,040
And it often has nothing to do with milliseconds.

484
00:20:49,040 --> 00:20:51,800
A plug-in executes quickly during every record update.

485
00:20:51,800 --> 00:20:55,840
But changing one routing rule requires a development request, backlog review, technical

486
00:20:55,840 --> 00:20:59,880
analysis, code changes, testing, release approval, deployment.

487
00:20:59,880 --> 00:21:01,800
The business process still moves slowly.

488
00:21:01,800 --> 00:21:03,000
The record saves quickly.

489
00:21:03,000 --> 00:21:04,680
The organization changes slowly.

490
00:21:04,680 --> 00:21:06,160
Those are different measurements.

491
00:21:06,160 --> 00:21:08,840
This is where visual automation changes the conversation.

492
00:21:08,840 --> 00:21:12,400
A flow gives people a readable representation of the process.

493
00:21:12,400 --> 00:21:13,760
The trigger appears at the top.

494
00:21:13,760 --> 00:21:14,960
The check sit below it.

495
00:21:14,960 --> 00:21:16,680
The decision branches show the routes.

496
00:21:16,680 --> 00:21:18,960
The approval step shows who receives the request.

497
00:21:18,960 --> 00:21:21,680
The follow-up action shows what happens after the decision.

498
00:21:21,680 --> 00:21:25,400
A process owner doesn't need to read CEG to understand the broad behavior.

499
00:21:25,400 --> 00:21:28,720
They can look at the flow with the platform team and ask useful questions.

500
00:21:28,720 --> 00:21:30,200
Why does this route apply here?

501
00:21:30,200 --> 00:21:31,720
Who owns that approval group?

502
00:21:31,720 --> 00:21:33,480
What happens if nobody responds?

503
00:21:33,480 --> 00:21:35,160
Should this threshold still exist?

504
00:21:35,160 --> 00:21:37,400
Those questions become part of the review.

505
00:21:37,400 --> 00:21:41,080
What are separate requirements exercised after the technical design already happened?

506
00:21:41,080 --> 00:21:43,640
That shortens the distance between policy and automation.

507
00:21:43,640 --> 00:21:45,040
It also changes handover.

508
00:21:45,040 --> 00:21:48,560
With custom code, handover depends on documents being current and developers explaining the

509
00:21:48,560 --> 00:21:52,200
intent behind classes, methods, configuration and deployment choices.

510
00:21:52,200 --> 00:21:56,120
That work has a place, but it becomes fragile when the automation contains ordinary business

511
00:21:56,120 --> 00:21:57,920
rules that could have remained visible.

512
00:21:57,920 --> 00:22:00,880
A visual flow doesn't remove the need for documentation.

513
00:22:00,880 --> 00:22:02,840
It gives documentation somewhere to point.

514
00:22:02,840 --> 00:22:04,800
The process owner can see the route.

515
00:22:04,800 --> 00:22:06,320
Support can see the failed action.

516
00:22:06,320 --> 00:22:10,160
A new maker can see the connection between the trigger and the outcome.

517
00:22:10,160 --> 00:22:13,600
The automation becomes easier to review without first reconstructing it.

518
00:22:13,600 --> 00:22:16,000
That reduces the time spent translating.

519
00:22:16,000 --> 00:22:18,720
And translation slows teams down more than most people admit.

520
00:22:18,720 --> 00:22:20,560
A policy owner describes the change.

521
00:22:20,560 --> 00:22:21,840
An analyst interprets it.

522
00:22:21,840 --> 00:22:24,520
A developer converts it into a technical change.

523
00:22:24,520 --> 00:22:27,800
Then the policy owner waits to see whether the result matches what they meant.

524
00:22:27,800 --> 00:22:31,200
With a readable automation layer, more of that discussion can happen around the actual

525
00:22:31,200 --> 00:22:32,200
process design.

526
00:22:32,200 --> 00:22:35,200
The policy owner still shouldn't edit production on a Friday afternoon.

527
00:22:35,200 --> 00:22:38,960
He needs that kind of freedom, but they can validate the route before it reaches production.

528
00:22:38,960 --> 00:22:41,240
They can see whether the logic matches the policy.

529
00:22:41,240 --> 00:22:44,960
They can catch the wrong approver, the missing exception or the outdated threshold, while

530
00:22:44,960 --> 00:22:47,160
the change still costs little to fix.

531
00:22:47,160 --> 00:22:48,160
That is business speed.

532
00:22:48,160 --> 00:22:52,120
It means the organization can correct automation while the context still exists.

533
00:22:52,120 --> 00:22:55,000
A routing change doesn't need to become a technical investigation.

534
00:22:55,000 --> 00:22:57,680
A threshold change doesn't need to become a code search.

535
00:22:57,680 --> 00:23:01,520
A process correction doesn't need to wait until the person who originally built it becomes

536
00:23:01,520 --> 00:23:02,520
available.

537
00:23:02,520 --> 00:23:06,000
This doesn't mean every visual flow is automatically easy to understand.

538
00:23:06,000 --> 00:23:11,200
A badly built flow hides logic behind vague action names, nested conditions, unexplained variables.

539
00:23:11,200 --> 00:23:13,240
It becomes just as hard to operate as code.

540
00:23:13,240 --> 00:23:14,520
The tool doesn't create clarity.

541
00:23:14,520 --> 00:23:15,520
The design does.

542
00:23:15,520 --> 00:23:17,800
So build flows for reading, not only for running.

543
00:23:17,800 --> 00:23:18,880
Name the trigger clearly.

544
00:23:18,880 --> 00:23:20,360
Name the decisions clearly.

545
00:23:20,360 --> 00:23:22,080
Use conditions that describe the rule.

546
00:23:22,080 --> 00:23:23,600
Keep related steps together.

547
00:23:23,600 --> 00:23:24,960
Make exception parts obvious.

548
00:23:24,960 --> 00:23:28,240
When somebody opens the automation six months later, they should understand the process

549
00:23:28,240 --> 00:23:29,920
before they understand the mechanics.

550
00:23:29,920 --> 00:23:32,840
It's standard changes what fast means.

551
00:23:32,840 --> 00:23:35,240
Fast is not only a record saving sooner.

552
00:23:35,240 --> 00:23:37,240
Fast is a policy owner seeing the rule.

553
00:23:37,240 --> 00:23:39,280
Fast is a reviewer understanding the root.

554
00:23:39,280 --> 00:23:42,840
Fast is a team fixing the process before manual work becomes normal again.

555
00:23:42,840 --> 00:23:45,680
But none of this holds if the automation belongs to nobody.

556
00:23:45,680 --> 00:23:51,000
A visible flow with no accountable owner still becomes slow the moment something changes.

557
00:23:51,000 --> 00:23:53,840
Ownership, personal flows, create personal automation.

558
00:23:53,840 --> 00:23:55,120
A flow can look shared.

559
00:23:55,120 --> 00:23:57,080
It can support a whole sales team.

560
00:23:57,080 --> 00:23:58,440
It can update hundreds of records.

561
00:23:58,440 --> 00:24:02,480
It can send approval requests across regions, but it may still belong to one employee.

562
00:24:02,480 --> 00:24:04,120
That's a problem hiding in plain sight.

563
00:24:04,120 --> 00:24:06,120
Many flows begin with good intent.

564
00:24:06,120 --> 00:24:07,560
Someone sees repetitive work.

565
00:24:07,560 --> 00:24:09,240
They build a flow under their own account.

566
00:24:09,240 --> 00:24:10,240
It runs correctly.

567
00:24:10,240 --> 00:24:11,240
The team benefits.

568
00:24:11,240 --> 00:24:13,560
Nobody asks who owns it because the maker still works there.

569
00:24:13,560 --> 00:24:15,680
Then the flow becomes part of daily operations.

570
00:24:15,680 --> 00:24:18,160
A scheduled flow sends a report every Monday.

571
00:24:18,160 --> 00:24:21,120
An automated flow reacts when a dynamics record changes.

572
00:24:21,120 --> 00:24:23,320
An approval flow roots commercial decisions.

573
00:24:23,320 --> 00:24:26,640
The work becomes normal, but the identity behind it remains personal.

574
00:24:26,640 --> 00:24:30,760
A scheduled and automated flows that identity can affect how the flow runs.

575
00:24:30,760 --> 00:24:33,400
The flow runs under its assigned owner's plan.

576
00:24:33,400 --> 00:24:36,480
Its access, connections and licensing arrangement depend on that setup.

577
00:24:36,480 --> 00:24:39,240
So the process hasn't really become organizational automation.

578
00:24:39,240 --> 00:24:41,040
It's still attached to an individual employee.

579
00:24:41,040 --> 00:24:42,600
That employee may change roles.

580
00:24:42,600 --> 00:24:44,320
They may lose access to a system.

581
00:24:44,320 --> 00:24:47,200
Their account may be disabled during an exit process.

582
00:24:47,200 --> 00:24:50,440
Nobody intends to break the automation, but the automation can break anyway.

583
00:24:50,440 --> 00:24:52,120
The business sees the effect later.

584
00:24:52,120 --> 00:24:53,120
The report stops arriving.

585
00:24:53,120 --> 00:24:54,600
A reminder doesn't send.

586
00:24:54,600 --> 00:24:55,920
Approval stop moving.

587
00:24:55,920 --> 00:24:58,960
A database update no longer triggers the work people expected.

588
00:24:58,960 --> 00:25:00,920
Then support starts investigating.

589
00:25:00,920 --> 00:25:03,800
Not because the process changed, because its owner left the company.

590
00:25:03,800 --> 00:25:07,520
This is often automation and it creates a strange kind of operational risk.

591
00:25:07,520 --> 00:25:09,880
The automation exists, the business relies on it.

592
00:25:09,880 --> 00:25:12,160
But nobody has clear authority to maintain it.

593
00:25:12,160 --> 00:25:13,880
Nobody can safely change its connection.

594
00:25:13,880 --> 00:25:15,640
Nobody knows whether it should still run.

595
00:25:15,640 --> 00:25:17,880
Sometimes the flow keeps working for a while.

596
00:25:17,880 --> 00:25:18,880
That can be worse.

597
00:25:18,880 --> 00:25:20,480
The team assumes everything is fine.

598
00:25:20,480 --> 00:25:23,560
Meanwhile, the owner no longer has an active role in the process and the flow still

599
00:25:23,560 --> 00:25:25,720
uses access that nobody has reviewed.

600
00:25:25,720 --> 00:25:27,240
The ownership isn't a name on an asset.

601
00:25:27,240 --> 00:25:29,120
It is an operating responsibility.

602
00:25:29,120 --> 00:25:30,840
Someone needs to own the business outcome.

603
00:25:30,840 --> 00:25:32,840
Someone needs to own the technical operation.

604
00:25:32,840 --> 00:25:35,000
For smaller processes, those may be the same person.

605
00:25:35,000 --> 00:25:37,280
For production automation, they often shouldn't be.

606
00:25:37,280 --> 00:25:41,720
A process owner answers questions like, does this approval route still match the policy?

607
00:25:41,720 --> 00:25:43,240
Who should receive the escalation?

608
00:25:43,240 --> 00:25:44,800
What happens when the process fails?

609
00:25:44,800 --> 00:25:47,040
A platform owner answers different questions.

610
00:25:47,040 --> 00:25:49,000
Which identity runs the automation?

611
00:25:49,000 --> 00:25:50,240
Which connections does it use?

612
00:25:50,240 --> 00:25:51,240
Who can maintain it?

613
00:25:51,240 --> 00:25:53,240
How does the flow move through test and production?

614
00:25:53,240 --> 00:25:55,040
Sharing a flow doesn't solve this by itself.

615
00:25:55,040 --> 00:25:56,720
You can share a flow with colleagues.

616
00:25:56,720 --> 00:25:58,440
You can give them permission to view it.

617
00:25:58,440 --> 00:26:00,600
You can give them permission to edit it.

618
00:26:00,600 --> 00:26:01,800
That helps with collaboration.

619
00:26:01,800 --> 00:26:04,560
But it doesn't automatically change the primary owner.

620
00:26:04,560 --> 00:26:08,040
The original identity can still remain at the center of the automation.

621
00:26:08,040 --> 00:26:10,920
Teams often discover that after the person is already left.

622
00:26:10,920 --> 00:26:12,520
They thought access meant ownership.

623
00:26:12,520 --> 00:26:13,520
It doesn't.

624
00:26:13,520 --> 00:26:14,840
Access lets someone participate.

625
00:26:14,840 --> 00:26:17,480
Ownership defines who carries the operational responsibility.

626
00:26:17,480 --> 00:26:21,760
So don't build business-critical automation under a personal identity and hope sharing

627
00:26:21,760 --> 00:26:23,680
will turn it into a team asset.

628
00:26:23,680 --> 00:26:25,960
Use an identity that matches the process.

629
00:26:25,960 --> 00:26:30,400
For unattended automation, that often means a service account with a defined purpose.

630
00:26:30,400 --> 00:26:33,240
Not a generic account whose password sits in an old document.

631
00:26:33,240 --> 00:26:34,640
Not a shared personal login.

632
00:26:34,640 --> 00:26:38,960
A real account with named operational owners, the right licensing, reviewed permissions,

633
00:26:38,960 --> 00:26:41,120
and a life cycle that survives staff changes.

634
00:26:41,120 --> 00:26:42,800
Its name should explain its role.

635
00:26:42,800 --> 00:26:45,760
Its access should be limited to what the flow needs.

636
00:26:45,760 --> 00:26:47,280
Its ownership should be documented.

637
00:26:47,280 --> 00:26:51,520
When someone reviews the automation, they should know who approves changes to that account,

638
00:26:51,520 --> 00:26:55,080
who checks its connections, and who acts when the flow fails.

639
00:26:55,080 --> 00:26:57,880
Application users also fit some application to application patterns.

640
00:26:57,880 --> 00:26:59,360
The point stays the same.

641
00:26:59,360 --> 00:27:01,760
The identity should represent the process boundary.

642
00:27:01,760 --> 00:27:04,040
Not the person who happened to build the first version.

643
00:27:04,040 --> 00:27:06,200
This is a small design choice at the start.

644
00:27:06,200 --> 00:27:10,840
Later, it becomes the difference between a managed process and a hidden dependency.

645
00:27:10,840 --> 00:27:13,720
Once automation has clear ownership, the next step becomes possible.

646
00:27:13,720 --> 00:27:15,320
You can package the process properly.

647
00:27:15,320 --> 00:27:16,680
You can move it between environments.

648
00:27:16,680 --> 00:27:20,000
You can separate the automation from the person who first created it.

649
00:27:20,000 --> 00:27:22,560
It starts when flows enter solutions.

650
00:27:22,560 --> 00:27:25,480
Environment variables keep environments different without rebuilds.

651
00:27:25,480 --> 00:27:29,240
A solution can move between environments, but the environment should not be identical.

652
00:27:29,240 --> 00:27:31,400
Your test environment uses a test mailbox.

653
00:27:31,400 --> 00:27:34,280
Your production environment uses a shared operations mailbox.

654
00:27:34,280 --> 00:27:37,280
One flow post to a team's channel for sales operations.

655
00:27:37,280 --> 00:27:40,600
Another environment points to a test channel where nobody mistakes a test approval for a

656
00:27:40,600 --> 00:27:41,600
real one.

657
00:27:41,600 --> 00:27:44,160
The flow design stays the same, the values change.

658
00:27:44,160 --> 00:27:45,840
That's what environment variables are for.

659
00:27:45,840 --> 00:27:48,200
They hold configuration outside the flow steps.

660
00:27:48,200 --> 00:27:56,000
A URL dot a mailbox address, a SharePoint site ID, a Q name, an approval threshold, a system

661
00:27:56,000 --> 00:27:58,280
endpoint without them.

662
00:27:58,280 --> 00:28:00,600
Make us type these values directly into the flow.

663
00:28:00,600 --> 00:28:02,760
The flow sends mail to a fixed address.

664
00:28:02,760 --> 00:28:04,000
It links to a fixed site.

665
00:28:04,000 --> 00:28:05,320
It calls a fixed URL.

666
00:28:05,320 --> 00:28:08,000
It uses a threshold buried inside a condition.

667
00:28:08,000 --> 00:28:11,480
Then the flow needs to move from development to test or from test to production.

668
00:28:11,480 --> 00:28:15,000
Now somebody must open the flow and replace each value by hand.

669
00:28:15,000 --> 00:28:16,320
That creates two problems.

670
00:28:16,320 --> 00:28:18,640
First, the package stops being portable.

671
00:28:18,640 --> 00:28:22,800
The process design includes details that only apply in one environment.

672
00:28:22,800 --> 00:28:25,640
Second, every deployment becomes an editing exercise.

673
00:28:25,640 --> 00:28:26,960
Someone can miss an address.

674
00:28:26,960 --> 00:28:29,120
Someone can leave a test URL in production.

675
00:28:29,120 --> 00:28:31,840
Someone can change the wrong threshold during a late release.

676
00:28:31,840 --> 00:28:33,280
Then the process behaves correctly.

677
00:28:33,280 --> 00:28:36,440
But in the wrong place, that kind of failure is frustrating because the logic may look

678
00:28:36,440 --> 00:28:37,280
fine.

679
00:28:37,280 --> 00:28:38,440
The flow triggered.

680
00:28:38,440 --> 00:28:39,600
The approval root worked.

681
00:28:39,600 --> 00:28:41,000
The record updated.

682
00:28:41,000 --> 00:28:43,320
But the notification went to the test mailbox.

683
00:28:43,320 --> 00:28:45,680
Or production wrote to the wrong sharepoint site.

684
00:28:45,680 --> 00:28:49,360
Or the flow sent data to an endpoint that no longer belongs to the active process.

685
00:28:49,360 --> 00:28:51,240
The issue didn't come from the automation logic.

686
00:28:51,240 --> 00:28:53,840
It came from configuration mixed into the logic.

687
00:28:53,840 --> 00:28:55,600
Environment variables separate those concerns.

688
00:28:55,600 --> 00:28:57,240
The flow defines what needs to happen.

689
00:28:57,240 --> 00:28:59,920
The environment variable defines where it happens.

690
00:28:59,920 --> 00:29:00,920
Who receives it?

691
00:29:00,920 --> 00:29:02,480
Or which value controls the root?

692
00:29:02,480 --> 00:29:04,000
Take an opportunity approval process.

693
00:29:04,000 --> 00:29:07,400
The logic says deals above a certain limit need commercial review.

694
00:29:07,400 --> 00:29:08,720
That rule belongs in the process.

695
00:29:08,720 --> 00:29:10,840
But the amount differs between test and production.

696
00:29:10,840 --> 00:29:15,640
In test, the team uses a low threshold to create approval scenarios quickly in production.

697
00:29:15,640 --> 00:29:19,360
The real policy uses the live threshold, the same flow supports both.

698
00:29:19,360 --> 00:29:25,120
No redesign, no copied version, no maker opening each condition and hoping nothing else changes.

699
00:29:25,120 --> 00:29:28,120
During deployment, the target environment receives the right value.

700
00:29:28,120 --> 00:29:30,160
The package stays consistent.

701
00:29:30,160 --> 00:29:33,360
The behavior changes only where the environment needs it to change.

702
00:29:33,360 --> 00:29:35,280
That gives test a real purpose.

703
00:29:35,280 --> 00:29:38,520
Testing should not mean building a near copy of production and manually adapting every

704
00:29:38,520 --> 00:29:43,000
flow it should mean validating the same automation package with controlled configuration.

705
00:29:43,000 --> 00:29:44,680
The test mailbox receives the message.

706
00:29:44,680 --> 00:29:46,400
The test side stores the document.

707
00:29:46,400 --> 00:29:47,960
The test queue receives the task.

708
00:29:47,960 --> 00:29:49,760
The test endpoint receives the request.

709
00:29:49,760 --> 00:29:53,800
Then, when the same package reaches production, the live values take over.

710
00:29:53,800 --> 00:29:55,520
The flow itself doesn't need a new shape.

711
00:29:55,520 --> 00:29:56,880
It needs the right configuration.

712
00:29:56,880 --> 00:29:59,760
This also works when the business changes without changing the whole process.

713
00:29:59,760 --> 00:30:01,600
A shared mailbox changes.

714
00:30:01,600 --> 00:30:03,480
A queue moves to another team.

715
00:30:03,480 --> 00:30:04,680
A site gets replaced.

716
00:30:04,680 --> 00:30:07,880
A threshold changes under an approved policy update.

717
00:30:07,880 --> 00:30:11,680
If the value sits in an environment variable, the team can manage that configuration through

718
00:30:11,680 --> 00:30:14,600
the proper route instead of editing the flow structure.

719
00:30:14,600 --> 00:30:17,480
That keeps process changes and configuration changes separate.

720
00:30:17,480 --> 00:30:19,280
They may need different reviews.

721
00:30:19,280 --> 00:30:22,760
Changing an approval path may need process owner sign off and testing.

722
00:30:22,760 --> 00:30:25,240
Changing a mailbox address may need confirmation from the service owner.

723
00:30:25,240 --> 00:30:26,240
Both changes matter.

724
00:30:26,240 --> 00:30:28,200
But they aren't the same kind of change.

725
00:30:28,200 --> 00:30:29,960
So give configuration a clear owner.

726
00:30:29,960 --> 00:30:31,400
A mailbox should have an owner.

727
00:30:31,400 --> 00:30:32,760
A queue should have an owner.

728
00:30:32,760 --> 00:30:34,720
An external URL should have an owner.

729
00:30:34,720 --> 00:30:36,960
A threshold should have a named policy owner.

730
00:30:36,960 --> 00:30:40,880
Too many teams treat configuration as nobody's job because it seems small.

731
00:30:40,880 --> 00:30:42,400
Then an old mailbox remains in use.

732
00:30:42,400 --> 00:30:44,480
A retired endpoint stays in a variable.

733
00:30:44,480 --> 00:30:47,480
A queue name points to a team that no longer handles the work.

734
00:30:47,480 --> 00:30:50,720
The automation keeps doing exactly what it was configured to do.

735
00:30:50,720 --> 00:30:52,200
Which is the problem.

736
00:30:52,200 --> 00:30:53,200
Configuration needs review dates.

737
00:30:53,200 --> 00:30:54,560
It needs named accountability.

738
00:30:54,560 --> 00:30:57,640
It needs a simple place where people can see what each value controls.

739
00:30:57,640 --> 00:31:01,640
Otherwise, you move hidden dependencies out of code and place them in unmanaged settings.

740
00:31:01,640 --> 00:31:02,800
That isn't progress.

741
00:31:02,800 --> 00:31:05,120
The goal isn't just to make deployment easier.

742
00:31:05,120 --> 00:31:09,160
It's to make the automation honest about what changes by environment and who controls those

743
00:31:09,160 --> 00:31:10,160
changes.

744
00:31:10,160 --> 00:31:13,560
Once flows, connections and configuration can travel as one managed unit.

745
00:31:13,560 --> 00:31:18,440
The next question is how you deploy that unit without turning production into a workshop.

746
00:31:18,440 --> 00:31:21,520
Managed solutions create a boundary around production.

747
00:31:21,520 --> 00:31:22,600
Production needs a boundary.

748
00:31:22,600 --> 00:31:24,360
Not because people can't be trusted.

749
00:31:24,360 --> 00:31:26,200
Because urgent changes feel reasonable at the time.

750
00:31:26,200 --> 00:31:27,200
A flow fails.

751
00:31:27,200 --> 00:31:28,800
A manager needs a root changed.

752
00:31:28,800 --> 00:31:30,760
A mailbox stops working.

753
00:31:30,760 --> 00:31:32,440
Someone opens production and fixes it.

754
00:31:32,440 --> 00:31:33,840
The process starts working again.

755
00:31:33,840 --> 00:31:36,360
Now production differs from the source solution.

756
00:31:36,360 --> 00:31:37,920
And the next deployment doesn't know that.

757
00:31:37,920 --> 00:31:42,800
A managed solution protects against that pattern when you import a managed solution into production.

758
00:31:42,800 --> 00:31:46,240
The package components cannot be directly edited in the normal way.

759
00:31:46,240 --> 00:31:47,240
The flow.

760
00:31:47,240 --> 00:31:48,240
App.

761
00:31:48,240 --> 00:31:49,720
Table changes.

762
00:31:49,720 --> 00:31:52,920
Connection references and other components arrive as a release.

763
00:31:52,920 --> 00:31:54,480
They remain tied to that release.

764
00:31:54,480 --> 00:31:57,160
That creates a clear rule if something needs to change.

765
00:31:57,160 --> 00:31:58,920
Change it where the solution is authored.

766
00:31:58,920 --> 00:31:59,920
Test it.

767
00:31:59,920 --> 00:32:02,200
Then deploy a new version without that boundary.

768
00:32:02,200 --> 00:32:04,120
And it becomes its own branch of the system.

769
00:32:04,120 --> 00:32:05,640
Not an official branch.

770
00:32:05,640 --> 00:32:08,160
A hidden one.

771
00:32:08,160 --> 00:32:11,760
Someone changes a flow in production to solve an urgent issue.

772
00:32:11,760 --> 00:32:14,440
Another person updates the source solution in development.

773
00:32:14,440 --> 00:32:16,280
Then the next managed deployment arrives.

774
00:32:16,280 --> 00:32:18,240
Now the team has two versions of the same process.

775
00:32:18,240 --> 00:32:20,040
One version exists in the source.

776
00:32:20,040 --> 00:32:22,120
Another exists in production.

777
00:32:22,120 --> 00:32:24,400
Neither one fully describes the live behavior.

778
00:32:24,400 --> 00:32:26,840
This is where unmanaged layers create confusion.

779
00:32:26,840 --> 00:32:29,320
A managed solution can exist in production.

780
00:32:29,320 --> 00:32:31,240
Then somebody adds a direct change on top of it.

781
00:32:31,240 --> 00:32:33,200
That change becomes an unmanaged layer.

782
00:32:33,200 --> 00:32:35,960
It may override the behavior shipped in the managed package.

783
00:32:35,960 --> 00:32:37,520
The process still works.

784
00:32:37,520 --> 00:32:39,560
Until another release arrives.

785
00:32:39,560 --> 00:32:42,400
Then the team needs to work out which part came from the package.

786
00:32:42,400 --> 00:32:44,320
Which part came from the production edit?

787
00:32:44,320 --> 00:32:46,240
And whether the new release will replace.

788
00:32:46,240 --> 00:32:47,240
Preserve.

789
00:32:47,240 --> 00:32:48,560
Or conflict with that change.

790
00:32:48,560 --> 00:32:51,520
Nobody wants to investigate solution layers during an incident.

791
00:32:51,520 --> 00:32:53,200
Yet that's where week release habits lead.

792
00:32:53,200 --> 00:32:54,920
The fix may have taken five minutes.

793
00:32:54,920 --> 00:32:58,560
The recovery later can take days because the team now has to reconstruct intent.

794
00:32:58,560 --> 00:33:00,000
Was the production edit temporary?

795
00:33:00,000 --> 00:33:01,000
Did anyone document it?

796
00:33:01,000 --> 00:33:02,800
Did the same change reach development?

797
00:33:02,800 --> 00:33:04,080
Did it reach test?

798
00:33:04,080 --> 00:33:07,560
Does the current source still represent the process the business relies on?

799
00:33:07,560 --> 00:33:09,360
A production patch can feel like speed.

800
00:33:09,360 --> 00:33:11,040
Often it only moves the work forward.

801
00:33:11,040 --> 00:33:13,600
The correct response is to fix the source solution.

802
00:33:13,600 --> 00:33:17,360
If a flow route needs changing, update the unmanaged solution in development.

803
00:33:17,360 --> 00:33:19,360
If a configuration value needs correction.

804
00:33:19,360 --> 00:33:21,200
Update it through the defined process.

805
00:33:21,200 --> 00:33:24,440
If a defect exists, reproduce it in the right environment.

806
00:33:24,440 --> 00:33:28,200
Apply the fix, test the outcome, and release it.

807
00:33:28,200 --> 00:33:30,600
That takes more discipline than opening the live flow.

808
00:33:30,600 --> 00:33:33,400
But it means the source continues to describe the product.

809
00:33:33,400 --> 00:33:36,720
And production continues to run a tested version of that product.

810
00:33:36,720 --> 00:33:39,840
This is where version numbers stop being administrative detail.

811
00:33:39,840 --> 00:33:42,240
A version identifies what the environment received.

812
00:33:42,240 --> 00:33:45,120
When a release enters production, the team should know what changed.

813
00:33:45,120 --> 00:33:46,680
Which process rule changed?

814
00:33:46,680 --> 00:33:48,080
Which defect was fixed?

815
00:33:48,080 --> 00:33:50,040
Which flow version now handles the work?

816
00:33:50,040 --> 00:33:51,640
When an issue appears?

817
00:33:51,640 --> 00:33:53,360
The team can ask a useful question.

818
00:33:53,360 --> 00:33:55,240
Did the start after version 2.4?

819
00:33:55,240 --> 00:33:58,680
That is a better starting point than searching through a live environment for changes nobody

820
00:33:58,680 --> 00:33:59,680
recorded.

821
00:33:59,680 --> 00:34:02,240
The version also creates a rollback conversation.

822
00:34:02,240 --> 00:34:05,880
Not every release needs a full reversal, but teams need to know what they can restore,

823
00:34:05,880 --> 00:34:07,520
what dependencies exist.

824
00:34:07,520 --> 00:34:10,080
And which tested version came before the current one?

825
00:34:10,080 --> 00:34:11,920
That knowledge comes from release discipline.

826
00:34:11,920 --> 00:34:15,240
Not from hoping the last export file still exists somewhere.

827
00:34:15,240 --> 00:34:17,000
Operational pressure exposes every week point.

828
00:34:17,000 --> 00:34:19,000
A senior leader wants an immediate change.

829
00:34:19,000 --> 00:34:20,400
A customer waits.

830
00:34:20,400 --> 00:34:22,320
An approval route fails at the wrong moment.

831
00:34:22,320 --> 00:34:24,200
The temptation is always the same.

832
00:34:24,200 --> 00:34:25,760
Just fix it in production.

833
00:34:25,760 --> 00:34:27,680
Sometimes an emergency response is unavoidable.

834
00:34:27,680 --> 00:34:29,600
But if emergency edits become normal.

835
00:34:29,600 --> 00:34:32,400
And no longer emergencies, they are the operating model.

836
00:34:32,400 --> 00:34:35,160
And that model creates drift, unclear ownership.

837
00:34:35,160 --> 00:34:37,040
And deployments nobody trusts.

838
00:34:37,040 --> 00:34:38,920
A mature team can still respond quickly.

839
00:34:38,920 --> 00:34:40,680
It has a defined emergency path.

840
00:34:40,680 --> 00:34:42,040
It records the change.

841
00:34:42,040 --> 00:34:44,240
It brings the fix back into the source solution.

842
00:34:44,240 --> 00:34:48,640
It tests and deploys the corrected version, so production does not stay different.

843
00:34:48,640 --> 00:34:49,640
That's the discipline.

844
00:34:49,640 --> 00:34:50,800
Not slowness.

845
00:34:50,800 --> 00:34:52,280
Not bureaucracy.

846
00:34:52,280 --> 00:34:54,920
A managed solution doesn't stop the business from changing.

847
00:34:54,920 --> 00:34:58,360
It stops untrag change from becoming permanent system behavior.

848
00:34:58,360 --> 00:35:00,160
And this is the shift people often miss.

849
00:35:00,160 --> 00:35:02,240
Governance isn't a queue that blocks automation.

850
00:35:02,240 --> 00:35:07,560
It defines the choices that let automation change without breaking production.

851
00:35:07,560 --> 00:35:10,400
Governance is the operating model, not the approval queue.

852
00:35:10,400 --> 00:35:11,800
Governance gets treated like a gate.

853
00:35:11,800 --> 00:35:13,040
A maker has an idea.

854
00:35:13,040 --> 00:35:14,520
They submit a request.

855
00:35:14,520 --> 00:35:15,520
It reviews it.

856
00:35:15,520 --> 00:35:16,760
The request waits.

857
00:35:16,760 --> 00:35:19,040
Then people decide governance slows everything down.

858
00:35:19,040 --> 00:35:20,040
But that is not governance.

859
00:35:20,040 --> 00:35:22,800
That is an approval queue pretending to be a strategy.

860
00:35:22,800 --> 00:35:24,120
Here's what governance actually does.

861
00:35:24,120 --> 00:35:26,320
It defines where different kinds of automation belong.

862
00:35:26,320 --> 00:35:30,320
It defines who can build, who can access data, who owns the process,

863
00:35:30,320 --> 00:35:33,840
and how a working idea becomes something the organization can rely on.

864
00:35:33,840 --> 00:35:35,560
The starting point is the environment.

865
00:35:35,560 --> 00:35:37,000
An environment is a container.

866
00:35:37,000 --> 00:35:42,280
It holds the apps, flows, connections, tables, and dataverse resources used for a purpose.

867
00:35:42,280 --> 00:35:44,080
And that purpose might be personal productivity.

868
00:35:44,080 --> 00:35:45,560
It might be a department process.

869
00:35:45,560 --> 00:35:48,600
It might be a production capability used across the company.

870
00:35:48,600 --> 00:35:49,640
Those are not the same thing.

871
00:35:49,640 --> 00:35:52,200
So they should not all follow the same rules.

872
00:35:52,200 --> 00:35:54,560
A personal automation can help one person save time.

873
00:35:54,560 --> 00:35:55,680
Maybe it sorts messages.

874
00:35:55,680 --> 00:35:57,240
Maybe it creates a reminder.

875
00:35:57,240 --> 00:36:00,560
Maybe it moves information between tools that person already uses.

876
00:36:00,560 --> 00:36:02,280
That work needs a safe place to exist.

877
00:36:02,280 --> 00:36:04,960
It should not need a full production release process.

878
00:36:04,960 --> 00:36:08,400
But it also should not quietly become the process that runs a department.

879
00:36:08,400 --> 00:36:09,920
Team automation sits in the middle.

880
00:36:09,920 --> 00:36:10,920
More people rely on it.

881
00:36:10,920 --> 00:36:12,240
It may use shared data.

882
00:36:12,240 --> 00:36:14,440
It may connect to a shared mailbox or a team's channel.

883
00:36:14,440 --> 00:36:18,240
It needs clearer ownership, defined access, and a path to support.

884
00:36:18,240 --> 00:36:20,160
Production automation has a different standard again.

885
00:36:20,160 --> 00:36:23,480
It affects customers, revenue, compliance, or core operations.

886
00:36:23,480 --> 00:36:24,720
It needs named owners.

887
00:36:24,720 --> 00:36:26,120
It needs control deployment.

888
00:36:26,120 --> 00:36:27,240
It needs monitoring.

889
00:36:27,240 --> 00:36:28,880
It needs an identity and access model that

890
00:36:28,880 --> 00:36:30,360
survives staff changes.

891
00:36:30,360 --> 00:36:34,560
A clear path for each type of work helps people choose correctly at the start.

892
00:36:34,560 --> 00:36:36,160
Instead of asking, can I build this?

893
00:36:36,160 --> 00:36:39,160
They ask, what kind of automation is this becoming?

894
00:36:39,160 --> 00:36:41,960
That one question prevents a lot of confusion later.

895
00:36:41,960 --> 00:36:43,560
Roads make the boundary real.

896
00:36:43,560 --> 00:36:47,000
Environment rolls control who can administer or build in an environment.

897
00:36:47,000 --> 00:36:51,120
Resource permissions control who can use edit or share a specific app or flow.

898
00:36:51,120 --> 00:36:54,480
Dataverse security rolls control, what data people can read, create, update,

899
00:36:54,480 --> 00:36:55,480
or delete.

900
00:36:55,480 --> 00:36:56,720
These are separate layers.

901
00:36:56,720 --> 00:36:59,600
And teams get into trouble when they treat them as one thing.

902
00:36:59,600 --> 00:37:04,120
Giving someone access to build a flow does not mean they should access every customer record.

903
00:37:04,120 --> 00:37:08,080
Giving someone a dataverse role does not mean they should edit production automation.

904
00:37:08,080 --> 00:37:11,840
Giving a user permission to run an app does not mean they should administer its environment.

905
00:37:11,840 --> 00:37:13,800
Each permission answers a different question.

906
00:37:13,800 --> 00:37:14,800
Who can build?

907
00:37:14,800 --> 00:37:15,800
Who can operate?

908
00:37:15,800 --> 00:37:16,800
Who can access the data?

909
00:37:16,800 --> 00:37:20,440
When those answers stay distinct, automation remains inside the business boundaries already

910
00:37:20,440 --> 00:37:22,720
defined in dynamics and dataverse.

911
00:37:22,720 --> 00:37:27,360
The power platform admin has a central role here, not as the person who builds every flow,

912
00:37:27,360 --> 00:37:29,960
not as the person who approves every small improvement.

913
00:37:29,960 --> 00:37:32,640
The admin creates the conditions for safe work.

914
00:37:32,640 --> 00:37:36,920
Environment strategy, access rules, support routes, visibility across the platform, a center

915
00:37:36,920 --> 00:37:38,840
of excellence can extend that role.

916
00:37:38,840 --> 00:37:40,760
It can help makers learn the right patterns.

917
00:37:40,760 --> 00:37:42,360
It can identify automation without owners.

918
00:37:42,360 --> 00:37:44,320
It can see which connectors are in use.

919
00:37:44,320 --> 00:37:47,760
It can find inactive or failing assets before users report a problem.

920
00:37:47,760 --> 00:37:50,800
It can guide teams toward the correct environment and delivery path.

921
00:37:50,800 --> 00:37:52,600
That is not central control for its own sake.

922
00:37:52,600 --> 00:37:54,280
It is shared operational awareness.

923
00:37:54,280 --> 00:37:56,920
Without it, every department solves the same problems alone.

924
00:37:56,920 --> 00:37:57,920
Who owns this flow?

925
00:37:57,920 --> 00:37:59,280
Which environment should we use?

926
00:37:59,280 --> 00:38:00,480
How do we deploy it?

927
00:38:00,480 --> 00:38:01,720
What happens if the maker leaves?

928
00:38:01,720 --> 00:38:03,000
Where do we report a failure?

929
00:38:03,000 --> 00:38:06,320
A good operating model answers those questions before they become incidents.

930
00:38:06,320 --> 00:38:08,720
And it also avoids forcing every request into IT.

931
00:38:08,720 --> 00:38:12,960
I should not become the bottleneck for a sales manager changing a rooting rule or a team

932
00:38:12,960 --> 00:38:15,200
improving a low-risk internal process.

933
00:38:15,200 --> 00:38:19,160
But the business should not be left alone with production data, shared identities, and

934
00:38:19,160 --> 00:38:20,720
unrestricted connectors either.

935
00:38:20,720 --> 00:38:23,960
The model gives people room to build within known boundaries.

936
00:38:23,960 --> 00:38:26,520
Personal makers get a safe place to experiment.

937
00:38:26,520 --> 00:38:28,600
Teams get support for shared automation.

938
00:38:28,600 --> 00:38:30,840
Production processes get the discipline their risk requires.

939
00:38:30,840 --> 00:38:34,760
That is how you scale automation without creating a second layer of unmanaged work.

940
00:38:34,760 --> 00:38:38,760
And once those parts are clear, the next decision is not who can use a connector.

941
00:38:38,760 --> 00:38:41,040
It is what data that connector is allowed to move.

942
00:38:41,040 --> 00:38:44,280
DLP policies define which data can travel together.

943
00:38:44,280 --> 00:38:46,480
A connector is not just a technical option.

944
00:38:46,480 --> 00:38:47,720
It is a route for data.

945
00:38:47,720 --> 00:38:49,160
And every route needs a decision.

946
00:38:49,160 --> 00:38:51,600
Every customer data leave data versed through this connector.

947
00:38:51,600 --> 00:38:52,600
Can it move into teams?

948
00:38:52,600 --> 00:38:53,640
Can it go to SharePoint?

949
00:38:53,640 --> 00:38:55,400
Can it reach a third-party service?

950
00:38:55,400 --> 00:38:58,640
The answer should not depend on what a maker happens to select in a flow.

951
00:38:58,640 --> 00:39:00,760
That is what data loss prevention policies control.

952
00:39:00,760 --> 00:39:04,520
DLP policies group connectors by the type of data they can handle together.

953
00:39:04,520 --> 00:39:07,360
One group can contain business data connectors.

954
00:39:07,360 --> 00:39:10,320
Another can contain connectors that should not handle business data.

955
00:39:10,320 --> 00:39:12,680
A third group blocks connectors entirely.

956
00:39:12,680 --> 00:39:13,960
The names are simple.

957
00:39:13,960 --> 00:39:14,960
Business?

958
00:39:14,960 --> 00:39:15,960
It's a non-business?

959
00:39:15,960 --> 00:39:16,960
Blocked.

960
00:39:16,960 --> 00:39:18,520
But the decision underneath is specific.

961
00:39:18,520 --> 00:39:23,760
If data versed holds customer records, account information, case data or commercial details,

962
00:39:23,760 --> 00:39:28,480
an organization may allow that data to work with approved Microsoft 365 services.

963
00:39:28,480 --> 00:39:31,120
Maybe outlook, maybe teams, maybe SharePoint.

964
00:39:31,120 --> 00:39:33,320
Those connectors can sit in the business data group.

965
00:39:33,320 --> 00:39:36,920
A connector placed in the non-business group cannot join that same flow with the business

966
00:39:36,920 --> 00:39:37,920
group.

967
00:39:37,920 --> 00:39:41,160
The policy stops the combination, not after the data already moved.

968
00:39:41,160 --> 00:39:44,320
Before the automation gets built, that is a different model from reviewing every flow

969
00:39:44,320 --> 00:39:45,320
by hand.

970
00:39:45,320 --> 00:39:48,800
The policy defines the allowed routes once, then make us work within those routes.

971
00:39:48,800 --> 00:39:52,360
If a connector is blocked, it cannot be used in power apps or power automate resources

972
00:39:52,360 --> 00:39:53,360
covered by that policy.

973
00:39:53,360 --> 00:39:55,040
That doesn't mean the connector is bad.

974
00:39:55,040 --> 00:39:58,680
It means the organization has decided it does not belong in that environment or with

975
00:39:58,680 --> 00:39:59,840
that class of data.

976
00:39:59,840 --> 00:40:03,080
A social media connector may make sense for a marketing experiment.

977
00:40:03,080 --> 00:40:06,720
It may not belong in an automation that begins with dynamics customer records.

978
00:40:06,720 --> 00:40:10,840
A file storage connector may be acceptable for low-risk productivity work.

979
00:40:10,840 --> 00:40:14,160
It may not be an approved destination for regulated case information.

980
00:40:14,160 --> 00:40:15,520
Here's the real question.

981
00:40:15,520 --> 00:40:17,640
Not can power automate connect to it?

982
00:40:17,640 --> 00:40:19,440
But should this data travel there?

983
00:40:19,440 --> 00:40:20,560
That shift matters.

984
00:40:20,560 --> 00:40:22,640
Connector combinations are data risk decisions.

985
00:40:22,640 --> 00:40:25,760
A flow can look harmless when each action appears separately.

986
00:40:25,760 --> 00:40:30,920
Read an account from dataverse, create a file, post a message, send an HTTP request.

987
00:40:30,920 --> 00:40:33,640
But together, those actions define a data route.

988
00:40:33,640 --> 00:40:34,720
Where did the data start?

989
00:40:34,720 --> 00:40:36,000
Which service received it?

990
00:40:36,000 --> 00:40:37,320
Who can access it there?

991
00:40:37,320 --> 00:40:39,320
What other systems can that service connect to?

992
00:40:39,320 --> 00:40:43,120
DLP policies force the organization to think about that route before a make-up press is

993
00:40:43,120 --> 00:40:44,120
safe.

994
00:40:44,120 --> 00:40:46,240
The environment should have different levels of freedom.

995
00:40:46,240 --> 00:40:50,000
A personal development environment may permit a limited set of low-risk connectors for

996
00:40:50,000 --> 00:40:51,280
learning and testing.

997
00:40:51,280 --> 00:40:54,480
A team environment may allow approved collaboration services.

998
00:40:54,480 --> 00:40:58,560
A production environment containing dynamics data may allow only the connectors needed

999
00:40:58,560 --> 00:41:00,160
for a defined business process.

1000
00:41:00,160 --> 00:41:01,840
That is not inconsistent governance.

1001
00:41:01,840 --> 00:41:04,560
It is governance based on process sensitivity.

1002
00:41:04,560 --> 00:41:08,840
A flow that sends an internal reminder doesn't carry the same risk as a flow that moves

1003
00:41:08,840 --> 00:41:12,160
customer, finance, or case data across systems.

1004
00:41:12,160 --> 00:41:16,760
Creating both the same either creates unnecessary friction or leaves too much open.

1005
00:41:16,760 --> 00:41:18,680
External sharing needs the same deliberate decision.

1006
00:41:18,680 --> 00:41:22,320
A flow can create a connection that crosses tenant boundaries when a user has valid access

1007
00:41:22,320 --> 00:41:26,040
in another tenant unless the organization restricts that path.

1008
00:41:26,040 --> 00:41:29,600
That creates a possible route for business data to leave the tenant through an approved

1009
00:41:29,600 --> 00:41:30,840
looking connection.

1010
00:41:30,840 --> 00:41:33,120
Some organizations need external collaboration.

1011
00:41:33,120 --> 00:41:36,240
Suppliers, partners, and acquired businesses may all require data movement.

1012
00:41:36,240 --> 00:41:38,600
The answer is not always to block every external route.

1013
00:41:38,600 --> 00:41:40,480
It is to define approved routes.

1014
00:41:40,480 --> 00:41:42,000
Which external tenants can connect?

1015
00:41:42,000 --> 00:41:43,000
In which direction?

1016
00:41:43,000 --> 00:41:44,440
For which environments?

1017
00:41:44,440 --> 00:41:45,920
For which business processes?

1018
00:41:45,920 --> 00:41:47,080
A production flow?

1019
00:41:47,080 --> 00:41:49,440
That sends information to an external partner?

1020
00:41:49,440 --> 00:41:51,800
Should use an agreed route with ownership and review?

1021
00:41:51,800 --> 00:41:55,720
It should not depend on a maker signing into another tenant with a personal connection.

1022
00:41:55,720 --> 00:41:58,440
Security works best when it enters the design at the start.

1023
00:41:58,440 --> 00:42:01,880
Not when someone discovers a connector after the process already depends on it.

1024
00:42:01,880 --> 00:42:03,840
The automation layer can move work quickly.

1025
00:42:03,840 --> 00:42:04,840
That is its purpose.

1026
00:42:04,840 --> 00:42:08,920
DLP makes sure it does not move business data without a defined boundary, but DLP only

1027
00:42:08,920 --> 00:42:10,800
governs the route between services.

1028
00:42:10,800 --> 00:42:14,920
It does not decide who can read or change the dynamics records underneath.

1029
00:42:14,920 --> 00:42:18,040
Dataverse security keeps automation inside business boundaries.

1030
00:42:18,040 --> 00:42:20,280
DLP tells data where it can go.

1031
00:42:20,280 --> 00:42:23,880
Dataverse security tells you who can work with that data before it ever moves.

1032
00:42:23,880 --> 00:42:28,160
Power Platform does not let users access records they don't already have permission to see.

1033
00:42:28,160 --> 00:42:29,400
That's the line that matters.

1034
00:42:29,400 --> 00:42:30,920
A flow connects to dynamics.

1035
00:42:30,920 --> 00:42:32,200
A user opens an app.

1036
00:42:32,200 --> 00:42:33,960
A maker builds automation.

1037
00:42:33,960 --> 00:42:36,760
None of that should become a shortcut around the security underneath.

1038
00:42:36,760 --> 00:42:40,720
The record still has rules, who can read it, who can update it, who can assign it, who can

1039
00:42:40,720 --> 00:42:41,720
delete it.

1040
00:42:41,720 --> 00:42:44,240
Those permissions come from Dataverse security roles.

1041
00:42:44,240 --> 00:42:47,000
A sales user may read and update their own opportunities.

1042
00:42:47,000 --> 00:42:49,120
A sales manager sees records across a team.

1043
00:42:49,120 --> 00:42:52,560
A finance user can access commercial fields that sellers cannot touch.

1044
00:42:52,560 --> 00:42:54,640
The automation has to respect those boundaries.

1045
00:42:54,640 --> 00:42:58,320
Otherwise, you get a process that looks controlled on the surface, but actually moves

1046
00:42:58,320 --> 00:43:02,120
data or updates records with more authority than the business intended.

1047
00:43:02,120 --> 00:43:03,760
Field-level security adds another layer.

1048
00:43:03,760 --> 00:43:06,720
Not everyone who sees a record should see every value on it.

1049
00:43:06,720 --> 00:43:09,720
A customer record might contain sensitive financial information.

1050
00:43:09,720 --> 00:43:11,520
A case could include restricted notes.

1051
00:43:11,520 --> 00:43:14,400
A contract may have terms limited to a specific group.

1052
00:43:14,400 --> 00:43:18,400
Field-level security controls, who reads, creates, or updates those fields that matters

1053
00:43:18,400 --> 00:43:19,760
for automation too.

1054
00:43:19,760 --> 00:43:24,320
If a flow uses restricted data, the identity running that flow needs the right permission.

1055
00:43:24,320 --> 00:43:25,320
No more than that.

1056
00:43:25,320 --> 00:43:29,840
A broad automation account with system administrator access might feel convenient during a build.

1057
00:43:29,840 --> 00:43:33,720
But it's also an easy way to hide excessive access inside a process.

1058
00:43:33,720 --> 00:43:34,720
Nobody reviews.

1059
00:43:34,720 --> 00:43:36,480
Give the automation only what it needs.

1060
00:43:36,480 --> 00:43:40,040
If it only reads opportunities and writes approval outcomes, grant that scope.

1061
00:43:40,040 --> 00:43:44,680
If it needs to create tasks, grant task permissions, if it never deletes records do not grant

1062
00:43:44,680 --> 00:43:47,640
delete rights just because the account might need them one day.

1063
00:43:47,640 --> 00:43:49,120
Least privilege is not paperwork.

1064
00:43:49,120 --> 00:43:53,280
It limits the damage when a connection gets misused, a flow behaves unexpectedly, or an

1065
00:43:53,280 --> 00:43:54,840
account gets compromised.

1066
00:43:54,840 --> 00:43:57,360
Auditing gives teams a way to inspect what happened.

1067
00:43:57,360 --> 00:43:58,560
A record changed.

1068
00:43:58,560 --> 00:43:59,800
A field changed.

1069
00:43:59,800 --> 00:44:01,560
And owner changed.

1070
00:44:01,560 --> 00:44:04,200
The audit trail answers who perform the action and when.

1071
00:44:04,200 --> 00:44:07,760
For regulated processes, that record may be part of the control itself.

1072
00:44:07,760 --> 00:44:10,640
For ordinary support work, it separates assumptions from evidence.

1073
00:44:10,640 --> 00:44:12,800
A customer's start is changed after an approval.

1074
00:44:12,800 --> 00:44:14,040
Was that a user action?

1075
00:44:14,040 --> 00:44:15,360
Was it an automation account?

1076
00:44:15,360 --> 00:44:17,360
Was it an integration?

1077
00:44:17,360 --> 00:44:20,000
The record history helps the team trace the path.

1078
00:44:20,000 --> 00:44:22,160
Security also depends on how records are owned.

1079
00:44:22,160 --> 00:44:24,840
Some tables hold organization-owned records.

1080
00:44:24,840 --> 00:44:28,440
Those records belong to the organization rather than a specific user or team.

1081
00:44:28,440 --> 00:44:32,320
They suit shared reference data where personal ownership does not define access.

1082
00:44:32,320 --> 00:44:34,320
Other tables use user or team ownership.

1083
00:44:34,320 --> 00:44:38,600
That model matters because ownership shapes who sees a record and who can act on it.

1084
00:44:38,600 --> 00:44:40,480
An opportunity may belong to a seller.

1085
00:44:40,480 --> 00:44:41,960
A case may belong to a service team.

1086
00:44:41,960 --> 00:44:46,000
A shared queue process moves work between owners as responsibility changes.

1087
00:44:46,000 --> 00:44:49,600
The automation should understand that model before it changes anything.

1088
00:44:49,600 --> 00:44:51,600
Assigning a record is not just an update.

1089
00:44:51,600 --> 00:44:53,920
It can change who accesses the record next.

1090
00:44:53,920 --> 00:44:55,920
It can change who receives follow-up work.

1091
00:44:55,920 --> 00:44:59,400
Defects reporting, workload views and escalation routes.

1092
00:44:59,400 --> 00:45:00,800
Business units add another boundary.

1093
00:45:00,800 --> 00:45:03,360
They structure access around parts of the organization.

1094
00:45:03,360 --> 00:45:07,800
A company might separate sales regions, legal entities, departments or operational groups

1095
00:45:07,800 --> 00:45:09,320
through business units and teams.

1096
00:45:09,320 --> 00:45:12,560
That structure shapes the records people can access through their roles.

1097
00:45:12,560 --> 00:45:16,560
So an automation that routes work across teams or reassigns records needs to follow the

1098
00:45:16,560 --> 00:45:17,760
actual security design.

1099
00:45:17,760 --> 00:45:22,360
It cannot assume every user should see every record just because the flow can find it.

1100
00:45:22,360 --> 00:45:23,480
Contacts decides the route.

1101
00:45:23,480 --> 00:45:25,600
But security decides whether that route is allowed.

1102
00:45:25,600 --> 00:45:28,840
This is where poor automation design often creates silent problems.

1103
00:45:28,840 --> 00:45:30,760
A flow runs under a powerful identity.

1104
00:45:30,760 --> 00:45:32,240
It updates records across teams.

1105
00:45:32,240 --> 00:45:35,240
It bypasses the limits that users experience every day.

1106
00:45:35,240 --> 00:45:36,560
The process works.

1107
00:45:36,560 --> 00:45:38,760
But it creates results nobody can explain.

1108
00:45:38,760 --> 00:45:40,800
A seller sees a record move away from them.

1109
00:45:40,800 --> 00:45:43,200
A manager receives data from another business unit.

1110
00:45:43,200 --> 00:45:45,680
A restricted field appears in a notification.

1111
00:45:45,680 --> 00:45:48,080
The automation did exactly what it's account allowed.

1112
00:45:48,080 --> 00:45:50,520
The account simply had too much authority.

1113
00:45:50,520 --> 00:45:52,920
Designed the automation identity around the process.

1114
00:45:52,920 --> 00:45:56,400
A name-to-count for unattended work where that fits the operating model.

1115
00:45:56,400 --> 00:45:58,160
Give it a defined security role.

1116
00:45:58,160 --> 00:45:59,160
Review its permissions.

1117
00:45:59,160 --> 00:46:02,400
Review where it sits in the business unit and team structure.

1118
00:46:02,400 --> 00:46:06,040
Then test the automation using the permissions it will actually have in production.

1119
00:46:06,040 --> 00:46:09,600
Do not build with administrator access and assume normal access will behave the same way

1120
00:46:09,600 --> 00:46:10,600
later.

1121
00:46:10,600 --> 00:46:12,960
Security changes who can own automation safely.

1122
00:46:12,960 --> 00:46:16,120
A personal maker identity may be suitable for low-risk work.

1123
00:46:16,120 --> 00:46:20,640
A production flow handling shared records, sensitive data or unattended updates needs

1124
00:46:20,640 --> 00:46:24,800
an owner model that matches the process, the data and the responsibility.

1125
00:46:24,800 --> 00:46:27,600
Build fewer flows with clearer process boundaries.

1126
00:46:27,600 --> 00:46:29,640
One business outcome, one primary flow.

1127
00:46:29,640 --> 00:46:30,680
That should be your default.

1128
00:46:30,680 --> 00:46:32,360
Not one flow for every small click.

1129
00:46:32,360 --> 00:46:34,160
Not one flow for every field update.

1130
00:46:34,160 --> 00:46:37,680
Not a collection of tiny automations that nobody can connect into one process.

1131
00:46:37,680 --> 00:46:39,480
Take an opportunity approval.

1132
00:46:39,480 --> 00:46:40,840
The outcome is clear.

1133
00:46:40,840 --> 00:46:45,080
A deal reaches a point where someone must approve, reject or request changes.

1134
00:46:45,080 --> 00:46:46,400
That process may check data.

1135
00:46:46,400 --> 00:46:47,480
It may root approval.

1136
00:46:47,480 --> 00:46:48,600
It may send reminders.

1137
00:46:48,600 --> 00:46:49,920
It may update the record.

1138
00:46:49,920 --> 00:46:51,280
It may notify the seller.

1139
00:46:51,280 --> 00:46:54,480
Those steps belong together because they produce one business outcome.

1140
00:46:54,480 --> 00:46:57,160
Splitting them into separate flows can look tidy at first.

1141
00:46:57,160 --> 00:46:58,760
One flow checks the amount.

1142
00:46:58,760 --> 00:47:00,080
Another sends the approval.

1143
00:47:00,080 --> 00:47:01,520
Another writes the outcome.

1144
00:47:01,520 --> 00:47:02,840
Another sends the reminder.

1145
00:47:02,840 --> 00:47:05,840
Soon, no one knows which flow owns the process.

1146
00:47:05,840 --> 00:47:09,720
A failure in one flow leaves the record halfway through the journey.

1147
00:47:09,720 --> 00:47:13,400
Support has to trace several run histories just to answer a simple question.

1148
00:47:13,400 --> 00:47:14,880
Did the approval start?

1149
00:47:14,880 --> 00:47:15,880
Did it finish?

1150
00:47:15,880 --> 00:47:17,440
Why didn't the seller receive the result?

1151
00:47:17,440 --> 00:47:19,880
The process boundary disappeared.

1152
00:47:19,880 --> 00:47:22,600
That doesn't mean every action belongs in one enormous flow.

1153
00:47:22,600 --> 00:47:27,520
A flow that handles several unrelated outcomes becomes difficult to test and harder to change.

1154
00:47:27,520 --> 00:47:29,440
The boundary should follow the business result.

1155
00:47:29,440 --> 00:47:32,560
A customer onboarding flow should own the onboarding outcome.

1156
00:47:32,560 --> 00:47:35,320
A case escalation flow should own the escalation outcome.

1157
00:47:35,320 --> 00:47:38,680
A sales approval flow should own the approval outcome.

1158
00:47:38,680 --> 00:47:40,800
Give each flow a name that says exactly that.

1159
00:47:40,800 --> 00:47:44,560
Not flow 7, not CRM automation final, not new version.

1160
00:47:44,560 --> 00:47:47,600
Use names people can search for when the business asks the question.

1161
00:47:47,600 --> 00:47:50,280
Sales opportunity commercial approval.

1162
00:47:50,280 --> 00:47:53,440
Customer case, SLA escalation.

1163
00:47:53,440 --> 00:47:55,560
Contract renewal follow up.

1164
00:47:55,560 --> 00:47:58,360
The name should tell support what the flow does before they open it.

1165
00:47:58,360 --> 00:47:59,760
Descriptions matter too.

1166
00:47:59,760 --> 00:48:03,680
A description can state the trigger, the business owner, the operational owner, the systems

1167
00:48:03,680 --> 00:48:06,320
involved and the condition that starts the process.

1168
00:48:06,320 --> 00:48:07,920
It can explain what the flow changes.

1169
00:48:07,920 --> 00:48:10,520
It can point to the process documentation or support route.

1170
00:48:10,520 --> 00:48:11,600
That is not busy work.

1171
00:48:11,600 --> 00:48:16,520
Six months later, it is the difference between an understandable asset and an unexplained dependency.

1172
00:48:16,520 --> 00:48:18,400
Trigger scope needs the same discipline.

1173
00:48:18,400 --> 00:48:22,360
A dataverse flow should not react to every update on a table when it only cares about

1174
00:48:22,360 --> 00:48:23,560
one business change.

1175
00:48:23,560 --> 00:48:27,920
If an approval begins when an opportunity reaches a certain stage, configure the flow around

1176
00:48:27,920 --> 00:48:28,920
that condition.

1177
00:48:28,920 --> 00:48:33,160
Do not wake it up when someone corrects a phone number, add the note or changes in unrelated

1178
00:48:33,160 --> 00:48:34,160
field.

1179
00:48:34,160 --> 00:48:37,760
Broad triggers create noise, they create unnecessary runs, they create hidden cost.

1180
00:48:37,760 --> 00:48:41,680
They also make failures harder to read because the run history fills with work the process

1181
00:48:41,680 --> 00:48:43,120
never needed to do.

1182
00:48:43,120 --> 00:48:47,480
Define the entry condition clearly, what changed, which table matters, which columns matter,

1183
00:48:47,480 --> 00:48:49,760
which status or stage starts the process.

1184
00:48:49,760 --> 00:48:51,480
Who owns the flow once it runs?

1185
00:48:51,480 --> 00:48:54,680
These questions create a boundary before the flow even begins.

1186
00:48:54,680 --> 00:48:58,400
Reusable child flows can help, but only when shared behavior truly exists.

1187
00:48:58,400 --> 00:49:03,160
A common pattern might create a standard notification, log a process outcome or build a consistent

1188
00:49:03,160 --> 00:49:04,160
approval summary.

1189
00:49:04,160 --> 00:49:07,800
If several business processes need that exact behavior, a child flow can keep it in one

1190
00:49:07,800 --> 00:49:08,960
place.

1191
00:49:08,960 --> 00:49:13,680
But reuse should not become an obsession, two flows that both send email do not automatically

1192
00:49:13,680 --> 00:49:15,280
need the same child flow.

1193
00:49:15,280 --> 00:49:18,640
Their messages may have different owners, different data rules, different failure parts,

1194
00:49:18,640 --> 00:49:20,240
and different reasons for existing.

1195
00:49:20,240 --> 00:49:23,960
Fourcing them together creates a shared component nobody can change safely.

1196
00:49:23,960 --> 00:49:26,560
Reuse works when the responsibility is genuinely shared.

1197
00:49:26,560 --> 00:49:31,040
The function has one purpose, its inputs are clear, its output is clear, and the team is

1198
00:49:31,040 --> 00:49:34,920
using it agree on how it should behave, otherwise keep the logic close to the process that

1199
00:49:34,920 --> 00:49:35,920
owns it.

1200
00:49:35,920 --> 00:49:39,200
Design the exception route before the happy path feels complete.

1201
00:49:39,200 --> 00:49:44,200
Most automations look fine when every record contains the right data, every connector response,

1202
00:49:44,200 --> 00:49:46,560
and every approver replies on time.

1203
00:49:46,560 --> 00:49:50,280
Production rarely stays that polite, what happens when the record is incomplete, what happens

1204
00:49:50,280 --> 00:49:54,280
when the approval group has no active members, what happens when the external system rejects

1205
00:49:54,280 --> 00:49:58,960
the request, what happens when the same record changes again while work is already in progress.

1206
00:49:58,960 --> 00:50:03,320
Those are not edge cases after launch, they are part of the process, give them a route,

1207
00:50:03,320 --> 00:50:05,240
notify the right owner.

1208
00:50:05,240 --> 00:50:09,240
Create a review task, set a status that tells the business what stopped, do not leave a record

1209
00:50:09,240 --> 00:50:12,320
in silence because the flow expected a perfect path.

1210
00:50:12,320 --> 00:50:15,800
Circular updates need special attention, a flow triggers on a dataverse update, then it

1211
00:50:15,800 --> 00:50:19,040
updates the same record, that update can trigger the flow again.

1212
00:50:19,040 --> 00:50:22,840
Now the process may loop, create duplicate actions, or consume runs without producing

1213
00:50:22,840 --> 00:50:27,480
useful work, use trigger conditions, update only the fields that need changing.

1214
00:50:27,480 --> 00:50:30,680
Separate automation state from general record updates where appropriate.

1215
00:50:30,680 --> 00:50:35,160
People look for competing automations, one flow updates a status, another flow reacts to

1216
00:50:35,160 --> 00:50:39,520
that status, a plug-in changes the same field, a business rule changes it again, each component

1217
00:50:39,520 --> 00:50:43,760
may look reasonable alone, together they create unpredictable behavior, map the automation

1218
00:50:43,760 --> 00:50:46,160
touching a process before adding another one.

1219
00:50:46,160 --> 00:50:48,360
The question is not can this flow do it?

1220
00:50:48,360 --> 00:50:51,840
The question is which automation already owns this outcome?

1221
00:50:51,840 --> 00:50:56,040
When the answer stays clear, the process stays easier to change, but clear design only helps

1222
00:50:56,040 --> 00:50:59,800
if people can see how the automation behaves after it starts.

1223
00:50:59,800 --> 00:51:02,320
Everyone starts with an inventory, not a rewrite.

1224
00:51:02,320 --> 00:51:06,940
Don't start by rewriting plug-ins, start by finding out what exists, most dynamics environments

1225
00:51:06,940 --> 00:51:08,760
carry years of automation.

1226
00:51:08,760 --> 00:51:12,880
Some of it still runs every day, some of it only fires when a rare case appears, and some

1227
00:51:12,880 --> 00:51:14,640
of it stopped mattering years ago.

1228
00:51:14,640 --> 00:51:19,360
But it still sits there, a migration plan fails when it treats all custom work as one problem,

1229
00:51:19,360 --> 00:51:23,400
it isn't one problem, you need an inventory first, list every plug-in, every JavaScript

1230
00:51:23,400 --> 00:51:28,440
library, every classic workflow, every custom workflow activity, every integration,

1231
00:51:28,440 --> 00:51:32,800
every scheduled job, every flow already touching the same records.

1232
00:51:32,800 --> 00:51:36,920
Then add one detail people often miss, who owns it, not who built it, who owns the business

1233
00:51:36,920 --> 00:51:37,920
rule today.

1234
00:51:37,920 --> 00:51:41,520
A developer may have written a plug-in five years ago that doesn't tell you whether sales,

1235
00:51:41,520 --> 00:51:44,440
finance, service or legal still wants the outcome.

1236
00:51:44,440 --> 00:51:48,400
The code describes behavior, it doesn't prove the behavior still belongs in the process.

1237
00:51:48,400 --> 00:51:53,240
For each item, capture the table it touches, capture the trigger, capture the fields it reads,

1238
00:51:53,240 --> 00:51:57,000
capture the fields it changes, capture every external system it calls.

1239
00:51:57,000 --> 00:52:00,920
Then ask a simpler question, what job does this automation actually perform?

1240
00:52:00,920 --> 00:52:06,000
Some items react to an event, an opportunity changes stage, a case reaches a deadline, a record

1241
00:52:06,000 --> 00:52:09,760
enters a new status, others apply reasoning, they decide whether a policy applies, they

1242
00:52:09,760 --> 00:52:13,600
calculate a route, they check whether a condition allows work to continue.

1243
00:52:13,600 --> 00:52:17,720
Then there is orchestration, the automation sends a notification, it creates a task, it

1244
00:52:17,720 --> 00:52:22,640
requests approval, it updates another system, it waits, escalates and closes the loop.

1245
00:52:22,640 --> 00:52:27,760
Lap each asset to those three jobs, event, reasoning, orchestration, one plug-in may contain all

1246
00:52:27,760 --> 00:52:32,600
three, that is common, a record changes, the plug-in checks several rules, then calls another

1247
00:52:32,600 --> 00:52:34,600
system and creates follow-up work.

1248
00:52:34,600 --> 00:52:38,200
That doesn't mean the plug-in was poorly built, it means several responsibilities accumulated

1249
00:52:38,200 --> 00:52:40,920
in one place, the inventory makes that visible.

1250
00:52:40,920 --> 00:52:44,320
Once you see the responsibilities, you can discuss the right future boundary.

1251
00:52:44,320 --> 00:52:48,680
Without that view, teams often replace code line by line, they recreate every old step

1252
00:52:48,680 --> 00:52:52,600
in a flow, they preserve every old condition, they carry forward every exception,

1253
00:52:52,600 --> 00:52:58,480
and they rebuild the same complexity using different tools, that isn't modernization, it is relocation.

1254
00:52:58,480 --> 00:53:02,520
You also need to find dependencies that aren't obvious from the automation name, a plug-in

1255
00:53:02,520 --> 00:53:05,160
may depend on a field that no one uses on the form.

1256
00:53:05,160 --> 00:53:09,680
A script may call a web resource used by only one app, a classic workflow may start another

1257
00:53:09,680 --> 00:53:13,920
workflow, an integration may expect a value to appear in a specific field before it processes

1258
00:53:13,920 --> 00:53:18,760
the record, a flow may already react to the same status change, these dependencies define

1259
00:53:18,760 --> 00:53:22,280
the risk, they tell you what could break when you move one piece.

1260
00:53:22,280 --> 00:53:23,480
And mode matters too.

1261
00:53:23,480 --> 00:53:25,520
Does the automation run before a record saves?

1262
00:53:25,520 --> 00:53:27,160
Does it run after the record changes?

1263
00:53:27,160 --> 00:53:28,320
Does it run in the background?

1264
00:53:28,320 --> 00:53:29,320
Does it run on a schedule?

1265
00:53:29,320 --> 00:53:30,560
Does it wait for a person?

1266
00:53:30,560 --> 00:53:33,920
A name like Opportunity Validation tells you almost nothing about that boundary.

1267
00:53:33,920 --> 00:53:38,560
The execution mode tells you whether the process affects data integrity, user experience,

1268
00:53:38,560 --> 00:53:42,960
or downstream work, documented clearly, also document the business owner, not a vague department

1269
00:53:42,960 --> 00:53:47,800
label, a real person or role responsible for deciding whether the rule remains valid.

1270
00:53:47,800 --> 00:53:50,480
That conversation can expose surprising things.

1271
00:53:50,480 --> 00:53:55,280
The team may discover that a complex approval route supports a policy that no longer exists.

1272
00:53:55,280 --> 00:53:59,280
A script may enforce a field requirement that the business removed from its process years

1273
00:53:59,280 --> 00:54:00,280
ago.

1274
00:54:00,280 --> 00:54:04,560
An integration may keep sending data to a system nobody uses, all customizations often

1275
00:54:04,560 --> 00:54:06,800
remain because nobody wants to touch them.

1276
00:54:06,800 --> 00:54:10,280
The inventory gives you a safer way to ask whether they should remain.

1277
00:54:10,280 --> 00:54:12,640
Separate active business rules from abandoned behavior.

1278
00:54:12,640 --> 00:54:16,760
A rule is active when someone can explain its purpose, confirm its owner, and describe

1279
00:54:16,760 --> 00:54:18,280
the outcome it still protects.

1280
00:54:18,280 --> 00:54:22,480
A customization without that evidence is not automatically safe to remove, but it should

1281
00:54:22,480 --> 00:54:25,240
not receive the same investment as a live process.

1282
00:54:25,240 --> 00:54:26,560
Market for investigation.

1283
00:54:26,560 --> 00:54:27,920
Look at whether it still runs.

1284
00:54:27,920 --> 00:54:29,920
Check whether records still depend on it.

1285
00:54:29,920 --> 00:54:32,440
Confirm whether another automation already replaced it.

1286
00:54:32,440 --> 00:54:34,760
Then decide with the people responsible for the process.

1287
00:54:34,760 --> 00:54:37,240
This work changes the migration conversation.

1288
00:54:37,240 --> 00:54:39,560
Instead of asking which plugins can we convert?

1289
00:54:39,560 --> 00:54:42,760
You ask which business outcomes still need automation?

1290
00:54:42,760 --> 00:54:43,760
That is a better question.

1291
00:54:43,760 --> 00:54:45,240
Now you can prioritize.

1292
00:54:45,240 --> 00:54:46,240
Start with pain.

1293
00:54:46,240 --> 00:54:49,680
Automation causes failures, delays, support work or manual chasing.

1294
00:54:49,680 --> 00:54:50,680
Then look at change frequency.

1295
00:54:50,680 --> 00:54:54,480
A rule that changes every quarter may suit a more visible automation model than a stable

1296
00:54:54,480 --> 00:54:56,520
calculation untouched for years.

1297
00:54:56,520 --> 00:54:57,520
Consider risk.

1298
00:54:57,520 --> 00:55:01,640
A process tied to sensitive data, revenue decisions or compliance needs a careful path.

1299
00:55:01,640 --> 00:55:03,520
Finally, consider technical fit.

1300
00:55:03,520 --> 00:55:05,960
Some automation belongs outside the record transaction.

1301
00:55:05,960 --> 00:55:06,960
Some does not.

1302
00:55:06,960 --> 00:55:10,720
Some code should remain because replacing it creates more risk than value.

1303
00:55:10,720 --> 00:55:13,120
After the inventory, every item needs a category.

1304
00:55:13,120 --> 00:55:14,120
Not a target tool yet.

1305
00:55:14,120 --> 00:55:15,120
A category.

1306
00:55:15,120 --> 00:55:18,600
Only then can you choose what changes, what stays and what should disappear.

1307
00:55:18,600 --> 00:55:21,360
A safer migration path from custom automation.

1308
00:55:21,360 --> 00:55:23,360
Don't begin with the most dangerous plugin.

1309
00:55:23,360 --> 00:55:25,040
Begin with the one that changes often.

1310
00:55:25,040 --> 00:55:26,920
Look for automation that crosses systems.

1311
00:55:26,920 --> 00:55:31,720
A process that updates dynamics, sends an approval, creates a task and notifies a team.

1312
00:55:31,720 --> 00:55:33,160
That is usually a better first move.

1313
00:55:33,160 --> 00:55:34,600
The boundary is easier to see.

1314
00:55:34,600 --> 00:55:37,320
And the business already feels the cost of every change.

1315
00:55:37,320 --> 00:55:39,720
Choose something important enough to prove the model.

1316
00:55:39,720 --> 00:55:42,120
But not so central that one mistake stops the company.

1317
00:55:42,120 --> 00:55:43,920
A recurring approval root works well.

1318
00:55:43,920 --> 00:55:46,040
A customer follow-up process can work too.

1319
00:55:46,040 --> 00:55:49,920
So can a notification process that depends on dynamics data and needs action in teams or

1320
00:55:49,920 --> 00:55:54,160
outlook pick work where the process changes more often than the data model.

1321
00:55:54,160 --> 00:55:57,560
That is where a visible automation layer earns its place fastest.

1322
00:55:57,560 --> 00:56:00,400
Before building anything, document the current behavior.

1323
00:56:00,400 --> 00:56:02,920
Not the intended behavior, the current behavior.

1324
00:56:02,920 --> 00:56:04,360
What does the automation produce?

1325
00:56:04,360 --> 00:56:05,600
Which records change?

1326
00:56:05,600 --> 00:56:06,600
Which messages send?

1327
00:56:06,600 --> 00:56:08,320
Which systems receive data?

1328
00:56:08,320 --> 00:56:09,680
What exceptions already exist?

1329
00:56:09,680 --> 00:56:12,560
A process may skip approval for certain account types.

1330
00:56:12,560 --> 00:56:14,920
It may root requests differently by region.

1331
00:56:14,920 --> 00:56:17,320
It may retry an external call after failure.

1332
00:56:17,320 --> 00:56:20,520
It may depend on a field updated by another customization.

1333
00:56:20,520 --> 00:56:22,840
Write that down, then document permissions.

1334
00:56:22,840 --> 00:56:24,760
Which identity runs the current automation?

1335
00:56:24,760 --> 00:56:25,920
What records can it read?

1336
00:56:25,920 --> 00:56:27,120
What data can it change?

1337
00:56:27,120 --> 00:56:29,400
Which external service permissions does it use?

1338
00:56:29,400 --> 00:56:34,200
A replacement flow cannot safely reproduce the outcome if nobody understands the authority

1339
00:56:34,200 --> 00:56:36,120
behind the old process.

1340
00:56:36,120 --> 00:56:37,440
Dependencies need the same attention.

1341
00:56:37,440 --> 00:56:41,200
A custom plug-in may publish a value that another integration expects.

1342
00:56:41,200 --> 00:56:43,480
Script may set a field that triggers later work.

1343
00:56:43,480 --> 00:56:47,120
A background process may rely on a status being written in a specific sequence.

1344
00:56:47,120 --> 00:56:50,720
The old automation may contain behavior the business never asked for directly, but other

1345
00:56:50,720 --> 00:56:51,960
systems still expect.

1346
00:56:51,960 --> 00:56:53,680
That is why migration needs evidence.

1347
00:56:53,680 --> 00:56:54,680
Not assumptions.

1348
00:56:54,680 --> 00:56:58,080
Once the behavior is understood, build the replacement in development.

1349
00:56:58,080 --> 00:56:59,080
Build it through a solution.

1350
00:56:59,080 --> 00:57:00,080
Bring in the flow.

1351
00:57:00,080 --> 00:57:01,600
Bring in the connection references.

1352
00:57:01,600 --> 00:57:03,160
Bring in the environment variables.

1353
00:57:03,160 --> 00:57:04,920
Keep the process components together.

1354
00:57:04,920 --> 00:57:08,840
The replacement should not begin as a personal flow that someone plans to organize later.

1355
00:57:08,840 --> 00:57:10,760
Later usually means after it becomes important.

1356
00:57:10,760 --> 00:57:13,000
Give it the right structure from the first version.

1357
00:57:13,000 --> 00:57:14,680
Use controlled configuration.

1358
00:57:14,680 --> 00:57:16,320
Use the right identity model.

1359
00:57:16,320 --> 00:57:17,360
Name the assets clearly.

1360
00:57:17,360 --> 00:57:21,520
A migration is not just moving logic from C-Port into a visual designer.

1361
00:57:21,520 --> 00:57:24,920
It is moving the process into an operating model that can support change.

1362
00:57:24,920 --> 00:57:26,520
Then test it beside the existing process.

1363
00:57:26,520 --> 00:57:29,880
Do not switch off the old automation on the day the new flow is built.

1364
00:57:29,880 --> 00:57:31,480
Use controlled records.

1365
00:57:31,480 --> 00:57:33,080
Create known scenarios.

1366
00:57:33,080 --> 00:57:34,520
A standard request.

1367
00:57:34,520 --> 00:57:35,520
An exception.

1368
00:57:35,520 --> 00:57:36,520
A rejected approval.

1369
00:57:36,520 --> 00:57:37,760
A delayed response.

1370
00:57:37,760 --> 00:57:39,600
A record with missing information.

1371
00:57:39,600 --> 00:57:40,920
That's what both paths do.

1372
00:57:40,920 --> 00:57:41,920
Compare the result.

1373
00:57:41,920 --> 00:57:43,720
Did dynamics receive the same outcome?

1374
00:57:43,720 --> 00:57:45,760
Did the right person receive the right message?

1375
00:57:45,760 --> 00:57:48,240
Did the external system get the correct data?

1376
00:57:48,240 --> 00:57:50,480
Did the exception root behavior as expected?

1377
00:57:50,480 --> 00:57:55,400
This parallel period matters because it exposes the details nobody remembered to document.

1378
00:57:55,400 --> 00:57:58,560
Maybe the old plug-in normalized a value before sending it.

1379
00:57:58,560 --> 00:58:00,760
Maybe it skipped a specific record type.

1380
00:58:00,760 --> 00:58:04,240
Maybe it handled an integration timeout in a way the team only notices under load.

1381
00:58:04,240 --> 00:58:05,640
Those discoveries are useful.

1382
00:58:05,640 --> 00:58:07,480
They do not mean the migration failed.

1383
00:58:07,480 --> 00:58:11,360
They mean the team found the real process before retiring the old automation.

1384
00:58:11,360 --> 00:58:12,760
Keep the comparison controlled.

1385
00:58:12,760 --> 00:58:17,100
You don't want both systems creating duplicate tasks or sending duplicate approvals to real

1386
00:58:17,100 --> 00:58:18,100
users.

1387
00:58:18,100 --> 00:58:18,940
Use test records.

1388
00:58:18,940 --> 00:58:20,100
Use a test queue.

1389
00:58:20,100 --> 00:58:21,440
Use a dedicated mailbox.

1390
00:58:21,440 --> 00:58:22,440
Where needed?

1391
00:58:22,440 --> 00:58:25,160
Configure one path to observe without performing the live action.

1392
00:58:25,160 --> 00:58:26,240
The aim is proof.

1393
00:58:26,240 --> 00:58:27,960
Not disruption.

1394
00:58:27,960 --> 00:58:32,000
When the new process behaves correctly, release it as a managed package.

1395
00:58:32,000 --> 00:58:35,680
Move the tested solution into production with the right configuration mapped for that

1396
00:58:35,680 --> 00:58:36,680
environment.

1397
00:58:36,680 --> 00:58:40,080
Once the release, no which version entered production, then monitor the runs.

1398
00:58:40,080 --> 00:58:41,080
Watch failures.

1399
00:58:41,080 --> 00:58:42,080
Watch retries.

1400
00:58:42,080 --> 00:58:43,080
Watch approval delays.

1401
00:58:43,080 --> 00:58:45,200
Check the records created or updated by the flow.

1402
00:58:45,200 --> 00:58:47,120
Talk to the people who use the process.

1403
00:58:47,120 --> 00:58:48,880
Technical success is not enough.

1404
00:58:48,880 --> 00:58:54,160
If the seller receives a confusing message or an approver, lacks the context to decide.

1405
00:58:54,160 --> 00:58:57,440
Only retire the old code when the replacement has earned that decision.

1406
00:58:57,440 --> 00:58:59,480
Not when the flow first saves successfully.

1407
00:58:59,480 --> 00:59:01,000
Not when the first test passes.

1408
00:59:01,000 --> 00:59:03,320
Retire it after the production process works.

1409
00:59:03,320 --> 00:59:04,720
The team can operate it.

1410
00:59:04,720 --> 00:59:06,640
And the business owner accepts the result.

1411
00:59:06,640 --> 00:59:08,520
Then remove the old path deliberately.

1412
00:59:08,520 --> 00:59:09,760
Document the retirement.

1413
00:59:09,760 --> 00:59:11,960
Confirm that no integration still depends on it.

1414
00:59:11,960 --> 00:59:14,040
Otherwise, you risk running two sources of truth.

1415
00:59:14,040 --> 00:59:16,720
This approach moves carefully without becoming slow.

1416
00:59:16,720 --> 00:59:18,200
You start where change hurts.

1417
00:59:18,200 --> 00:59:19,560
You build with the right structure.

1418
00:59:19,560 --> 00:59:21,360
You test against the actual behavior.

1419
00:59:21,360 --> 00:59:22,440
Then you release with evidence.

1420
00:59:22,440 --> 00:59:25,880
But low code can create its own mess when teams skip those disciplines.

1421
00:59:25,880 --> 00:59:27,680
The team model, business owns intent.

1422
00:59:27,680 --> 00:59:29,240
IT owns guardrails.

1423
00:59:29,240 --> 00:59:31,160
The process owner owns the intent.

1424
00:59:31,160 --> 00:59:32,920
Not the flow, not the connector.

1425
00:59:32,920 --> 00:59:33,920
The intent.

1426
00:59:33,920 --> 00:59:37,960
Design what outcome the process needs to produce along with the rules and the exceptions.

1427
00:59:37,960 --> 00:59:41,040
When an approval route changes, the process owner decides why.

1428
00:59:41,040 --> 00:59:44,560
They confirm the policy if an account type should skip a review.

1429
00:59:44,560 --> 00:59:47,800
And when an escalation needs a new recipient, they own that decision.

1430
00:59:47,800 --> 00:59:49,120
This changes the conversation.

1431
00:59:49,120 --> 00:59:51,560
Instead of telling IT, build what we asked for.

1432
00:59:51,560 --> 00:59:54,520
The business takes responsibility for what the process should do.

1433
00:59:54,520 --> 00:59:57,120
That responsibility cannot sit inside a technical backlog.

1434
00:59:57,120 --> 01:00:00,920
The backlog can implement a request, but it cannot decide whether the request still

1435
01:00:00,920 --> 01:00:01,920
makes business sense.

1436
01:00:01,920 --> 01:00:04,840
So makers take that intent and turn it into automation.

1437
01:00:04,840 --> 01:00:09,000
They build within an approved environment using approved connectors, following the delivery

1438
01:00:09,000 --> 01:00:10,520
path for their type of work.

1439
01:00:10,520 --> 01:00:12,480
That doesn't turn every maker into a developer.

1440
01:00:12,480 --> 01:00:13,960
It gives them a clear place to work.

1441
01:00:13,960 --> 01:00:16,160
A low-risk team process can move quickly.

1442
01:00:16,160 --> 01:00:18,280
A production process follows a stronger path.

1443
01:00:18,280 --> 01:00:20,800
The maker doesn't need to guess which rules apply.

1444
01:00:20,800 --> 01:00:23,160
The operating model already answers that.

1445
01:00:23,160 --> 01:00:25,120
IT owns the guardrails around the work.

1446
01:00:25,120 --> 01:00:26,120
Identity.

1447
01:00:26,120 --> 01:00:27,120
Data policies.

1448
01:00:27,120 --> 01:00:28,120
Release discipline.

1449
01:00:28,120 --> 01:00:29,120
Monitoring.

1450
01:00:29,120 --> 01:00:30,120
Support routes.

1451
01:00:30,120 --> 01:00:33,000
They stay with IT because they cross individual processes.

1452
01:00:33,000 --> 01:00:37,320
So one team might build an approval flow, another builds a service escalation, and a third

1453
01:00:37,320 --> 01:00:39,120
automates finance notifications.

1454
01:00:39,120 --> 01:00:40,720
Each team knows its own outcome.

1455
01:00:40,720 --> 01:00:42,640
It sees the shared platform underneath.

1456
01:00:42,640 --> 01:00:46,360
Which identities run unattended work, which connectors can work with customer data.

1457
01:00:46,360 --> 01:00:48,320
How do solutions move into production?

1458
01:00:48,320 --> 01:00:49,680
Who sees a failed run?

1459
01:00:49,680 --> 01:00:52,000
Where does a maker go when a connection breaks?

1460
01:00:52,000 --> 01:00:55,200
Those are platform questions, and they meet consistent answers.

1461
01:00:55,200 --> 01:00:58,280
Without that consistency, every team creates its own approach.

1462
01:00:58,280 --> 01:01:02,640
One process uses a personal account, while another uses an un-reviewed shared login.

1463
01:01:02,640 --> 01:01:06,160
One team tests changes another at its production directly.

1464
01:01:06,160 --> 01:01:09,120
One flow sends failure alerts, another fails quietly.

1465
01:01:09,120 --> 01:01:13,040
The automation may work today, but the organization cannot operate it as a system.

1466
01:01:13,040 --> 01:01:14,360
I'd prevent that drift.

1467
01:01:14,360 --> 01:01:18,560
Not by taking every build away from the business, but by defining the safe path before the business

1468
01:01:18,560 --> 01:01:19,560
needs it.

1469
01:01:19,560 --> 01:01:20,560
Developers still matter.

1470
01:01:20,560 --> 01:01:22,360
They matter at the true code boundary.

1471
01:01:22,360 --> 01:01:27,040
A developer handles work that needs controlled server-side execution, heavy processing, specialist

1472
01:01:27,040 --> 01:01:30,880
integration work, or reusable components beyond what a flow should carry.

1473
01:01:30,880 --> 01:01:31,960
That is not a fallback rule.

1474
01:01:31,960 --> 01:01:33,400
It is a focused rule.

1475
01:01:33,400 --> 01:01:37,280
Developers should not spend weeks turning ordinary routing rules into hidden code.

1476
01:01:37,280 --> 01:01:41,400
Their time belongs where code gives the organization something the platform cannot provide

1477
01:01:41,400 --> 01:01:42,400
cleanly.

1478
01:01:42,400 --> 01:01:43,880
A narrow real-time validation.

1479
01:01:43,880 --> 01:01:45,720
A performance-sensitive operation.

1480
01:01:45,720 --> 01:01:48,760
A reusable component needed across several processes.

1481
01:01:48,760 --> 01:01:50,600
A complex integration contract.

1482
01:01:50,600 --> 01:01:52,400
That division improves both sides.

1483
01:01:52,400 --> 01:01:56,000
The business stops waiting for developers to change ordinary process rules.

1484
01:01:56,000 --> 01:01:59,680
The developer stops becoming the default owner of every small automation request.

1485
01:01:59,680 --> 01:02:03,160
And I'd stop trying to govern work through approval meetings alone.

1486
01:02:03,160 --> 01:02:04,600
Review should follow risk.

1487
01:02:04,600 --> 01:02:06,120
Not job title.

1488
01:02:06,120 --> 01:02:08,880
A business maker can build a safe internal process.

1489
01:02:08,880 --> 01:02:11,840
A professional developer can create a risky integration.

1490
01:02:11,840 --> 01:02:13,440
Neither title tells you enough.

1491
01:02:13,440 --> 01:02:16,720
Look at the data, the process impact, and the identity involved.

1492
01:02:16,720 --> 01:02:17,720
Check the systems.

1493
01:02:17,720 --> 01:02:19,960
And consider what happens if the automation fails.

1494
01:02:19,960 --> 01:02:23,920
A reminder flow for one team needs a different review from a process that updates customer

1495
01:02:23,920 --> 01:02:25,960
records and triggers financial approval.

1496
01:02:25,960 --> 01:02:27,800
The maker's title does not change that.

1497
01:02:27,800 --> 01:02:29,480
The risk does.

1498
01:02:29,480 --> 01:02:32,320
This is the team model behind scalable automation.

1499
01:02:32,320 --> 01:02:33,760
Business owns what should happen.

1500
01:02:33,760 --> 01:02:36,320
Makeers build the process within the defined boundaries.

1501
01:02:36,320 --> 01:02:38,560
It keeps the platform safe and operable.

1502
01:02:38,560 --> 01:02:41,160
Developers take the technical work that genuinely needs code.

1503
01:02:41,160 --> 01:02:44,920
Then review follows the effect of the automation, not the person who created it.

1504
01:02:44,920 --> 01:02:47,400
That model changes the executive decision too.

1505
01:02:47,400 --> 01:02:50,320
Because the question is no longer whether to fund more custom development.

1506
01:02:50,320 --> 01:02:54,800
It is whether the organization wants automation capacity to remain trapped inside a developer

1507
01:02:54,800 --> 01:02:55,800
queue.

1508
01:02:55,800 --> 01:02:57,800
A 90 day reset for dynamics automation.

1509
01:02:57,800 --> 01:02:59,200
Don't start with the platform rebuild.

1510
01:02:59,200 --> 01:03:01,080
Start with 30 days of visibility.

1511
01:03:01,080 --> 01:03:02,600
Find the automation already running.

1512
01:03:02,600 --> 01:03:06,760
List the plugins, scripts, flows, classic workflows, and integrations.

1513
01:03:06,760 --> 01:03:07,760
Then identify the gaps.

1514
01:03:07,760 --> 01:03:08,760
Who owns each process?

1515
01:03:08,760 --> 01:03:09,760
Who can support it?

1516
01:03:09,760 --> 01:03:10,920
Which identity runs it?

1517
01:03:10,920 --> 01:03:12,680
Which automation has no current business owner?

1518
01:03:12,680 --> 01:03:14,040
You're not fixing everything yet.

1519
01:03:14,040 --> 01:03:16,960
You're finding the work your organization already depends on.

1520
01:03:16,960 --> 01:03:18,920
That list changes the conversation quickly.

1521
01:03:18,920 --> 01:03:21,760
Some automations will have clear owners and stable behavior.

1522
01:03:21,760 --> 01:03:23,360
Others will reveal a different problem.

1523
01:03:23,360 --> 01:03:27,280
Nobody knows why they run, who can change them safely or where the credentials sit.

1524
01:03:27,280 --> 01:03:28,280
That is your starting point.

1525
01:03:28,280 --> 01:03:31,120
In the next 30 days, define the operating rules.

1526
01:03:31,120 --> 01:03:34,640
Create the environments needed for development, testing, and production work.

1527
01:03:34,640 --> 01:03:35,840
Set the solution structure.

1528
01:03:35,840 --> 01:03:40,040
Define which connectors can work together through DLP policy and how unattended automation

1529
01:03:40,040 --> 01:03:41,200
uses identity.

1530
01:03:41,200 --> 01:03:45,160
Then decide what belongs in a personal environment, what belongs to a team, and what qualifies

1531
01:03:45,160 --> 01:03:46,840
as production automation.

1532
01:03:46,840 --> 01:03:48,160
Keep these rules short.

1533
01:03:48,160 --> 01:03:49,160
People need to use them.

1534
01:03:49,160 --> 01:03:50,720
A maker should know where to build.

1535
01:03:50,720 --> 01:03:53,280
The process owner needs to know who approves a change.

1536
01:03:53,280 --> 01:03:56,360
And the support team should know where to look when something fails.

1537
01:03:56,360 --> 01:03:57,480
The aim isn't paperwork.

1538
01:03:57,480 --> 01:04:00,560
It's removing uncertainty before more automation appears.

1539
01:04:00,560 --> 01:04:03,760
In the final 30 days, prove the model with one process.

1540
01:04:03,760 --> 01:04:06,720
Pick a process that changes often and crosses systems.

1541
01:04:06,720 --> 01:04:10,600
Maybe dynamic triggers an approval, teams notifies the right person and the outcome returns

1542
01:04:10,600 --> 01:04:11,600
to the record.

1543
01:04:11,600 --> 01:04:15,720
Build it in a solution with the right connection references and controlled configuration.

1544
01:04:15,720 --> 01:04:19,120
If you've tested it before production, then release it through the path you defined.

1545
01:04:19,120 --> 01:04:22,680
That one process gives the team evidence, not a slight deck evidence.

1546
01:04:22,680 --> 01:04:26,720
You can see whether releases move faster, failure ownership is clear, and approvals wait

1547
01:04:26,720 --> 01:04:27,720
less time.

1548
01:04:27,720 --> 01:04:32,080
And you can see how much support effort disappears when the process has a visible structure.

1549
01:04:32,080 --> 01:04:33,240
Measure those things.

1550
01:04:33,240 --> 01:04:34,240
Release time.

1551
01:04:34,240 --> 01:04:35,240
Failure rate.

1552
01:04:35,240 --> 01:04:36,240
Approval delay.

1553
01:04:36,240 --> 01:04:37,240
Support effort.

1554
01:04:37,240 --> 01:04:38,560
Don't measure activity.

1555
01:04:38,560 --> 01:04:42,160
Measure whether the operating model reduces friction around real work.

1556
01:04:42,160 --> 01:04:45,120
Then publish the decision framework before demand expands.

1557
01:04:45,120 --> 01:04:49,480
People will ask whether their process needs a flow, a low-code plug-in custom code, or

1558
01:04:49,480 --> 01:04:50,480
no change at all.

1559
01:04:50,480 --> 01:04:54,120
Give them a clear route before every new request becomes another architecture debate.

1560
01:04:54,120 --> 01:04:56,120
Because demand will expand, it always does.

1561
01:04:56,120 --> 01:04:59,720
Once people see that dynamics can trigger work across the tools they already use, they

1562
01:04:59,720 --> 01:05:01,400
won't stop asking for automation.

1563
01:05:01,400 --> 01:05:05,320
The question is whether those requests enter a system with ownership, boundaries, and clear

1564
01:05:05,320 --> 01:05:06,320
choices.

1565
01:05:06,320 --> 01:05:09,240
Or whether they become the next collection of hidden dependencies.

1566
01:05:09,240 --> 01:05:10,280
That is the structural shift.