Apple Podcasts
Spotify
Youtube Music
Spreaker
Podchaser
Amazon Music
Automation is evolving—and fast. What used to be simple task execution is now becoming something far more powerful: systems that can observe themselves, make decisions, and recover without human intervention. In this episode, we explore what it really means to engineer self-healing automation, and why telemetry is the missing piece that turns static workflows into adaptive systems.
THE SHIFT FROM STATIC AUTOMATION TO INTELLIGENT SYSTEMS
For years, automation has been built on deterministic logic: predefined triggers, fixed conditions, and predictable outcomes. But modern environments—especially cloud, SaaS, and distributed systems—are anything but predictable. Conditions change constantly, signals are noisy, and dependencies are complex. This is where traditional automation starts to break down. Instead of rigid workflows, we now need systems that can interpret signals dynamically. Systems that don’t just execute, but decide. This shift marks the transition from automation as a tool… to automation as a system.
WHY TRADITIONAL AUTOMATION FAILS AT SCALE
Most automation fails not because the idea is wrong—but because the design is incomplete. Static workflows assume:
- Stable environments
- Predictable inputs
- Linear cause-and-effect relationships
- Distributed services
- Rapid configuration changes
- Uncertain and evolving conditions
ENTER THE TELEMETRY-DRIVEN LOGIC LAYER
Telemetry is everywhere—logs, metrics, traces, events. But collecting data isn’t enough. The real value comes from interpreting that data and turning it into decisions. That’s where the Telemetry-Driven Logic Layer comes in. This layer sits between raw signals and automated actions. It acts as the brain of your automation system:
- It ingests telemetry from multiple sources
- It applies context and correlation
- It evaluates conditions dynamically
- It determines the best course of action
FROM “IF THIS THEN THAT” TO “OBSERVE, DECIDE, ACT”
Traditional automation follows a simple model:
IF condition → THEN action Self-healing automation follows a more advanced loop:
OBSERVE → ANALYZE → DECIDE → ACT → LEARN
This feedback loop is what enables systems to evolve over time. They don’t just respond—they improve.
BUILDING SELF-HEALING SYSTEMS IN PRACTICE
So how do you actually design for self-healing? It starts with three foundational components:
- OBSERVABILITY (THE INPUT LAYER)
Collect meaningful telemetry across systems—metrics, logs, user signals, and performance data. The goal is not more data, but better signals. - DECISION ENGINE (THE LOGIC LAYER)
This is where intelligence lives. You define rules, thresholds, and models that interpret telemetry and determine actions. - AUTOMATED EXECUTION (THE ACTION LAYER)
Actions are triggered based on decisions—remediation, scaling, policy enforcement, or workflow adjustments.
REAL-WORLD USE CASES OF SELF-HEALING AUTOMATION
This isn’t just theory—it’s already happening. Imagine:
- A system detects abnormal API latency and automatically reroutes traffic
- A security anomaly triggers adaptive access policies in real time
- A failed workflow self-corrects based on historical success patterns
- A resource spike initiates scaling actions before users are impacted
THE ROLE OF FEEDBACK LOOPS IN MODERN AUTOMATION
The real breakthrough isn’t automation—it’s feedback. Without feedback, automation is blind.
With feedback, it becomes intelligent. Telemetry provides that feedback by:
- Validating whether actions were successful
- Identifying unintended consequences
- Continuously refining decision logic
DESIGN PATTERNS FOR TELEMETRY-DRIVEN AUTOMATION
To implement this effectively, consider these patterns:
- EVENT-DRIVEN ARCHITECTURE
React to real-time signals instead of scheduled triggers - CORRELATION OVER ISOLATION
Combine multiple signals to reduce false positives - GRADUAL AUTOMATION MATURITY
Start with assisted automation, then move to full autonomy - HUMAN-IN-THE-LOOP DESIGN
Keep humans involved where decisions carry risk
Even advanced automation can fail if poorly designed. Watch out for:
- Over-automation without context
- Poor signal quality leading to bad decisions
- Lack of visibility into automated actions
- No rollback or safety mechanisms
THE FUTURE: AUTONOMOUS OPERATIONS
We’re moving toward a world where systems manage themselves. Not entirely without humans—but with far less manual intervention. This is the foundation of:
- Autonomous IT operations
- Resilient cloud architectures
- Intelligent enterprise platforms
WHAT YOU’LL LEARN
- How to move from static workflows to adaptive automation systems
- The architecture and purpose of a telemetry-driven logic layer
- Why feedback loops are critical for resilience and scalability
- Practical approaches to building self-healing automation
- Real-world scenarios where this model delivers immediate value
- Automation without telemetry is reactive—automation with telemetry is intelligent
- Self-healing systems reduce downtime, effort, and operational complexity
- The future of automation is not scripts—it’s systems that learn and adapt
The complexity of modern systems is growing faster than our ability to manage them manually. If your automation can’t adapt, it will eventually fail. The question is no longer if you need smarter automation—but how soon you can implement it.
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
1
00:00:00,000 --> 00:00:02,720
Most flows automate tasks, but they don't manage themselves.
2
00:00:02,720 --> 00:00:03,640
That sounds small.
3
00:00:03,640 --> 00:00:05,880
It isn't, because the moment a trigger fails,
4
00:00:05,880 --> 00:00:08,200
most teams fall back into the same old model.
5
00:00:08,200 --> 00:00:10,760
Someone gets an alert, someone checks run history,
6
00:00:10,760 --> 00:00:12,120
someone patches the symptom,
7
00:00:12,120 --> 00:00:14,600
and then everyone pretends the system is healthy again.
8
00:00:14,600 --> 00:00:16,480
The automation runs until the next break.
9
00:00:16,480 --> 00:00:17,800
That model doesn't scale.
10
00:00:17,800 --> 00:00:19,880
The problem usually isn't missing features,
11
00:00:19,880 --> 00:00:21,420
and it usually isn't bad makers.
12
00:00:21,420 --> 00:00:22,360
It's maintenance debt.
13
00:00:22,360 --> 00:00:25,240
Every new flow adds one more thing that needs watching,
14
00:00:25,240 --> 00:00:26,880
one more dependency that can drift
15
00:00:26,880 --> 00:00:30,120
and one more silent point of failure inside the tenant.
16
00:00:30,120 --> 00:00:33,120
So the shift is this, stop treating failure as an interruption,
17
00:00:33,120 --> 00:00:34,020
treat it as input.
18
00:00:34,020 --> 00:00:36,440
In this episode, we're building a recursive feedback loop
19
00:00:36,440 --> 00:00:38,560
inside power automate with telemetry,
20
00:00:38,560 --> 00:00:40,640
decision logic, and controlled self correction,
21
00:00:40,640 --> 00:00:42,560
because without that layer, your flow estate
22
00:00:42,560 --> 00:00:43,560
doesn't get smarter.
23
00:00:43,560 --> 00:00:45,240
It just gets bigger and weaker.
24
00:00:45,240 --> 00:00:46,400
Before we build the pattern,
25
00:00:46,400 --> 00:00:49,080
we need to get clear on what actually breaks.
26
00:00:49,080 --> 00:00:50,600
The death of manual debugging.
27
00:00:50,600 --> 00:00:52,440
In most environments, manual maintenance
28
00:00:52,440 --> 00:00:55,320
is still the real operating model, not the flow diagram,
29
00:00:55,320 --> 00:00:57,840
not the governance deck, not the nice automation roadmap,
30
00:00:57,840 --> 00:00:59,280
what actually keeps the estate running
31
00:00:59,280 --> 00:01:01,080
is a human being checking failed runs,
32
00:01:01,080 --> 00:01:03,320
retrygaring actions, updating connections,
33
00:01:03,320 --> 00:01:06,040
cleaning up edge cases, and doing weekend repair work
34
00:01:06,040 --> 00:01:08,440
that nobody planned for but everyone expects.
35
00:01:08,440 --> 00:01:10,360
So you don't really have autonomous automation.
36
00:01:10,360 --> 00:01:13,440
You have automated work sitting on top of manual supervision.
37
00:01:13,440 --> 00:01:15,840
And that gap matters because the flow looks stable
38
00:01:15,840 --> 00:01:18,040
right up until a connector changes behavior,
39
00:01:18,040 --> 00:01:20,520
a token expires, a payload grows,
40
00:01:20,520 --> 00:01:22,960
or a dependency upstream starts returning
41
00:01:22,960 --> 00:01:25,120
something slightly different than yesterday,
42
00:01:25,120 --> 00:01:27,320
which is exactly when the automated process
43
00:01:27,320 --> 00:01:29,040
turns back into operations labor.
44
00:01:29,040 --> 00:01:30,480
This is where most teams get trapped.
45
00:01:30,480 --> 00:01:32,280
They build more flows to save time,
46
00:01:32,280 --> 00:01:34,920
but each flow adds another maintenance surface,
47
00:01:34,920 --> 00:01:37,920
another owner, another trigger, another hidden assumption.
48
00:01:37,920 --> 00:01:40,360
And because those assumptions are spread across approvals,
49
00:01:40,360 --> 00:01:43,720
provisioning, reporting, access requests, finance handoffs,
50
00:01:43,720 --> 00:01:47,280
or compliance tasks, a single broken business critical flow
51
00:01:47,280 --> 00:01:49,560
can store much more than one transaction.
52
00:01:49,560 --> 00:01:51,960
It can freeze a whole chain of work that depends on it.
53
00:01:51,960 --> 00:01:53,760
That is why break-fix thinking fails.
54
00:01:53,760 --> 00:01:56,240
Reactive maintenance keeps teams stuck in high labor
55
00:01:56,240 --> 00:01:57,240
and downtime costs.
56
00:01:57,240 --> 00:01:59,720
In broader maintenance research, predictive approaches
57
00:01:59,720 --> 00:02:05,120
reduce overall costs by 25% to 30% and cut breakdowns by 70%
58
00:02:05,120 --> 00:02:06,800
compared with reactive models.
59
00:02:06,800 --> 00:02:09,040
The point isn't that a power-automate flow
60
00:02:09,040 --> 00:02:10,920
behaves like a factory machine.
61
00:02:10,920 --> 00:02:13,800
The point is the operating model is the same.
62
00:02:13,800 --> 00:02:16,080
If you wait for failure and then respond manually,
63
00:02:16,080 --> 00:02:18,280
the labor compounds and the downtime spreads
64
00:02:18,280 --> 00:02:19,680
and downtime isn't abstract.
65
00:02:19,680 --> 00:02:21,520
In some sectors, unplanned downtime
66
00:02:21,520 --> 00:02:24,040
averages $260,000 per hour.
67
00:02:24,040 --> 00:02:25,680
You don't need to import that number directly
68
00:02:25,680 --> 00:02:29,120
into every M365 workflow, but you do need to understand
69
00:02:29,120 --> 00:02:30,360
the pattern behind it.
70
00:02:30,360 --> 00:02:32,520
When a business critical automation stalls,
71
00:02:32,520 --> 00:02:34,400
the cost isn't the failed run.
72
00:02:34,400 --> 00:02:36,480
The cost is the approvals that stop moving,
73
00:02:36,480 --> 00:02:37,800
the accounts that don't get provisioned,
74
00:02:37,800 --> 00:02:38,880
the reports that don't land,
75
00:02:38,880 --> 00:02:40,800
and the people who now need to investigate by hand.
76
00:02:40,800 --> 00:02:43,440
So maintenance debt isn't a pile of isolated bugs.
77
00:02:43,440 --> 00:02:44,440
It's system debt.
78
00:02:44,440 --> 00:02:46,880
It compounds through dependencies, ownership gaps,
79
00:02:46,880 --> 00:02:49,200
undocumented logic, and repeated manual intervention.
80
00:02:49,200 --> 00:02:52,040
That's why teams feel slower even while they keep automating more.
81
00:02:52,040 --> 00:02:54,160
Now, basic try-catch logic still matters.
82
00:02:54,160 --> 00:02:57,280
Scopes, retries, fallback branches, all of that helps locally.
83
00:02:57,280 --> 00:02:59,200
You should use it, but local error handling
84
00:02:59,200 --> 00:03:00,440
doesn't change the model.
85
00:03:00,440 --> 00:03:03,080
It just makes one flow less fragile in one moment.
86
00:03:03,080 --> 00:03:04,960
It doesn't create memory across failures,
87
00:03:04,960 --> 00:03:06,800
and it doesn't turn exceptions into signals
88
00:03:06,800 --> 00:03:08,440
the wider system can learn from.
89
00:03:08,440 --> 00:03:10,200
So if the model is wrong, the next layer
90
00:03:10,200 --> 00:03:11,480
can't be more error emails.
91
00:03:11,480 --> 00:03:13,480
It has to be something that watches patterns,
92
00:03:13,480 --> 00:03:15,760
classifies drift, and changes behavior
93
00:03:15,760 --> 00:03:17,840
before people get pulled back in.
94
00:03:17,840 --> 00:03:19,600
The telemetry-driven logic layer.
95
00:03:19,600 --> 00:03:20,880
So what replaces that model?
96
00:03:20,880 --> 00:03:23,240
A telemetry-driven logic layer, not another dashboard,
97
00:03:23,240 --> 00:03:24,920
not a prettier failure report.
98
00:03:24,920 --> 00:03:27,720
A logic layer is a control plane inside your flow estate
99
00:03:27,720 --> 00:03:30,800
that watches signals, classifies what kind of failure is happening,
100
00:03:30,800 --> 00:03:33,240
and then changes behavior based on what it sees.
101
00:03:33,240 --> 00:03:35,000
The flow still does the business job,
102
00:03:35,000 --> 00:03:36,560
but now something else supervises
103
00:03:36,560 --> 00:03:38,800
how that job behaves when conditions shift.
104
00:03:38,800 --> 00:03:41,640
That separation matters more than most people think.
105
00:03:41,640 --> 00:03:43,720
Business logic should answer one question.
106
00:03:43,720 --> 00:03:45,120
What work needs to happen?
107
00:03:45,120 --> 00:03:47,320
Approved the request, create the account,
108
00:03:47,320 --> 00:03:49,440
send the report, update the list.
109
00:03:49,440 --> 00:03:51,600
Supervisory logic answers a different question,
110
00:03:51,600 --> 00:03:53,800
and it's the one that usually gets ignored.
111
00:03:53,800 --> 00:03:55,760
What should happen when the environment stops
112
00:03:55,760 --> 00:03:58,120
matching the assumptions this flow depends on?
113
00:03:58,120 --> 00:04:00,000
Especially when the same failure pattern starts
114
00:04:00,000 --> 00:04:02,400
repeating across runs, owners, and connectors.
115
00:04:02,400 --> 00:04:05,160
If you mix those two jobs inside one pile of actions,
116
00:04:05,160 --> 00:04:07,680
the flow turns into its own confused operator.
117
00:04:07,680 --> 00:04:09,920
It tries to process the business task,
118
00:04:09,920 --> 00:04:12,320
diagnose the failure, decide policy, log history,
119
00:04:12,320 --> 00:04:13,760
and recover all at once.
120
00:04:13,760 --> 00:04:15,000
That's where things get messy fast,
121
00:04:15,000 --> 00:04:17,640
because the flow is no longer just doing work.
122
00:04:17,640 --> 00:04:18,920
It's guessing about itself.
123
00:04:18,920 --> 00:04:20,240
The better model is explicit.
124
00:04:20,240 --> 00:04:21,720
You define a desired state.
125
00:04:21,720 --> 00:04:23,720
Then the system checks for drift from that state.
126
00:04:23,720 --> 00:04:25,480
It decides what kind of drift it is.
127
00:04:25,480 --> 00:04:26,800
It applies a response.
128
00:04:26,800 --> 00:04:27,880
Then it records the outcome
129
00:04:27,880 --> 00:04:29,560
so the next decision can improve.
130
00:04:29,560 --> 00:04:32,440
Desired state detection, decision, remediation, learning.
131
00:04:32,440 --> 00:04:33,440
That's the loop.
132
00:04:33,440 --> 00:04:35,240
And if you remember nothing else, remember this.
133
00:04:35,240 --> 00:04:37,080
The remediation is not the smart part.
134
00:04:37,080 --> 00:04:38,120
The decision is.
135
00:04:38,120 --> 00:04:39,560
Now what feeds that decision?
136
00:04:39,560 --> 00:04:40,320
Telemetry.
137
00:04:40,320 --> 00:04:42,200
And not all telemetry is equally useful.
138
00:04:42,200 --> 00:04:44,480
A lot of teams collect whatever the platform already gives them
139
00:04:44,480 --> 00:04:46,040
and call that observability.
140
00:04:46,040 --> 00:04:47,880
But decision-grade telemetry is narrower.
141
00:04:47,880 --> 00:04:50,360
It captures what helps the system choose a safe next action.
142
00:04:50,360 --> 00:04:51,600
Run history matters, yes.
143
00:04:51,600 --> 00:04:53,280
Duration drift matters because of flow
144
00:04:53,280 --> 00:04:55,280
that suddenly takes three times longer,
145
00:04:55,280 --> 00:04:57,840
maybe nearing a timeout or dependency issue.
146
00:04:57,840 --> 00:05:00,600
Retry patterns matter because repeated retries
147
00:05:00,600 --> 00:05:03,640
often point to a class of problem, not a one-off glitch.
148
00:05:03,640 --> 00:05:05,560
Connector failures matter, throttling matters,
149
00:05:05,560 --> 00:05:08,080
payload size matters, owner context matters,
150
00:05:08,080 --> 00:05:10,200
business criticality matters.
151
00:05:10,200 --> 00:05:13,040
This clicked for me when I stopped asking what failed.
152
00:05:13,040 --> 00:05:14,120
And started asking,
153
00:05:14,120 --> 00:05:17,280
what does the system need to know to respond differently next time?
154
00:05:17,280 --> 00:05:18,720
That's a different design question.
155
00:05:18,720 --> 00:05:20,920
One is descriptive, the other is operational.
156
00:05:20,920 --> 00:05:23,440
So there are really two kinds of data in a flow estate.
157
00:05:23,440 --> 00:05:26,120
First, normal flow data, inputs, outputs, records,
158
00:05:26,120 --> 00:05:28,160
message bodies, form responses, created items.
159
00:05:28,160 --> 00:05:30,400
That's the content the process is moving around.
160
00:05:30,400 --> 00:05:33,200
Then decision-grade telemetry, error class,
161
00:05:33,200 --> 00:05:35,720
execution duration trends, dependency health,
162
00:05:35,720 --> 00:05:38,080
remediation history, confidence level,
163
00:05:38,080 --> 00:05:41,000
allowed fallback paths, escalation thresholds.
164
00:05:41,000 --> 00:05:43,120
That data doesn't exist to complete the task.
165
00:05:43,120 --> 00:05:44,920
It exists to supervise the task.
166
00:05:44,920 --> 00:05:45,800
And this is the shift.
167
00:05:45,800 --> 00:05:48,360
Governance usually lives in documents, standards,
168
00:05:48,360 --> 00:05:50,520
naming rules and review meetings.
169
00:05:50,520 --> 00:05:52,000
Useful but static.
170
00:05:52,000 --> 00:05:53,400
The telemetry driven logic layer
171
00:05:53,400 --> 00:05:54,960
moves governance into runtime.
172
00:05:54,960 --> 00:05:56,520
It asks, in the moment of failure,
173
00:05:56,520 --> 00:05:58,760
what policy applies here, what action is allowed,
174
00:05:58,760 --> 00:05:59,880
what confidence do we have,
175
00:05:59,880 --> 00:06:01,480
and when should a human step in?
176
00:06:01,480 --> 00:06:03,520
That's governance doing work, not governance,
177
00:06:03,520 --> 00:06:04,720
waiting in a folder.
178
00:06:04,720 --> 00:06:06,200
Which means the logic layer is not
179
00:06:06,200 --> 00:06:08,560
some extra technical decoration around your flows.
180
00:06:08,560 --> 00:06:11,920
It's the part that turns automation from task execution
181
00:06:11,920 --> 00:06:13,960
into supervised adaptation.
182
00:06:13,960 --> 00:06:15,640
Without it, every failure still depends
183
00:06:15,640 --> 00:06:16,960
on people reading symptoms.
184
00:06:16,960 --> 00:06:19,760
With it, the estate starts classifying its own conditions,
185
00:06:19,760 --> 00:06:21,240
marrowing its own uncertainty,
186
00:06:21,240 --> 00:06:22,600
and acting within defined limits.
187
00:06:22,600 --> 00:06:24,000
And once that model is in place,
188
00:06:24,000 --> 00:06:26,360
the next question isn't whether self-correction is possible.
189
00:06:26,360 --> 00:06:28,800
The next question is, what this loop needs to store?
190
00:06:28,800 --> 00:06:32,240
So its decisions stay grounded instead of improvising.
191
00:06:32,240 --> 00:06:34,000
Building the telemetry nerve center.
192
00:06:34,000 --> 00:06:36,360
Once you accept that the flow needs supervision,
193
00:06:36,360 --> 00:06:39,560
you need one place where every exception turns into structured evidence.
194
00:06:39,560 --> 00:06:40,560
That's the nerve center.
195
00:06:40,560 --> 00:06:43,400
Not a dumping ground for logs, not a giant archive nobody reads.
196
00:06:43,400 --> 00:06:45,680
A small, usable system that records enough context
197
00:06:45,680 --> 00:06:47,800
for the next decision to be better than the last one.
198
00:06:47,800 --> 00:06:50,400
Because if failure stayed trapped inside run history,
199
00:06:50,400 --> 00:06:51,480
they stay local.
200
00:06:51,480 --> 00:06:53,480
They don't accumulate into pattern knowledge.
201
00:06:53,480 --> 00:06:55,080
So the first job is the data model.
202
00:06:55,080 --> 00:06:57,040
For each event, capture the flow ID,
203
00:06:57,040 --> 00:06:58,840
the environment, and the trigger type.
204
00:06:58,840 --> 00:07:01,000
Then at the dependency involved, the error class,
205
00:07:01,000 --> 00:07:02,520
how often that class has appeared,
206
00:07:02,520 --> 00:07:04,120
the last known successful state,
207
00:07:04,120 --> 00:07:05,800
the remediation that was attempted,
208
00:07:05,800 --> 00:07:07,720
and the outcome of that remediation.
209
00:07:07,720 --> 00:07:09,160
I would also add a confidence score,
210
00:07:09,160 --> 00:07:12,680
because a retry after a time out is not the same thing as rewriting a path,
211
00:07:12,680 --> 00:07:15,680
changing a destination, or re-routing a business step.
212
00:07:15,680 --> 00:07:18,800
One action can run safely with high confidence.
213
00:07:18,800 --> 00:07:21,760
Another should stop instantly unless a policy allows it.
214
00:07:21,760 --> 00:07:23,920
That confidence field matters because without it,
215
00:07:23,920 --> 00:07:25,960
every exception looks equally actionable,
216
00:07:25,960 --> 00:07:28,400
and that's how noisy systems become reckless systems,
217
00:07:28,400 --> 00:07:30,800
especially when the same connector behaves differently
218
00:07:30,800 --> 00:07:33,680
across environments, owners, or payload sizes.
219
00:07:33,680 --> 00:07:36,960
And your logic layer needs to know whether it's seeing a known pattern
220
00:07:36,960 --> 00:07:38,440
or just a symptom.
221
00:07:38,440 --> 00:07:40,000
Keep the model lean.
222
00:07:40,000 --> 00:07:41,600
More logs don't create better judgment.
223
00:07:41,600 --> 00:07:44,440
They create more storage, more noise, and more false certainty.
224
00:07:44,440 --> 00:07:46,720
The system doesn't need every output body forever.
225
00:07:46,720 --> 00:07:49,800
It needs the minimum evidence required to classify the issue,
226
00:07:49,800 --> 00:07:51,480
compare it to previous events,
227
00:07:51,480 --> 00:07:54,320
and choose from a narrow set of approved responses.
228
00:07:54,320 --> 00:07:56,160
That's the shortcut nobody teaches.
229
00:07:56,160 --> 00:07:58,120
Useful telemetry is selective.
230
00:07:58,120 --> 00:08:00,200
Storage depends on maturity.
231
00:08:00,200 --> 00:08:03,040
If you're early, a SharePoint list or database table can be enough,
232
00:08:03,040 --> 00:08:06,920
because the point at first is consistency, not elegance.
233
00:08:06,920 --> 00:08:09,560
If you need more scale or tighter operational control,
234
00:08:09,560 --> 00:08:12,040
Azure table storage can work for structured records.
235
00:08:12,040 --> 00:08:14,720
If your estate is larger and you need deeper search, analytics,
236
00:08:14,720 --> 00:08:18,400
or broader observability, then log analytics or application insights
237
00:08:18,400 --> 00:08:19,840
starts to make more sense.
238
00:08:19,840 --> 00:08:21,560
The decision isn't about prestige.
239
00:08:21,560 --> 00:08:23,320
It's about volume query needs retention
240
00:08:23,320 --> 00:08:25,120
and who needs access to the evidence.
241
00:08:25,120 --> 00:08:27,680
I wouldn't bury all of this inside every flow.
242
00:08:27,680 --> 00:08:30,880
Use child flows for the shared supervisory functions instead.
243
00:08:30,880 --> 00:08:32,680
One child flow classifies the error.
244
00:08:32,680 --> 00:08:34,160
Another enriches the context.
245
00:08:34,160 --> 00:08:35,880
Another decides an allowed action.
246
00:08:35,880 --> 00:08:37,120
Another records the result.
247
00:08:37,120 --> 00:08:39,600
That way the business flow stays focused on business work,
248
00:08:39,600 --> 00:08:42,240
while the supervisory layer stays reusable, testable,
249
00:08:42,240 --> 00:08:45,000
and easier to update when your classification logic changes.
250
00:08:45,000 --> 00:08:47,400
If you hard-code all of that into each production flow,
251
00:08:47,400 --> 00:08:50,040
every improvement becomes a manual retrofit project.
252
00:08:50,040 --> 00:08:51,920
You also need policy context in the record,
253
00:08:51,920 --> 00:08:54,400
not just technical context, who owns this flow.
254
00:08:54,400 --> 00:08:56,200
What SLA tier is attached to it?
255
00:08:56,200 --> 00:08:57,840
Does it touch a sensitive data path?
256
00:08:57,840 --> 00:09:00,000
What actions are allowed to run automatically
257
00:09:00,000 --> 00:09:02,560
and what escalation rule applies if confidence drops
258
00:09:02,560 --> 00:09:04,200
or repeat frequency rises?
259
00:09:04,200 --> 00:09:06,120
That's where things change because a timeout
260
00:09:06,120 --> 00:09:08,520
on a low-risk notification flow and a timeout
261
00:09:08,520 --> 00:09:11,720
on an identity workflow should not trigger the same response,
262
00:09:11,720 --> 00:09:14,040
even if the connector error code looks similar.
263
00:09:14,040 --> 00:09:16,160
And one level deeper, the nerve center should separate
264
00:09:16,160 --> 00:09:18,040
event signals from state signals.
265
00:09:18,040 --> 00:09:20,760
An event signal tells you what just happened, a run failed,
266
00:09:20,760 --> 00:09:23,520
a retry succeeded, a token refresh path worked.
267
00:09:23,520 --> 00:09:24,480
Those are moments.
268
00:09:24,480 --> 00:09:27,000
A state signal tells you what has drifted over time,
269
00:09:27,000 --> 00:09:29,920
and that sentence matters because many failures are only obvious
270
00:09:29,920 --> 00:09:33,120
once you compare current behavior with prior healthy behavior.
271
00:09:33,120 --> 00:09:36,040
Looking at slower trends like repeated duration increases,
272
00:09:36,040 --> 00:09:38,240
rising retry counts, or a growing gap
273
00:09:38,240 --> 00:09:40,160
since the last clean success.
274
00:09:40,160 --> 00:09:42,560
If you mix those together, the system reacts to noise.
275
00:09:42,560 --> 00:09:44,720
If you separate them, the system starts seeing drift.
276
00:09:44,720 --> 00:09:46,480
So the nerve center is really a filter.
277
00:09:46,480 --> 00:09:49,000
It turns scattered incidents into comparable records,
278
00:09:49,000 --> 00:09:51,560
and it turns raw failure into operational memory.
279
00:09:51,560 --> 00:09:53,760
That is what gives the recursive loop something solid
280
00:09:53,760 --> 00:09:56,120
to work with because once the telemetry is structured,
281
00:09:56,120 --> 00:09:58,240
the next challenge isn't collecting more.
282
00:09:58,240 --> 00:10:00,520
It's designing how the system re-enters the problem,
283
00:10:00,520 --> 00:10:03,520
changes its behavior, and stops before self-correction
284
00:10:03,520 --> 00:10:05,920
becomes self-inflicted damage.
285
00:10:05,920 --> 00:10:08,440
Engineering the recursive loop, now the loop itself.
286
00:10:08,440 --> 00:10:10,240
When I say recursion in power automate,
287
00:10:10,240 --> 00:10:12,400
I don't mean some elegant computer science demo
288
00:10:12,400 --> 00:10:14,480
where a flow keeps calling itself forever.
289
00:10:14,480 --> 00:10:17,440
In this environment recursion has to mean control re-entry.
290
00:10:17,440 --> 00:10:19,600
The system hits a problem, records what happened,
291
00:10:19,600 --> 00:10:22,080
chooses a narrower next move, and then re-enters
292
00:10:22,080 --> 00:10:24,040
with more context than it had before.
293
00:10:24,040 --> 00:10:27,160
If that second pass doesn't reduce uncertainty or change the state,
294
00:10:27,160 --> 00:10:28,120
it shouldn't run.
295
00:10:28,120 --> 00:10:29,080
That's the rule.
296
00:10:29,080 --> 00:10:31,080
Every pass must do one of two things.
297
00:10:31,080 --> 00:10:32,720
It must either learn something new,
298
00:10:32,720 --> 00:10:34,400
or it must alter the conditions enough
299
00:10:34,400 --> 00:10:36,440
that the next result could reasonably differ.
300
00:10:36,440 --> 00:10:38,680
If all you're doing is repeating the same action
301
00:10:38,680 --> 00:10:41,080
against the same broken dependency with the same parameters,
302
00:10:41,080 --> 00:10:42,520
you don't have a feedback loop.
303
00:10:42,520 --> 00:10:44,680
You have automated panic, and that burns actions,
304
00:10:44,680 --> 00:10:46,880
clutter, telemetry, and drags humans back in later
305
00:10:46,880 --> 00:10:48,200
to clean up the noise.
306
00:10:48,200 --> 00:10:51,160
Power automate gives you a few practical ways to build this.
307
00:10:51,160 --> 00:10:52,880
The simplest is a child flow pattern.
308
00:10:52,880 --> 00:10:56,320
A parent flow detects the issue, passes context to a child flow,
309
00:10:56,320 --> 00:10:58,200
and the child handles classification,
310
00:10:58,200 --> 00:10:59,480
decisioning, and response.
311
00:10:59,480 --> 00:11:01,800
That works well because direct self-invocation
312
00:11:01,800 --> 00:11:02,800
isn't the model here.
313
00:11:02,800 --> 00:11:03,840
You want separation.
314
00:11:03,840 --> 00:11:07,320
Another option is do, until where the loop stops only
315
00:11:07,320 --> 00:11:09,000
when a condition flips, but that condition has
316
00:11:09,000 --> 00:11:11,480
to be tied to state improvement, not hope.
317
00:11:11,480 --> 00:11:13,440
Then you have queue-like hand-off patterns,
318
00:11:13,440 --> 00:11:15,760
where one pass records the issue, and another process
319
00:11:15,760 --> 00:11:18,640
picks it up later after a delay, or after some dependency
320
00:11:18,640 --> 00:11:19,680
window changes.
321
00:11:19,680 --> 00:11:21,600
And then there are bounded retry windows,
322
00:11:21,600 --> 00:11:24,280
where retries exist, but inside a tighter decision frame
323
00:11:24,280 --> 00:11:26,000
instead of brute force repetition.
324
00:11:26,000 --> 00:11:28,440
The thing most people miss is workload reduction.
325
00:11:28,440 --> 00:11:29,720
A healthy recursive design should
326
00:11:29,720 --> 00:11:31,400
shrink the problem each time.
327
00:11:31,400 --> 00:11:34,760
Smaller batch, narrower scope, better classification,
328
00:11:34,760 --> 00:11:37,280
more specific fallback, maybe the first pass tries
329
00:11:37,280 --> 00:11:39,640
the primary connector, the second delays,
330
00:11:39,640 --> 00:11:42,560
the third reduces payload size, and the fourth isolates
331
00:11:42,560 --> 00:11:44,720
one bad item from a larger set.
332
00:11:44,720 --> 00:11:46,560
That is a recursive loop doing useful work
333
00:11:46,560 --> 00:11:49,200
because each pass changes the search space.
334
00:11:49,200 --> 00:11:51,800
It doesn't just keep knocking on the same locked door.
335
00:11:51,800 --> 00:11:53,600
So the decision tree needs to be explicit.
336
00:11:53,600 --> 00:11:55,640
Start with retry, but only when the signal
337
00:11:55,640 --> 00:11:57,280
suggests a temporary issue.
338
00:11:57,280 --> 00:11:58,720
Move to delay when the pattern looks
339
00:11:58,720 --> 00:12:01,000
like throttling or transient service pressure.
340
00:12:01,000 --> 00:12:03,360
Switch connector path, if your architecture allows
341
00:12:03,360 --> 00:12:04,440
an alternate route.
342
00:12:04,440 --> 00:12:06,560
Reduce batch size if payload or volume appears
343
00:12:06,560 --> 00:12:07,480
to be the cause.
344
00:12:07,480 --> 00:12:09,760
Try a token refresh path when the problem points
345
00:12:09,760 --> 00:12:11,200
to authentication drift.
346
00:12:11,200 --> 00:12:14,320
Re-root to a fallback process, when continuity matters more
347
00:12:14,320 --> 00:12:15,360
than elegance.
348
00:12:15,360 --> 00:12:18,160
Escalate to a human when the system reaches the edge
349
00:12:18,160 --> 00:12:19,800
of its confidence or authority.
350
00:12:19,800 --> 00:12:22,680
That confidence gate is where beginners and serious operators
351
00:12:22,680 --> 00:12:23,400
split.
352
00:12:23,400 --> 00:12:26,600
A low risk action with a known pattern can run automatically.
353
00:12:26,600 --> 00:12:29,320
A medium risk action might need a policy check first
354
00:12:29,320 --> 00:12:31,560
because the system knows a possible remedy,
355
00:12:31,560 --> 00:12:33,840
but also knows the blast radius isn't trivial.
356
00:12:33,840 --> 00:12:36,480
A high risk action should stop and ask for human approval,
357
00:12:36,480 --> 00:12:38,920
especially if it touches identity, permission, sensitive
358
00:12:38,920 --> 00:12:40,920
records, or downstream financial impact.
359
00:12:40,920 --> 00:12:42,600
The loop is not there to prove autonomy.
360
00:12:42,600 --> 00:12:44,400
It's there to preserve continuity safely.
361
00:12:44,400 --> 00:12:46,840
So you need breaks, set max attempts,
362
00:12:46,840 --> 00:12:49,080
add cooling periods, suppress duplicates,
363
00:12:49,080 --> 00:12:51,640
so the same issue doesn't keep spawning parallel remediation
364
00:12:51,640 --> 00:12:52,360
paths.
365
00:12:52,360 --> 00:12:54,960
Isolate poison items, so one bad record
366
00:12:54,960 --> 00:12:56,960
doesn't contaminate the whole run.
367
00:12:56,960 --> 00:12:58,680
And make termination conditions obvious
368
00:12:58,680 --> 00:13:01,600
because hidden loop endings are how maintenance logic turns
369
00:13:01,600 --> 00:13:03,240
into its own support incident.
370
00:13:03,240 --> 00:13:06,120
Most recursive designs fail for one reason.
371
00:13:06,120 --> 00:13:08,280
They repeat action without improving diagnosis.
372
00:13:08,280 --> 00:13:11,320
The system sees an error, retries it, waits, retries again,
373
00:13:11,320 --> 00:13:13,920
and logs each failure as if more volume somehow counts
374
00:13:13,920 --> 00:13:14,840
as more intelligence.
375
00:13:14,840 --> 00:13:15,600
It doesn't.
376
00:13:15,600 --> 00:13:17,800
The reason recursion works is not repetition.
377
00:13:17,800 --> 00:13:20,200
It's guided reentry based on stronger evidence.
378
00:13:20,200 --> 00:13:22,520
That's why the telemetry layer and the recursive loop
379
00:13:22,520 --> 00:13:24,160
have to stay tightly connected.
380
00:13:24,160 --> 00:13:25,160
One gather signals.
381
00:13:25,160 --> 00:13:27,800
The other converts those signals into narrower decisions.
382
00:13:27,800 --> 00:13:29,960
And once a loop can take action like that,
383
00:13:29,960 --> 00:13:33,760
a new problem shows up fast, cost, safety, and platform
384
00:13:33,760 --> 00:13:37,800
limits, cost, scale, and platform trade-offs.
385
00:13:37,800 --> 00:13:40,040
Now we need to talk about the part people usually skip,
386
00:13:40,040 --> 00:13:41,920
because self-healing sounds elegant right up
387
00:13:41,920 --> 00:13:45,040
until the bill arrives, and the flow count starts climbing.
388
00:13:45,040 --> 00:13:47,160
A recursive design doesn't just add intelligence.
389
00:13:47,160 --> 00:13:49,240
It adds activity, more checks, more branches,
390
00:13:49,240 --> 00:13:51,760
more child flow calls, more rights to telemetry storage,
391
00:13:51,760 --> 00:13:52,960
more connector traffic.
392
00:13:52,960 --> 00:13:54,680
So if you design this badly, the system
393
00:13:54,680 --> 00:13:56,800
can spend half its time supervising itself
394
00:13:56,800 --> 00:13:58,120
and still not improve outcomes.
395
00:13:58,120 --> 00:13:59,400
That's where the architecture starts
396
00:13:59,400 --> 00:14:01,000
fighting its own economics.
397
00:14:01,000 --> 00:14:02,800
Power automate is strong when the workload
398
00:14:02,800 --> 00:14:05,280
lives close to business process context.
399
00:14:05,280 --> 00:14:06,360
Approvals.
400
00:14:06,360 --> 00:14:07,640
Notifications.
401
00:14:07,640 --> 00:14:08,840
SharePoint changes.
402
00:14:08,840 --> 00:14:10,080
Teams actions.
403
00:14:10,080 --> 00:14:12,160
Microsoft 365 signals.
404
00:14:12,160 --> 00:14:13,480
Short decision chains.
405
00:14:13,480 --> 00:14:14,640
Human touch points.
406
00:14:14,640 --> 00:14:17,280
That is the environment where supervised recursion works well,
407
00:14:17,280 --> 00:14:18,920
because the flow can detect an issue.
408
00:14:18,920 --> 00:14:19,960
Classified.
409
00:14:19,960 --> 00:14:22,800
Take one bounded action and either recover or escalate.
410
00:14:22,800 --> 00:14:25,320
The platform is good at that kind of operational rhythm,
411
00:14:25,320 --> 00:14:27,480
especially when the remediation path is narrow,
412
00:14:27,480 --> 00:14:29,920
and the business owner is still part of the model.
413
00:14:29,920 --> 00:14:32,680
But the limits show up fast when the recursion gets deep.
414
00:14:32,680 --> 00:14:34,680
Loops over large data sets slow down.
415
00:14:34,680 --> 00:14:36,720
Child flow chains get harder to trace.
416
00:14:36,720 --> 00:14:37,960
Action counts rise.
417
00:14:37,960 --> 00:14:39,240
Branches multiply.
418
00:14:39,240 --> 00:14:41,440
A design that felt smart at 10 runs per day
419
00:14:41,440 --> 00:14:43,480
starts feeling heavy at 10,000, especially
420
00:14:43,480 --> 00:14:46,720
when every pass adds logging, retry logic, policy checks,
421
00:14:46,720 --> 00:14:48,640
and fallback evaluation.
422
00:14:48,640 --> 00:14:51,320
And when all of that remains packed inside one giant flow,
423
00:14:51,320 --> 00:14:52,960
maintenance doesn't disappear.
424
00:14:52,960 --> 00:14:55,120
It just moves to a more complicated place.
425
00:14:55,120 --> 00:14:57,840
So there is a threshold where the right answer is not
426
00:14:57,840 --> 00:15:00,040
add more logic in power automate.
427
00:15:00,040 --> 00:15:03,000
The right answer is to externalize part of the pattern.
428
00:15:03,000 --> 00:15:05,880
If you need heavy state handling, wider observability,
429
00:15:05,880 --> 00:15:08,360
high volume recursion, queue-driven processing,
430
00:15:08,360 --> 00:15:10,200
or orchestration across multiple systems
431
00:15:10,200 --> 00:15:12,200
with stronger runtime control, then you
432
00:15:12,200 --> 00:15:13,920
should look beyond one low-code flow
433
00:15:13,920 --> 00:15:15,520
carrying the entire burden.
434
00:15:15,520 --> 00:15:18,080
This is exactly where Azure Logic app starts to matter,
435
00:15:18,080 --> 00:15:20,360
because the decision isn't about prestige.
436
00:15:20,360 --> 00:15:22,360
It's about fit logic apps gives you a different cost
437
00:15:22,360 --> 00:15:23,160
and scale model.
438
00:15:23,160 --> 00:15:25,560
In consumption, every extra action matters.
439
00:15:25,560 --> 00:15:27,840
In standard, fixed compute can make more sense
440
00:15:27,840 --> 00:15:30,240
once the volume is predictable and the recursive workload
441
00:15:30,240 --> 00:15:31,680
is large enough because you're no longer
442
00:15:31,680 --> 00:15:33,640
thinking only in per-action terms.
443
00:15:33,640 --> 00:15:35,680
You're thinking in throughput, hosting model,
444
00:15:35,680 --> 00:15:37,680
and how much supervised re-logic you can run
445
00:15:37,680 --> 00:15:40,880
without turning every improvement into a direct action text.
446
00:15:40,880 --> 00:15:42,120
Research on logic apps.
447
00:15:42,120 --> 00:15:44,680
Standard points to fixed compute becoming the better deal
448
00:15:44,680 --> 00:15:46,360
when action volume gets high enough, which
449
00:15:46,360 --> 00:15:49,080
is the kind of shift enterprise teams need to understand
450
00:15:49,080 --> 00:15:52,120
before they build the wrong control layer in the wrong place.
451
00:15:52,120 --> 00:15:54,160
That doesn't mean power automate is the wrong tool.
452
00:15:54,160 --> 00:15:56,560
It means power automate is the right tool
453
00:15:56,560 --> 00:15:59,200
for supervised recursion close to the business process,
454
00:15:59,200 --> 00:16:02,200
and the wrong tool for every kind of recursive ambition.
455
00:16:02,200 --> 00:16:03,840
That distinction saves a lot of pain.
456
00:16:03,840 --> 00:16:06,120
You can keep the business flow in power automate,
457
00:16:06,120 --> 00:16:08,840
keep the decision surface clear, and move deeper orchestration
458
00:16:08,840 --> 00:16:11,320
or observability to logic apps as your storage
459
00:16:11,320 --> 00:16:14,040
or another service when the recursion starts acting
460
00:16:14,040 --> 00:16:17,120
more like platform engineering than workflow automation.
461
00:16:17,120 --> 00:16:19,280
And cost can't be judged by license lines alone.
462
00:16:19,280 --> 00:16:22,520
If a better supervisory layer cuts manual intervention,
463
00:16:22,520 --> 00:16:25,360
shortens recovery, and prevents repeated incidents,
464
00:16:25,360 --> 00:16:27,960
then the cost discussion has to include a void at downtime,
465
00:16:27,960 --> 00:16:30,800
a void at support effort, and a void at rework.
466
00:16:30,800 --> 00:16:32,480
Teams often compare platform pricing
467
00:16:32,480 --> 00:16:34,920
and ignore the labor that are quietly burning every week
468
00:16:34,920 --> 00:16:37,080
inside manual triage after hours fixes
469
00:16:37,080 --> 00:16:38,960
and repeated business interruptions.
470
00:16:38,960 --> 00:16:40,440
That comparison is incomplete.
471
00:16:40,440 --> 00:16:42,480
There is also a governance cost to bad design.
472
00:16:42,480 --> 00:16:43,920
Telemetry has to live somewhere.
473
00:16:43,920 --> 00:16:45,560
Someone has to own retention.
474
00:16:45,560 --> 00:16:47,160
Someone has to control access.
475
00:16:47,160 --> 00:16:49,200
Someone has to decide what evidence must be kept,
476
00:16:49,200 --> 00:16:51,480
what can be deleted, and how the system proves
477
00:16:51,480 --> 00:16:52,440
what it changed.
478
00:16:52,440 --> 00:16:55,400
If you collect too much, storage and review costs rise.
479
00:16:55,400 --> 00:16:57,240
If you collect too little, the loop loses trust
480
00:16:57,240 --> 00:16:59,080
because nobody can verify why it acted.
481
00:16:59,080 --> 00:17:00,680
So scale is never just compute.
482
00:17:00,680 --> 00:17:02,960
Scale is storage, auditability, ownership,
483
00:17:02,960 --> 00:17:04,960
and the ability to explain behavior later.
484
00:17:04,960 --> 00:17:05,920
And this is the line.
485
00:17:05,920 --> 00:17:08,760
A self-healing pattern either becomes a safe operating model
486
00:17:08,760 --> 00:17:11,560
with clear boundaries or it becomes a noisy automation layer
487
00:17:11,560 --> 00:17:13,640
that multiplies actions, hides risk,
488
00:17:13,640 --> 00:17:15,640
and leaves people cleaning up after a system
489
00:17:15,640 --> 00:17:17,960
that looks clever on paper.
490
00:17:17,960 --> 00:17:20,480
Governance, AI, and autonomy with breaks.
491
00:17:20,480 --> 00:17:23,080
That brings us to the part that decides whether this architecture
492
00:17:23,080 --> 00:17:24,800
belongs in production at all.
493
00:17:24,800 --> 00:17:27,640
Self-healing without governance doesn't reduce drift.
494
00:17:27,640 --> 00:17:29,840
It accelerates it.
495
00:17:29,840 --> 00:17:32,120
The moment a system can react to failure on its own,
496
00:17:32,120 --> 00:17:33,600
you've given it operational influence,
497
00:17:33,600 --> 00:17:35,880
maybe narrow influence, maybe tightly scoped,
498
00:17:35,880 --> 00:17:36,720
but still influence.
499
00:17:36,720 --> 00:17:39,200
And if the permissions are wrong, the data boundaries are weak
500
00:17:39,200 --> 00:17:40,640
or the remediation rules are vague,
501
00:17:40,640 --> 00:17:43,800
the system can apply the wrong fix faster than a human ever could.
502
00:17:43,800 --> 00:17:44,840
That's not resilience.
503
00:17:44,840 --> 00:17:46,600
That's speed without judgment.
504
00:17:46,600 --> 00:17:50,080
AI raises the stakes because bad structure gets exposed faster.
505
00:17:50,080 --> 00:17:52,240
Copilot, agents, and automated assistance
506
00:17:52,240 --> 00:17:54,440
all depend on data access, identity context,
507
00:17:54,440 --> 00:17:55,720
and policy clarity.
508
00:17:55,720 --> 00:17:57,320
If those foundations are weak,
509
00:17:57,320 --> 00:17:59,000
then adding a recursive healing loop
510
00:17:59,000 --> 00:18:00,200
doesn't solve the problem.
511
00:18:00,200 --> 00:18:03,280
It just creates another actor inside the same broken model.
512
00:18:03,280 --> 00:18:05,400
Research around Microsoft 365 governance
513
00:18:05,400 --> 00:18:07,000
keeps pointing to the same issue.
514
00:18:07,000 --> 00:18:08,760
Manual reviews can't keep pace.
515
00:18:08,760 --> 00:18:12,440
And AI surfaces oversharing and misconfiguration almost immediately.
516
00:18:12,440 --> 00:18:14,400
So the loop has to respect the same boundaries
517
00:18:14,400 --> 00:18:16,120
your human operators should respect,
518
00:18:16,120 --> 00:18:17,200
only more consistently.
519
00:18:17,200 --> 00:18:18,680
Start with risk tiers.
520
00:18:18,680 --> 00:18:20,520
Low risk fixes can run automatically.
521
00:18:20,520 --> 00:18:22,440
A bounded retry, a timed delay,
522
00:18:22,440 --> 00:18:25,400
a known fallback on a non-sensitive notification flow.
523
00:18:25,400 --> 00:18:27,560
Fine, medium risk fixes need policy checks.
524
00:18:27,560 --> 00:18:29,440
Maybe the flow wants to switch path,
525
00:18:29,440 --> 00:18:32,320
alter batch size, or move to a fallback connector.
526
00:18:32,320 --> 00:18:35,160
That can still work, but only inside approved conditions.
527
00:18:35,160 --> 00:18:37,000
High risk fixes need a person.
528
00:18:37,000 --> 00:18:39,840
If the remediation touches identities, permissions,
529
00:18:39,840 --> 00:18:41,520
records with sensitive data,
530
00:18:41,520 --> 00:18:42,960
or decisions with business impact,
531
00:18:42,960 --> 00:18:44,840
the system should pause and ask.
532
00:18:44,840 --> 00:18:46,480
Not because the technology is weak,
533
00:18:46,480 --> 00:18:48,520
but because accountability still matters.
534
00:18:48,520 --> 00:18:50,240
Every remediation also needs evidence.
535
00:18:50,240 --> 00:18:51,160
Why did it act?
536
00:18:51,160 --> 00:18:52,320
What signal triggered it?
537
00:18:52,320 --> 00:18:53,560
What policy allowed it?
538
00:18:53,560 --> 00:18:54,400
What changed?
539
00:18:54,400 --> 00:18:56,640
Who owns the outcome if it goes wrong?
540
00:18:56,640 --> 00:18:59,800
Those questions can't be answered with the automation decided.
541
00:18:59,800 --> 00:19:01,680
That sentence is useless in an audit,
542
00:19:01,680 --> 00:19:03,680
useless in a post-incident review,
543
00:19:03,680 --> 00:19:05,520
and useless when trust starts falling
544
00:19:05,520 --> 00:19:06,880
across the platform team.
545
00:19:06,880 --> 00:19:08,800
So the model is autonomy with breaks,
546
00:19:08,800 --> 00:19:11,160
not full autonomy, not automation theater,
547
00:19:11,160 --> 00:19:12,440
controlled autonomy,
548
00:19:12,440 --> 00:19:14,600
where the system can act inside known boundaries,
549
00:19:14,600 --> 00:19:16,200
stop at confidence limits,
550
00:19:16,200 --> 00:19:19,040
and produce a record each time it crosses from observation
551
00:19:19,040 --> 00:19:20,480
into intervention.
552
00:19:20,480 --> 00:19:22,640
That record is what makes the architecture governable,
553
00:19:22,640 --> 00:19:24,960
because now the loop isn't just doing something.
554
00:19:24,960 --> 00:19:26,480
It's doing something explainable.
555
00:19:26,480 --> 00:19:27,880
Once you put those breaks in place,
556
00:19:27,880 --> 00:19:30,400
the design stops being a clever pattern for specialists
557
00:19:30,400 --> 00:19:32,120
and starts looking like an operating model
558
00:19:32,120 --> 00:19:34,240
other teams can actually adopt.
559
00:19:34,240 --> 00:19:35,560
Implementation path.
560
00:19:35,560 --> 00:19:37,960
From brittle flow to self-healing estate,
561
00:19:37,960 --> 00:19:40,080
start with one painful production flow,
562
00:19:40,080 --> 00:19:42,600
add telemetry first, then add classification,
563
00:19:42,600 --> 00:19:44,560
then allow one safe remediation path
564
00:19:44,560 --> 00:19:46,720
that everybody agrees on ahead of time.
565
00:19:46,720 --> 00:19:48,200
Measure mean time to repair,
566
00:19:48,200 --> 00:19:51,280
repeat failures, manual touches, and false positives.
567
00:19:51,280 --> 00:19:52,720
If the pattern lowers support effort
568
00:19:52,720 --> 00:19:55,000
without creating confusion, reuse it,
569
00:19:55,000 --> 00:19:57,120
expand by pattern, not by enthusiasm,
570
00:19:57,120 --> 00:19:59,320
because the final shift isn't really about tooling,
571
00:19:59,320 --> 00:20:00,400
it's about role.
572
00:20:00,400 --> 00:20:01,560
So the shift is simple.
573
00:20:01,560 --> 00:20:03,400
Stop treating failures as tickets
574
00:20:03,400 --> 00:20:05,200
and start treating them as training data
575
00:20:05,200 --> 00:20:08,200
for the logic layer that supervises your flows at runtime.
576
00:20:08,200 --> 00:20:09,640
Pick one production flow this month,
577
00:20:09,640 --> 00:20:12,240
map the signal, the decision, the safe remediation,
578
00:20:12,240 --> 00:20:14,520
and the point where a human still needs to step in.
579
00:20:14,520 --> 00:20:15,840
That's where the new model starts.
580
00:20:15,840 --> 00:20:17,920
If this changed how you think about automation,
581
00:20:17,920 --> 00:20:20,680
subscribe to the M365FM podcast.
582
00:20:20,680 --> 00:20:22,280
Leave a review if you want more of this
583
00:20:22,280 --> 00:20:23,240
and connect with me,
584
00:20:23,240 --> 00:20:25,320
Mirko Peters, on LinkedIn with the next system
585
00:20:25,320 --> 00:20:26,600
you want me to break down.
00:00:00,000 --> 00:00:02,720
Most flows automate tasks, but they don't manage themselves.
2
00:00:02,720 --> 00:00:03,640
That sounds small.
3
00:00:03,640 --> 00:00:05,880
It isn't, because the moment a trigger fails,
4
00:00:05,880 --> 00:00:08,200
most teams fall back into the same old model.
5
00:00:08,200 --> 00:00:10,760
Someone gets an alert, someone checks run history,
6
00:00:10,760 --> 00:00:12,120
someone patches the symptom,
7
00:00:12,120 --> 00:00:14,600
and then everyone pretends the system is healthy again.
8
00:00:14,600 --> 00:00:16,480
The automation runs until the next break.
9
00:00:16,480 --> 00:00:17,800
That model doesn't scale.
10
00:00:17,800 --> 00:00:19,880
The problem usually isn't missing features,
11
00:00:19,880 --> 00:00:21,420
and it usually isn't bad makers.
12
00:00:21,420 --> 00:00:22,360
It's maintenance debt.
13
00:00:22,360 --> 00:00:25,240
Every new flow adds one more thing that needs watching,
14
00:00:25,240 --> 00:00:26,880
one more dependency that can drift
15
00:00:26,880 --> 00:00:30,120
and one more silent point of failure inside the tenant.
16
00:00:30,120 --> 00:00:33,120
So the shift is this, stop treating failure as an interruption,
17
00:00:33,120 --> 00:00:34,020
treat it as input.
18
00:00:34,020 --> 00:00:36,440
In this episode, we're building a recursive feedback loop
19
00:00:36,440 --> 00:00:38,560
inside power automate with telemetry,
20
00:00:38,560 --> 00:00:40,640
decision logic, and controlled self correction,
21
00:00:40,640 --> 00:00:42,560
because without that layer, your flow estate
22
00:00:42,560 --> 00:00:43,560
doesn't get smarter.
23
00:00:43,560 --> 00:00:45,240
It just gets bigger and weaker.
24
00:00:45,240 --> 00:00:46,400
Before we build the pattern,
25
00:00:46,400 --> 00:00:49,080
we need to get clear on what actually breaks.
26
00:00:49,080 --> 00:00:50,600
The death of manual debugging.
27
00:00:50,600 --> 00:00:52,440
In most environments, manual maintenance
28
00:00:52,440 --> 00:00:55,320
is still the real operating model, not the flow diagram,
29
00:00:55,320 --> 00:00:57,840
not the governance deck, not the nice automation roadmap,
30
00:00:57,840 --> 00:00:59,280
what actually keeps the estate running
31
00:00:59,280 --> 00:01:01,080
is a human being checking failed runs,
32
00:01:01,080 --> 00:01:03,320
retrygaring actions, updating connections,
33
00:01:03,320 --> 00:01:06,040
cleaning up edge cases, and doing weekend repair work
34
00:01:06,040 --> 00:01:08,440
that nobody planned for but everyone expects.
35
00:01:08,440 --> 00:01:10,360
So you don't really have autonomous automation.
36
00:01:10,360 --> 00:01:13,440
You have automated work sitting on top of manual supervision.
37
00:01:13,440 --> 00:01:15,840
And that gap matters because the flow looks stable
38
00:01:15,840 --> 00:01:18,040
right up until a connector changes behavior,
39
00:01:18,040 --> 00:01:20,520
a token expires, a payload grows,
40
00:01:20,520 --> 00:01:22,960
or a dependency upstream starts returning
41
00:01:22,960 --> 00:01:25,120
something slightly different than yesterday,
42
00:01:25,120 --> 00:01:27,320
which is exactly when the automated process
43
00:01:27,320 --> 00:01:29,040
turns back into operations labor.
44
00:01:29,040 --> 00:01:30,480
This is where most teams get trapped.
45
00:01:30,480 --> 00:01:32,280
They build more flows to save time,
46
00:01:32,280 --> 00:01:34,920
but each flow adds another maintenance surface,
47
00:01:34,920 --> 00:01:37,920
another owner, another trigger, another hidden assumption.
48
00:01:37,920 --> 00:01:40,360
And because those assumptions are spread across approvals,
49
00:01:40,360 --> 00:01:43,720
provisioning, reporting, access requests, finance handoffs,
50
00:01:43,720 --> 00:01:47,280
or compliance tasks, a single broken business critical flow
51
00:01:47,280 --> 00:01:49,560
can store much more than one transaction.
52
00:01:49,560 --> 00:01:51,960
It can freeze a whole chain of work that depends on it.
53
00:01:51,960 --> 00:01:53,760
That is why break-fix thinking fails.
54
00:01:53,760 --> 00:01:56,240
Reactive maintenance keeps teams stuck in high labor
55
00:01:56,240 --> 00:01:57,240
and downtime costs.
56
00:01:57,240 --> 00:01:59,720
In broader maintenance research, predictive approaches
57
00:01:59,720 --> 00:02:05,120
reduce overall costs by 25% to 30% and cut breakdowns by 70%
58
00:02:05,120 --> 00:02:06,800
compared with reactive models.
59
00:02:06,800 --> 00:02:09,040
The point isn't that a power-automate flow
60
00:02:09,040 --> 00:02:10,920
behaves like a factory machine.
61
00:02:10,920 --> 00:02:13,800
The point is the operating model is the same.
62
00:02:13,800 --> 00:02:16,080
If you wait for failure and then respond manually,
63
00:02:16,080 --> 00:02:18,280
the labor compounds and the downtime spreads
64
00:02:18,280 --> 00:02:19,680
and downtime isn't abstract.
65
00:02:19,680 --> 00:02:21,520
In some sectors, unplanned downtime
66
00:02:21,520 --> 00:02:24,040
averages $260,000 per hour.
67
00:02:24,040 --> 00:02:25,680
You don't need to import that number directly
68
00:02:25,680 --> 00:02:29,120
into every M365 workflow, but you do need to understand
69
00:02:29,120 --> 00:02:30,360
the pattern behind it.
70
00:02:30,360 --> 00:02:32,520
When a business critical automation stalls,
71
00:02:32,520 --> 00:02:34,400
the cost isn't the failed run.
72
00:02:34,400 --> 00:02:36,480
The cost is the approvals that stop moving,
73
00:02:36,480 --> 00:02:37,800
the accounts that don't get provisioned,
74
00:02:37,800 --> 00:02:38,880
the reports that don't land,
75
00:02:38,880 --> 00:02:40,800
and the people who now need to investigate by hand.
76
00:02:40,800 --> 00:02:43,440
So maintenance debt isn't a pile of isolated bugs.
77
00:02:43,440 --> 00:02:44,440
It's system debt.
78
00:02:44,440 --> 00:02:46,880
It compounds through dependencies, ownership gaps,
79
00:02:46,880 --> 00:02:49,200
undocumented logic, and repeated manual intervention.
80
00:02:49,200 --> 00:02:52,040
That's why teams feel slower even while they keep automating more.
81
00:02:52,040 --> 00:02:54,160
Now, basic try-catch logic still matters.
82
00:02:54,160 --> 00:02:57,280
Scopes, retries, fallback branches, all of that helps locally.
83
00:02:57,280 --> 00:02:59,200
You should use it, but local error handling
84
00:02:59,200 --> 00:03:00,440
doesn't change the model.
85
00:03:00,440 --> 00:03:03,080
It just makes one flow less fragile in one moment.
86
00:03:03,080 --> 00:03:04,960
It doesn't create memory across failures,
87
00:03:04,960 --> 00:03:06,800
and it doesn't turn exceptions into signals
88
00:03:06,800 --> 00:03:08,440
the wider system can learn from.
89
00:03:08,440 --> 00:03:10,200
So if the model is wrong, the next layer
90
00:03:10,200 --> 00:03:11,480
can't be more error emails.
91
00:03:11,480 --> 00:03:13,480
It has to be something that watches patterns,
92
00:03:13,480 --> 00:03:15,760
classifies drift, and changes behavior
93
00:03:15,760 --> 00:03:17,840
before people get pulled back in.
94
00:03:17,840 --> 00:03:19,600
The telemetry-driven logic layer.
95
00:03:19,600 --> 00:03:20,880
So what replaces that model?
96
00:03:20,880 --> 00:03:23,240
A telemetry-driven logic layer, not another dashboard,
97
00:03:23,240 --> 00:03:24,920
not a prettier failure report.
98
00:03:24,920 --> 00:03:27,720
A logic layer is a control plane inside your flow estate
99
00:03:27,720 --> 00:03:30,800
that watches signals, classifies what kind of failure is happening,
100
00:03:30,800 --> 00:03:33,240
and then changes behavior based on what it sees.
101
00:03:33,240 --> 00:03:35,000
The flow still does the business job,
102
00:03:35,000 --> 00:03:36,560
but now something else supervises
103
00:03:36,560 --> 00:03:38,800
how that job behaves when conditions shift.
104
00:03:38,800 --> 00:03:41,640
That separation matters more than most people think.
105
00:03:41,640 --> 00:03:43,720
Business logic should answer one question.
106
00:03:43,720 --> 00:03:45,120
What work needs to happen?
107
00:03:45,120 --> 00:03:47,320
Approved the request, create the account,
108
00:03:47,320 --> 00:03:49,440
send the report, update the list.
109
00:03:49,440 --> 00:03:51,600
Supervisory logic answers a different question,
110
00:03:51,600 --> 00:03:53,800
and it's the one that usually gets ignored.
111
00:03:53,800 --> 00:03:55,760
What should happen when the environment stops
112
00:03:55,760 --> 00:03:58,120
matching the assumptions this flow depends on?
113
00:03:58,120 --> 00:04:00,000
Especially when the same failure pattern starts
114
00:04:00,000 --> 00:04:02,400
repeating across runs, owners, and connectors.
115
00:04:02,400 --> 00:04:05,160
If you mix those two jobs inside one pile of actions,
116
00:04:05,160 --> 00:04:07,680
the flow turns into its own confused operator.
117
00:04:07,680 --> 00:04:09,920
It tries to process the business task,
118
00:04:09,920 --> 00:04:12,320
diagnose the failure, decide policy, log history,
119
00:04:12,320 --> 00:04:13,760
and recover all at once.
120
00:04:13,760 --> 00:04:15,000
That's where things get messy fast,
121
00:04:15,000 --> 00:04:17,640
because the flow is no longer just doing work.
122
00:04:17,640 --> 00:04:18,920
It's guessing about itself.
123
00:04:18,920 --> 00:04:20,240
The better model is explicit.
124
00:04:20,240 --> 00:04:21,720
You define a desired state.
125
00:04:21,720 --> 00:04:23,720
Then the system checks for drift from that state.
126
00:04:23,720 --> 00:04:25,480
It decides what kind of drift it is.
127
00:04:25,480 --> 00:04:26,800
It applies a response.
128
00:04:26,800 --> 00:04:27,880
Then it records the outcome
129
00:04:27,880 --> 00:04:29,560
so the next decision can improve.
130
00:04:29,560 --> 00:04:32,440
Desired state detection, decision, remediation, learning.
131
00:04:32,440 --> 00:04:33,440
That's the loop.
132
00:04:33,440 --> 00:04:35,240
And if you remember nothing else, remember this.
133
00:04:35,240 --> 00:04:37,080
The remediation is not the smart part.
134
00:04:37,080 --> 00:04:38,120
The decision is.
135
00:04:38,120 --> 00:04:39,560
Now what feeds that decision?
136
00:04:39,560 --> 00:04:40,320
Telemetry.
137
00:04:40,320 --> 00:04:42,200
And not all telemetry is equally useful.
138
00:04:42,200 --> 00:04:44,480
A lot of teams collect whatever the platform already gives them
139
00:04:44,480 --> 00:04:46,040
and call that observability.
140
00:04:46,040 --> 00:04:47,880
But decision-grade telemetry is narrower.
141
00:04:47,880 --> 00:04:50,360
It captures what helps the system choose a safe next action.
142
00:04:50,360 --> 00:04:51,600
Run history matters, yes.
143
00:04:51,600 --> 00:04:53,280
Duration drift matters because of flow
144
00:04:53,280 --> 00:04:55,280
that suddenly takes three times longer,
145
00:04:55,280 --> 00:04:57,840
maybe nearing a timeout or dependency issue.
146
00:04:57,840 --> 00:05:00,600
Retry patterns matter because repeated retries
147
00:05:00,600 --> 00:05:03,640
often point to a class of problem, not a one-off glitch.
148
00:05:03,640 --> 00:05:05,560
Connector failures matter, throttling matters,
149
00:05:05,560 --> 00:05:08,080
payload size matters, owner context matters,
150
00:05:08,080 --> 00:05:10,200
business criticality matters.
151
00:05:10,200 --> 00:05:13,040
This clicked for me when I stopped asking what failed.
152
00:05:13,040 --> 00:05:14,120
And started asking,
153
00:05:14,120 --> 00:05:17,280
what does the system need to know to respond differently next time?
154
00:05:17,280 --> 00:05:18,720
That's a different design question.
155
00:05:18,720 --> 00:05:20,920
One is descriptive, the other is operational.
156
00:05:20,920 --> 00:05:23,440
So there are really two kinds of data in a flow estate.
157
00:05:23,440 --> 00:05:26,120
First, normal flow data, inputs, outputs, records,
158
00:05:26,120 --> 00:05:28,160
message bodies, form responses, created items.
159
00:05:28,160 --> 00:05:30,400
That's the content the process is moving around.
160
00:05:30,400 --> 00:05:33,200
Then decision-grade telemetry, error class,
161
00:05:33,200 --> 00:05:35,720
execution duration trends, dependency health,
162
00:05:35,720 --> 00:05:38,080
remediation history, confidence level,
163
00:05:38,080 --> 00:05:41,000
allowed fallback paths, escalation thresholds.
164
00:05:41,000 --> 00:05:43,120
That data doesn't exist to complete the task.
165
00:05:43,120 --> 00:05:44,920
It exists to supervise the task.
166
00:05:44,920 --> 00:05:45,800
And this is the shift.
167
00:05:45,800 --> 00:05:48,360
Governance usually lives in documents, standards,
168
00:05:48,360 --> 00:05:50,520
naming rules and review meetings.
169
00:05:50,520 --> 00:05:52,000
Useful but static.
170
00:05:52,000 --> 00:05:53,400
The telemetry driven logic layer
171
00:05:53,400 --> 00:05:54,960
moves governance into runtime.
172
00:05:54,960 --> 00:05:56,520
It asks, in the moment of failure,
173
00:05:56,520 --> 00:05:58,760
what policy applies here, what action is allowed,
174
00:05:58,760 --> 00:05:59,880
what confidence do we have,
175
00:05:59,880 --> 00:06:01,480
and when should a human step in?
176
00:06:01,480 --> 00:06:03,520
That's governance doing work, not governance,
177
00:06:03,520 --> 00:06:04,720
waiting in a folder.
178
00:06:04,720 --> 00:06:06,200
Which means the logic layer is not
179
00:06:06,200 --> 00:06:08,560
some extra technical decoration around your flows.
180
00:06:08,560 --> 00:06:11,920
It's the part that turns automation from task execution
181
00:06:11,920 --> 00:06:13,960
into supervised adaptation.
182
00:06:13,960 --> 00:06:15,640
Without it, every failure still depends
183
00:06:15,640 --> 00:06:16,960
on people reading symptoms.
184
00:06:16,960 --> 00:06:19,760
With it, the estate starts classifying its own conditions,
185
00:06:19,760 --> 00:06:21,240
marrowing its own uncertainty,
186
00:06:21,240 --> 00:06:22,600
and acting within defined limits.
187
00:06:22,600 --> 00:06:24,000
And once that model is in place,
188
00:06:24,000 --> 00:06:26,360
the next question isn't whether self-correction is possible.
189
00:06:26,360 --> 00:06:28,800
The next question is, what this loop needs to store?
190
00:06:28,800 --> 00:06:32,240
So its decisions stay grounded instead of improvising.
191
00:06:32,240 --> 00:06:34,000
Building the telemetry nerve center.
192
00:06:34,000 --> 00:06:36,360
Once you accept that the flow needs supervision,
193
00:06:36,360 --> 00:06:39,560
you need one place where every exception turns into structured evidence.
194
00:06:39,560 --> 00:06:40,560
That's the nerve center.
195
00:06:40,560 --> 00:06:43,400
Not a dumping ground for logs, not a giant archive nobody reads.
196
00:06:43,400 --> 00:06:45,680
A small, usable system that records enough context
197
00:06:45,680 --> 00:06:47,800
for the next decision to be better than the last one.
198
00:06:47,800 --> 00:06:50,400
Because if failure stayed trapped inside run history,
199
00:06:50,400 --> 00:06:51,480
they stay local.
200
00:06:51,480 --> 00:06:53,480
They don't accumulate into pattern knowledge.
201
00:06:53,480 --> 00:06:55,080
So the first job is the data model.
202
00:06:55,080 --> 00:06:57,040
For each event, capture the flow ID,
203
00:06:57,040 --> 00:06:58,840
the environment, and the trigger type.
204
00:06:58,840 --> 00:07:01,000
Then at the dependency involved, the error class,
205
00:07:01,000 --> 00:07:02,520
how often that class has appeared,
206
00:07:02,520 --> 00:07:04,120
the last known successful state,
207
00:07:04,120 --> 00:07:05,800
the remediation that was attempted,
208
00:07:05,800 --> 00:07:07,720
and the outcome of that remediation.
209
00:07:07,720 --> 00:07:09,160
I would also add a confidence score,
210
00:07:09,160 --> 00:07:12,680
because a retry after a time out is not the same thing as rewriting a path,
211
00:07:12,680 --> 00:07:15,680
changing a destination, or re-routing a business step.
212
00:07:15,680 --> 00:07:18,800
One action can run safely with high confidence.
213
00:07:18,800 --> 00:07:21,760
Another should stop instantly unless a policy allows it.
214
00:07:21,760 --> 00:07:23,920
That confidence field matters because without it,
215
00:07:23,920 --> 00:07:25,960
every exception looks equally actionable,
216
00:07:25,960 --> 00:07:28,400
and that's how noisy systems become reckless systems,
217
00:07:28,400 --> 00:07:30,800
especially when the same connector behaves differently
218
00:07:30,800 --> 00:07:33,680
across environments, owners, or payload sizes.
219
00:07:33,680 --> 00:07:36,960
And your logic layer needs to know whether it's seeing a known pattern
220
00:07:36,960 --> 00:07:38,440
or just a symptom.
221
00:07:38,440 --> 00:07:40,000
Keep the model lean.
222
00:07:40,000 --> 00:07:41,600
More logs don't create better judgment.
223
00:07:41,600 --> 00:07:44,440
They create more storage, more noise, and more false certainty.
224
00:07:44,440 --> 00:07:46,720
The system doesn't need every output body forever.
225
00:07:46,720 --> 00:07:49,800
It needs the minimum evidence required to classify the issue,
226
00:07:49,800 --> 00:07:51,480
compare it to previous events,
227
00:07:51,480 --> 00:07:54,320
and choose from a narrow set of approved responses.
228
00:07:54,320 --> 00:07:56,160
That's the shortcut nobody teaches.
229
00:07:56,160 --> 00:07:58,120
Useful telemetry is selective.
230
00:07:58,120 --> 00:08:00,200
Storage depends on maturity.
231
00:08:00,200 --> 00:08:03,040
If you're early, a SharePoint list or database table can be enough,
232
00:08:03,040 --> 00:08:06,920
because the point at first is consistency, not elegance.
233
00:08:06,920 --> 00:08:09,560
If you need more scale or tighter operational control,
234
00:08:09,560 --> 00:08:12,040
Azure table storage can work for structured records.
235
00:08:12,040 --> 00:08:14,720
If your estate is larger and you need deeper search, analytics,
236
00:08:14,720 --> 00:08:18,400
or broader observability, then log analytics or application insights
237
00:08:18,400 --> 00:08:19,840
starts to make more sense.
238
00:08:19,840 --> 00:08:21,560
The decision isn't about prestige.
239
00:08:21,560 --> 00:08:23,320
It's about volume query needs retention
240
00:08:23,320 --> 00:08:25,120
and who needs access to the evidence.
241
00:08:25,120 --> 00:08:27,680
I wouldn't bury all of this inside every flow.
242
00:08:27,680 --> 00:08:30,880
Use child flows for the shared supervisory functions instead.
243
00:08:30,880 --> 00:08:32,680
One child flow classifies the error.
244
00:08:32,680 --> 00:08:34,160
Another enriches the context.
245
00:08:34,160 --> 00:08:35,880
Another decides an allowed action.
246
00:08:35,880 --> 00:08:37,120
Another records the result.
247
00:08:37,120 --> 00:08:39,600
That way the business flow stays focused on business work,
248
00:08:39,600 --> 00:08:42,240
while the supervisory layer stays reusable, testable,
249
00:08:42,240 --> 00:08:45,000
and easier to update when your classification logic changes.
250
00:08:45,000 --> 00:08:47,400
If you hard-code all of that into each production flow,
251
00:08:47,400 --> 00:08:50,040
every improvement becomes a manual retrofit project.
252
00:08:50,040 --> 00:08:51,920
You also need policy context in the record,
253
00:08:51,920 --> 00:08:54,400
not just technical context, who owns this flow.
254
00:08:54,400 --> 00:08:56,200
What SLA tier is attached to it?
255
00:08:56,200 --> 00:08:57,840
Does it touch a sensitive data path?
256
00:08:57,840 --> 00:09:00,000
What actions are allowed to run automatically
257
00:09:00,000 --> 00:09:02,560
and what escalation rule applies if confidence drops
258
00:09:02,560 --> 00:09:04,200
or repeat frequency rises?
259
00:09:04,200 --> 00:09:06,120
That's where things change because a timeout
260
00:09:06,120 --> 00:09:08,520
on a low-risk notification flow and a timeout
261
00:09:08,520 --> 00:09:11,720
on an identity workflow should not trigger the same response,
262
00:09:11,720 --> 00:09:14,040
even if the connector error code looks similar.
263
00:09:14,040 --> 00:09:16,160
And one level deeper, the nerve center should separate
264
00:09:16,160 --> 00:09:18,040
event signals from state signals.
265
00:09:18,040 --> 00:09:20,760
An event signal tells you what just happened, a run failed,
266
00:09:20,760 --> 00:09:23,520
a retry succeeded, a token refresh path worked.
267
00:09:23,520 --> 00:09:24,480
Those are moments.
268
00:09:24,480 --> 00:09:27,000
A state signal tells you what has drifted over time,
269
00:09:27,000 --> 00:09:29,920
and that sentence matters because many failures are only obvious
270
00:09:29,920 --> 00:09:33,120
once you compare current behavior with prior healthy behavior.
271
00:09:33,120 --> 00:09:36,040
Looking at slower trends like repeated duration increases,
272
00:09:36,040 --> 00:09:38,240
rising retry counts, or a growing gap
273
00:09:38,240 --> 00:09:40,160
since the last clean success.
274
00:09:40,160 --> 00:09:42,560
If you mix those together, the system reacts to noise.
275
00:09:42,560 --> 00:09:44,720
If you separate them, the system starts seeing drift.
276
00:09:44,720 --> 00:09:46,480
So the nerve center is really a filter.
277
00:09:46,480 --> 00:09:49,000
It turns scattered incidents into comparable records,
278
00:09:49,000 --> 00:09:51,560
and it turns raw failure into operational memory.
279
00:09:51,560 --> 00:09:53,760
That is what gives the recursive loop something solid
280
00:09:53,760 --> 00:09:56,120
to work with because once the telemetry is structured,
281
00:09:56,120 --> 00:09:58,240
the next challenge isn't collecting more.
282
00:09:58,240 --> 00:10:00,520
It's designing how the system re-enters the problem,
283
00:10:00,520 --> 00:10:03,520
changes its behavior, and stops before self-correction
284
00:10:03,520 --> 00:10:05,920
becomes self-inflicted damage.
285
00:10:05,920 --> 00:10:08,440
Engineering the recursive loop, now the loop itself.
286
00:10:08,440 --> 00:10:10,240
When I say recursion in power automate,
287
00:10:10,240 --> 00:10:12,400
I don't mean some elegant computer science demo
288
00:10:12,400 --> 00:10:14,480
where a flow keeps calling itself forever.
289
00:10:14,480 --> 00:10:17,440
In this environment recursion has to mean control re-entry.
290
00:10:17,440 --> 00:10:19,600
The system hits a problem, records what happened,
291
00:10:19,600 --> 00:10:22,080
chooses a narrower next move, and then re-enters
292
00:10:22,080 --> 00:10:24,040
with more context than it had before.
293
00:10:24,040 --> 00:10:27,160
If that second pass doesn't reduce uncertainty or change the state,
294
00:10:27,160 --> 00:10:28,120
it shouldn't run.
295
00:10:28,120 --> 00:10:29,080
That's the rule.
296
00:10:29,080 --> 00:10:31,080
Every pass must do one of two things.
297
00:10:31,080 --> 00:10:32,720
It must either learn something new,
298
00:10:32,720 --> 00:10:34,400
or it must alter the conditions enough
299
00:10:34,400 --> 00:10:36,440
that the next result could reasonably differ.
300
00:10:36,440 --> 00:10:38,680
If all you're doing is repeating the same action
301
00:10:38,680 --> 00:10:41,080
against the same broken dependency with the same parameters,
302
00:10:41,080 --> 00:10:42,520
you don't have a feedback loop.
303
00:10:42,520 --> 00:10:44,680
You have automated panic, and that burns actions,
304
00:10:44,680 --> 00:10:46,880
clutter, telemetry, and drags humans back in later
305
00:10:46,880 --> 00:10:48,200
to clean up the noise.
306
00:10:48,200 --> 00:10:51,160
Power automate gives you a few practical ways to build this.
307
00:10:51,160 --> 00:10:52,880
The simplest is a child flow pattern.
308
00:10:52,880 --> 00:10:56,320
A parent flow detects the issue, passes context to a child flow,
309
00:10:56,320 --> 00:10:58,200
and the child handles classification,
310
00:10:58,200 --> 00:10:59,480
decisioning, and response.
311
00:10:59,480 --> 00:11:01,800
That works well because direct self-invocation
312
00:11:01,800 --> 00:11:02,800
isn't the model here.
313
00:11:02,800 --> 00:11:03,840
You want separation.
314
00:11:03,840 --> 00:11:07,320
Another option is do, until where the loop stops only
315
00:11:07,320 --> 00:11:09,000
when a condition flips, but that condition has
316
00:11:09,000 --> 00:11:11,480
to be tied to state improvement, not hope.
317
00:11:11,480 --> 00:11:13,440
Then you have queue-like hand-off patterns,
318
00:11:13,440 --> 00:11:15,760
where one pass records the issue, and another process
319
00:11:15,760 --> 00:11:18,640
picks it up later after a delay, or after some dependency
320
00:11:18,640 --> 00:11:19,680
window changes.
321
00:11:19,680 --> 00:11:21,600
And then there are bounded retry windows,
322
00:11:21,600 --> 00:11:24,280
where retries exist, but inside a tighter decision frame
323
00:11:24,280 --> 00:11:26,000
instead of brute force repetition.
324
00:11:26,000 --> 00:11:28,440
The thing most people miss is workload reduction.
325
00:11:28,440 --> 00:11:29,720
A healthy recursive design should
326
00:11:29,720 --> 00:11:31,400
shrink the problem each time.
327
00:11:31,400 --> 00:11:34,760
Smaller batch, narrower scope, better classification,
328
00:11:34,760 --> 00:11:37,280
more specific fallback, maybe the first pass tries
329
00:11:37,280 --> 00:11:39,640
the primary connector, the second delays,
330
00:11:39,640 --> 00:11:42,560
the third reduces payload size, and the fourth isolates
331
00:11:42,560 --> 00:11:44,720
one bad item from a larger set.
332
00:11:44,720 --> 00:11:46,560
That is a recursive loop doing useful work
333
00:11:46,560 --> 00:11:49,200
because each pass changes the search space.
334
00:11:49,200 --> 00:11:51,800
It doesn't just keep knocking on the same locked door.
335
00:11:51,800 --> 00:11:53,600
So the decision tree needs to be explicit.
336
00:11:53,600 --> 00:11:55,640
Start with retry, but only when the signal
337
00:11:55,640 --> 00:11:57,280
suggests a temporary issue.
338
00:11:57,280 --> 00:11:58,720
Move to delay when the pattern looks
339
00:11:58,720 --> 00:12:01,000
like throttling or transient service pressure.
340
00:12:01,000 --> 00:12:03,360
Switch connector path, if your architecture allows
341
00:12:03,360 --> 00:12:04,440
an alternate route.
342
00:12:04,440 --> 00:12:06,560
Reduce batch size if payload or volume appears
343
00:12:06,560 --> 00:12:07,480
to be the cause.
344
00:12:07,480 --> 00:12:09,760
Try a token refresh path when the problem points
345
00:12:09,760 --> 00:12:11,200
to authentication drift.
346
00:12:11,200 --> 00:12:14,320
Re-root to a fallback process, when continuity matters more
347
00:12:14,320 --> 00:12:15,360
than elegance.
348
00:12:15,360 --> 00:12:18,160
Escalate to a human when the system reaches the edge
349
00:12:18,160 --> 00:12:19,800
of its confidence or authority.
350
00:12:19,800 --> 00:12:22,680
That confidence gate is where beginners and serious operators
351
00:12:22,680 --> 00:12:23,400
split.
352
00:12:23,400 --> 00:12:26,600
A low risk action with a known pattern can run automatically.
353
00:12:26,600 --> 00:12:29,320
A medium risk action might need a policy check first
354
00:12:29,320 --> 00:12:31,560
because the system knows a possible remedy,
355
00:12:31,560 --> 00:12:33,840
but also knows the blast radius isn't trivial.
356
00:12:33,840 --> 00:12:36,480
A high risk action should stop and ask for human approval,
357
00:12:36,480 --> 00:12:38,920
especially if it touches identity, permission, sensitive
358
00:12:38,920 --> 00:12:40,920
records, or downstream financial impact.
359
00:12:40,920 --> 00:12:42,600
The loop is not there to prove autonomy.
360
00:12:42,600 --> 00:12:44,400
It's there to preserve continuity safely.
361
00:12:44,400 --> 00:12:46,840
So you need breaks, set max attempts,
362
00:12:46,840 --> 00:12:49,080
add cooling periods, suppress duplicates,
363
00:12:49,080 --> 00:12:51,640
so the same issue doesn't keep spawning parallel remediation
364
00:12:51,640 --> 00:12:52,360
paths.
365
00:12:52,360 --> 00:12:54,960
Isolate poison items, so one bad record
366
00:12:54,960 --> 00:12:56,960
doesn't contaminate the whole run.
367
00:12:56,960 --> 00:12:58,680
And make termination conditions obvious
368
00:12:58,680 --> 00:13:01,600
because hidden loop endings are how maintenance logic turns
369
00:13:01,600 --> 00:13:03,240
into its own support incident.
370
00:13:03,240 --> 00:13:06,120
Most recursive designs fail for one reason.
371
00:13:06,120 --> 00:13:08,280
They repeat action without improving diagnosis.
372
00:13:08,280 --> 00:13:11,320
The system sees an error, retries it, waits, retries again,
373
00:13:11,320 --> 00:13:13,920
and logs each failure as if more volume somehow counts
374
00:13:13,920 --> 00:13:14,840
as more intelligence.
375
00:13:14,840 --> 00:13:15,600
It doesn't.
376
00:13:15,600 --> 00:13:17,800
The reason recursion works is not repetition.
377
00:13:17,800 --> 00:13:20,200
It's guided reentry based on stronger evidence.
378
00:13:20,200 --> 00:13:22,520
That's why the telemetry layer and the recursive loop
379
00:13:22,520 --> 00:13:24,160
have to stay tightly connected.
380
00:13:24,160 --> 00:13:25,160
One gather signals.
381
00:13:25,160 --> 00:13:27,800
The other converts those signals into narrower decisions.
382
00:13:27,800 --> 00:13:29,960
And once a loop can take action like that,
383
00:13:29,960 --> 00:13:33,760
a new problem shows up fast, cost, safety, and platform
384
00:13:33,760 --> 00:13:37,800
limits, cost, scale, and platform trade-offs.
385
00:13:37,800 --> 00:13:40,040
Now we need to talk about the part people usually skip,
386
00:13:40,040 --> 00:13:41,920
because self-healing sounds elegant right up
387
00:13:41,920 --> 00:13:45,040
until the bill arrives, and the flow count starts climbing.
388
00:13:45,040 --> 00:13:47,160
A recursive design doesn't just add intelligence.
389
00:13:47,160 --> 00:13:49,240
It adds activity, more checks, more branches,
390
00:13:49,240 --> 00:13:51,760
more child flow calls, more rights to telemetry storage,
391
00:13:51,760 --> 00:13:52,960
more connector traffic.
392
00:13:52,960 --> 00:13:54,680
So if you design this badly, the system
393
00:13:54,680 --> 00:13:56,800
can spend half its time supervising itself
394
00:13:56,800 --> 00:13:58,120
and still not improve outcomes.
395
00:13:58,120 --> 00:13:59,400
That's where the architecture starts
396
00:13:59,400 --> 00:14:01,000
fighting its own economics.
397
00:14:01,000 --> 00:14:02,800
Power automate is strong when the workload
398
00:14:02,800 --> 00:14:05,280
lives close to business process context.
399
00:14:05,280 --> 00:14:06,360
Approvals.
400
00:14:06,360 --> 00:14:07,640
Notifications.
401
00:14:07,640 --> 00:14:08,840
SharePoint changes.
402
00:14:08,840 --> 00:14:10,080
Teams actions.
403
00:14:10,080 --> 00:14:12,160
Microsoft 365 signals.
404
00:14:12,160 --> 00:14:13,480
Short decision chains.
405
00:14:13,480 --> 00:14:14,640
Human touch points.
406
00:14:14,640 --> 00:14:17,280
That is the environment where supervised recursion works well,
407
00:14:17,280 --> 00:14:18,920
because the flow can detect an issue.
408
00:14:18,920 --> 00:14:19,960
Classified.
409
00:14:19,960 --> 00:14:22,800
Take one bounded action and either recover or escalate.
410
00:14:22,800 --> 00:14:25,320
The platform is good at that kind of operational rhythm,
411
00:14:25,320 --> 00:14:27,480
especially when the remediation path is narrow,
412
00:14:27,480 --> 00:14:29,920
and the business owner is still part of the model.
413
00:14:29,920 --> 00:14:32,680
But the limits show up fast when the recursion gets deep.
414
00:14:32,680 --> 00:14:34,680
Loops over large data sets slow down.
415
00:14:34,680 --> 00:14:36,720
Child flow chains get harder to trace.
416
00:14:36,720 --> 00:14:37,960
Action counts rise.
417
00:14:37,960 --> 00:14:39,240
Branches multiply.
418
00:14:39,240 --> 00:14:41,440
A design that felt smart at 10 runs per day
419
00:14:41,440 --> 00:14:43,480
starts feeling heavy at 10,000, especially
420
00:14:43,480 --> 00:14:46,720
when every pass adds logging, retry logic, policy checks,
421
00:14:46,720 --> 00:14:48,640
and fallback evaluation.
422
00:14:48,640 --> 00:14:51,320
And when all of that remains packed inside one giant flow,
423
00:14:51,320 --> 00:14:52,960
maintenance doesn't disappear.
424
00:14:52,960 --> 00:14:55,120
It just moves to a more complicated place.
425
00:14:55,120 --> 00:14:57,840
So there is a threshold where the right answer is not
426
00:14:57,840 --> 00:15:00,040
add more logic in power automate.
427
00:15:00,040 --> 00:15:03,000
The right answer is to externalize part of the pattern.
428
00:15:03,000 --> 00:15:05,880
If you need heavy state handling, wider observability,
429
00:15:05,880 --> 00:15:08,360
high volume recursion, queue-driven processing,
430
00:15:08,360 --> 00:15:10,200
or orchestration across multiple systems
431
00:15:10,200 --> 00:15:12,200
with stronger runtime control, then you
432
00:15:12,200 --> 00:15:13,920
should look beyond one low-code flow
433
00:15:13,920 --> 00:15:15,520
carrying the entire burden.
434
00:15:15,520 --> 00:15:18,080
This is exactly where Azure Logic app starts to matter,
435
00:15:18,080 --> 00:15:20,360
because the decision isn't about prestige.
436
00:15:20,360 --> 00:15:22,360
It's about fit logic apps gives you a different cost
437
00:15:22,360 --> 00:15:23,160
and scale model.
438
00:15:23,160 --> 00:15:25,560
In consumption, every extra action matters.
439
00:15:25,560 --> 00:15:27,840
In standard, fixed compute can make more sense
440
00:15:27,840 --> 00:15:30,240
once the volume is predictable and the recursive workload
441
00:15:30,240 --> 00:15:31,680
is large enough because you're no longer
442
00:15:31,680 --> 00:15:33,640
thinking only in per-action terms.
443
00:15:33,640 --> 00:15:35,680
You're thinking in throughput, hosting model,
444
00:15:35,680 --> 00:15:37,680
and how much supervised re-logic you can run
445
00:15:37,680 --> 00:15:40,880
without turning every improvement into a direct action text.
446
00:15:40,880 --> 00:15:42,120
Research on logic apps.
447
00:15:42,120 --> 00:15:44,680
Standard points to fixed compute becoming the better deal
448
00:15:44,680 --> 00:15:46,360
when action volume gets high enough, which
449
00:15:46,360 --> 00:15:49,080
is the kind of shift enterprise teams need to understand
450
00:15:49,080 --> 00:15:52,120
before they build the wrong control layer in the wrong place.
451
00:15:52,120 --> 00:15:54,160
That doesn't mean power automate is the wrong tool.
452
00:15:54,160 --> 00:15:56,560
It means power automate is the right tool
453
00:15:56,560 --> 00:15:59,200
for supervised recursion close to the business process,
454
00:15:59,200 --> 00:16:02,200
and the wrong tool for every kind of recursive ambition.
455
00:16:02,200 --> 00:16:03,840
That distinction saves a lot of pain.
456
00:16:03,840 --> 00:16:06,120
You can keep the business flow in power automate,
457
00:16:06,120 --> 00:16:08,840
keep the decision surface clear, and move deeper orchestration
458
00:16:08,840 --> 00:16:11,320
or observability to logic apps as your storage
459
00:16:11,320 --> 00:16:14,040
or another service when the recursion starts acting
460
00:16:14,040 --> 00:16:17,120
more like platform engineering than workflow automation.
461
00:16:17,120 --> 00:16:19,280
And cost can't be judged by license lines alone.
462
00:16:19,280 --> 00:16:22,520
If a better supervisory layer cuts manual intervention,
463
00:16:22,520 --> 00:16:25,360
shortens recovery, and prevents repeated incidents,
464
00:16:25,360 --> 00:16:27,960
then the cost discussion has to include a void at downtime,
465
00:16:27,960 --> 00:16:30,800
a void at support effort, and a void at rework.
466
00:16:30,800 --> 00:16:32,480
Teams often compare platform pricing
467
00:16:32,480 --> 00:16:34,920
and ignore the labor that are quietly burning every week
468
00:16:34,920 --> 00:16:37,080
inside manual triage after hours fixes
469
00:16:37,080 --> 00:16:38,960
and repeated business interruptions.
470
00:16:38,960 --> 00:16:40,440
That comparison is incomplete.
471
00:16:40,440 --> 00:16:42,480
There is also a governance cost to bad design.
472
00:16:42,480 --> 00:16:43,920
Telemetry has to live somewhere.
473
00:16:43,920 --> 00:16:45,560
Someone has to own retention.
474
00:16:45,560 --> 00:16:47,160
Someone has to control access.
475
00:16:47,160 --> 00:16:49,200
Someone has to decide what evidence must be kept,
476
00:16:49,200 --> 00:16:51,480
what can be deleted, and how the system proves
477
00:16:51,480 --> 00:16:52,440
what it changed.
478
00:16:52,440 --> 00:16:55,400
If you collect too much, storage and review costs rise.
479
00:16:55,400 --> 00:16:57,240
If you collect too little, the loop loses trust
480
00:16:57,240 --> 00:16:59,080
because nobody can verify why it acted.
481
00:16:59,080 --> 00:17:00,680
So scale is never just compute.
482
00:17:00,680 --> 00:17:02,960
Scale is storage, auditability, ownership,
483
00:17:02,960 --> 00:17:04,960
and the ability to explain behavior later.
484
00:17:04,960 --> 00:17:05,920
And this is the line.
485
00:17:05,920 --> 00:17:08,760
A self-healing pattern either becomes a safe operating model
486
00:17:08,760 --> 00:17:11,560
with clear boundaries or it becomes a noisy automation layer
487
00:17:11,560 --> 00:17:13,640
that multiplies actions, hides risk,
488
00:17:13,640 --> 00:17:15,640
and leaves people cleaning up after a system
489
00:17:15,640 --> 00:17:17,960
that looks clever on paper.
490
00:17:17,960 --> 00:17:20,480
Governance, AI, and autonomy with breaks.
491
00:17:20,480 --> 00:17:23,080
That brings us to the part that decides whether this architecture
492
00:17:23,080 --> 00:17:24,800
belongs in production at all.
493
00:17:24,800 --> 00:17:27,640
Self-healing without governance doesn't reduce drift.
494
00:17:27,640 --> 00:17:29,840
It accelerates it.
495
00:17:29,840 --> 00:17:32,120
The moment a system can react to failure on its own,
496
00:17:32,120 --> 00:17:33,600
you've given it operational influence,
497
00:17:33,600 --> 00:17:35,880
maybe narrow influence, maybe tightly scoped,
498
00:17:35,880 --> 00:17:36,720
but still influence.
499
00:17:36,720 --> 00:17:39,200
And if the permissions are wrong, the data boundaries are weak
500
00:17:39,200 --> 00:17:40,640
or the remediation rules are vague,
501
00:17:40,640 --> 00:17:43,800
the system can apply the wrong fix faster than a human ever could.
502
00:17:43,800 --> 00:17:44,840
That's not resilience.
503
00:17:44,840 --> 00:17:46,600
That's speed without judgment.
504
00:17:46,600 --> 00:17:50,080
AI raises the stakes because bad structure gets exposed faster.
505
00:17:50,080 --> 00:17:52,240
Copilot, agents, and automated assistance
506
00:17:52,240 --> 00:17:54,440
all depend on data access, identity context,
507
00:17:54,440 --> 00:17:55,720
and policy clarity.
508
00:17:55,720 --> 00:17:57,320
If those foundations are weak,
509
00:17:57,320 --> 00:17:59,000
then adding a recursive healing loop
510
00:17:59,000 --> 00:18:00,200
doesn't solve the problem.
511
00:18:00,200 --> 00:18:03,280
It just creates another actor inside the same broken model.
512
00:18:03,280 --> 00:18:05,400
Research around Microsoft 365 governance
513
00:18:05,400 --> 00:18:07,000
keeps pointing to the same issue.
514
00:18:07,000 --> 00:18:08,760
Manual reviews can't keep pace.
515
00:18:08,760 --> 00:18:12,440
And AI surfaces oversharing and misconfiguration almost immediately.
516
00:18:12,440 --> 00:18:14,400
So the loop has to respect the same boundaries
517
00:18:14,400 --> 00:18:16,120
your human operators should respect,
518
00:18:16,120 --> 00:18:17,200
only more consistently.
519
00:18:17,200 --> 00:18:18,680
Start with risk tiers.
520
00:18:18,680 --> 00:18:20,520
Low risk fixes can run automatically.
521
00:18:20,520 --> 00:18:22,440
A bounded retry, a timed delay,
522
00:18:22,440 --> 00:18:25,400
a known fallback on a non-sensitive notification flow.
523
00:18:25,400 --> 00:18:27,560
Fine, medium risk fixes need policy checks.
524
00:18:27,560 --> 00:18:29,440
Maybe the flow wants to switch path,
525
00:18:29,440 --> 00:18:32,320
alter batch size, or move to a fallback connector.
526
00:18:32,320 --> 00:18:35,160
That can still work, but only inside approved conditions.
527
00:18:35,160 --> 00:18:37,000
High risk fixes need a person.
528
00:18:37,000 --> 00:18:39,840
If the remediation touches identities, permissions,
529
00:18:39,840 --> 00:18:41,520
records with sensitive data,
530
00:18:41,520 --> 00:18:42,960
or decisions with business impact,
531
00:18:42,960 --> 00:18:44,840
the system should pause and ask.
532
00:18:44,840 --> 00:18:46,480
Not because the technology is weak,
533
00:18:46,480 --> 00:18:48,520
but because accountability still matters.
534
00:18:48,520 --> 00:18:50,240
Every remediation also needs evidence.
535
00:18:50,240 --> 00:18:51,160
Why did it act?
536
00:18:51,160 --> 00:18:52,320
What signal triggered it?
537
00:18:52,320 --> 00:18:53,560
What policy allowed it?
538
00:18:53,560 --> 00:18:54,400
What changed?
539
00:18:54,400 --> 00:18:56,640
Who owns the outcome if it goes wrong?
540
00:18:56,640 --> 00:18:59,800
Those questions can't be answered with the automation decided.
541
00:18:59,800 --> 00:19:01,680
That sentence is useless in an audit,
542
00:19:01,680 --> 00:19:03,680
useless in a post-incident review,
543
00:19:03,680 --> 00:19:05,520
and useless when trust starts falling
544
00:19:05,520 --> 00:19:06,880
across the platform team.
545
00:19:06,880 --> 00:19:08,800
So the model is autonomy with breaks,
546
00:19:08,800 --> 00:19:11,160
not full autonomy, not automation theater,
547
00:19:11,160 --> 00:19:12,440
controlled autonomy,
548
00:19:12,440 --> 00:19:14,600
where the system can act inside known boundaries,
549
00:19:14,600 --> 00:19:16,200
stop at confidence limits,
550
00:19:16,200 --> 00:19:19,040
and produce a record each time it crosses from observation
551
00:19:19,040 --> 00:19:20,480
into intervention.
552
00:19:20,480 --> 00:19:22,640
That record is what makes the architecture governable,
553
00:19:22,640 --> 00:19:24,960
because now the loop isn't just doing something.
554
00:19:24,960 --> 00:19:26,480
It's doing something explainable.
555
00:19:26,480 --> 00:19:27,880
Once you put those breaks in place,
556
00:19:27,880 --> 00:19:30,400
the design stops being a clever pattern for specialists
557
00:19:30,400 --> 00:19:32,120
and starts looking like an operating model
558
00:19:32,120 --> 00:19:34,240
other teams can actually adopt.
559
00:19:34,240 --> 00:19:35,560
Implementation path.
560
00:19:35,560 --> 00:19:37,960
From brittle flow to self-healing estate,
561
00:19:37,960 --> 00:19:40,080
start with one painful production flow,
562
00:19:40,080 --> 00:19:42,600
add telemetry first, then add classification,
563
00:19:42,600 --> 00:19:44,560
then allow one safe remediation path
564
00:19:44,560 --> 00:19:46,720
that everybody agrees on ahead of time.
565
00:19:46,720 --> 00:19:48,200
Measure mean time to repair,
566
00:19:48,200 --> 00:19:51,280
repeat failures, manual touches, and false positives.
567
00:19:51,280 --> 00:19:52,720
If the pattern lowers support effort
568
00:19:52,720 --> 00:19:55,000
without creating confusion, reuse it,
569
00:19:55,000 --> 00:19:57,120
expand by pattern, not by enthusiasm,
570
00:19:57,120 --> 00:19:59,320
because the final shift isn't really about tooling,
571
00:19:59,320 --> 00:20:00,400
it's about role.
572
00:20:00,400 --> 00:20:01,560
So the shift is simple.
573
00:20:01,560 --> 00:20:03,400
Stop treating failures as tickets
574
00:20:03,400 --> 00:20:05,200
and start treating them as training data
575
00:20:05,200 --> 00:20:08,200
for the logic layer that supervises your flows at runtime.
576
00:20:08,200 --> 00:20:09,640
Pick one production flow this month,
577
00:20:09,640 --> 00:20:12,240
map the signal, the decision, the safe remediation,
578
00:20:12,240 --> 00:20:14,520
and the point where a human still needs to step in.
579
00:20:14,520 --> 00:20:15,840
That's where the new model starts.
580
00:20:15,840 --> 00:20:17,920
If this changed how you think about automation,
581
00:20:17,920 --> 00:20:20,680
subscribe to the M365FM podcast.
582
00:20:20,680 --> 00:20:22,280
Leave a review if you want more of this
583
00:20:22,280 --> 00:20:23,240
and connect with me,
584
00:20:23,240 --> 00:20:25,320
Mirko Peters, on LinkedIn with the next system
585
00:20:25,320 --> 00:20:26,600
you want me to break down.