Most flows automate tasks, but they don't manage themselves.
That sounds small.
It isn't, because the moment a trigger fails,
most teams fall back into the same old model.
Someone gets an alert, someone checks run history,
someone patches the symptom,
and then everyone pretends the system is healthy again.
The automation runs until the next break.
That model doesn't scale.
The problem usually isn't missing features,
and it usually isn't bad makers.
It's maintenance debt.
Every new flow adds one more thing that needs watching,
one more dependency that can drift
and one more silent point of failure inside the tenant.
So the shift is this, stop treating failure as an interruption,
treat it as input.
In this episode, we're building a recursive feedback loop
inside power automate with telemetry,
decision logic, and controlled self correction,
because without that layer, your flow estate
doesn't get smarter.
It just gets bigger and weaker.
Before we build the pattern,
we need to get clear on what actually breaks.
The death of manual debugging.
In most environments, manual maintenance
is still the real operating model, not the flow diagram,
not the governance deck, not the nice automation roadmap,
what actually keeps the estate running
is a human being checking failed runs,
retrygaring actions, updating connections,
cleaning up edge cases, and doing weekend repair work
that nobody planned for but everyone expects.
So you don't really have autonomous automation.
You have automated work sitting on top of manual supervision.
And that gap matters because the flow looks stable
right up until a connector changes behavior,
a token expires, a payload grows,
or a dependency upstream starts returning
something slightly different than yesterday,
which is exactly when the automated process
turns back into operations labor.
This is where most teams get trapped.
They build more flows to save time,
but each flow adds another maintenance surface,
another owner, another trigger, another hidden assumption.
And because those assumptions are spread across approvals,
provisioning, reporting, access requests, finance handoffs,
or compliance tasks, a single broken business critical flow
can store much more than one transaction.
It can freeze a whole chain of work that depends on it.
That is why break-fix thinking fails.
Reactive maintenance keeps teams stuck in high labor
and downtime costs.
In broader maintenance research, predictive approaches
reduce overall costs by 25% to 30% and cut breakdowns by 70%
compared with reactive models.
The point isn't that a power-automate flow
behaves like a factory machine.
The point is the operating model is the same.
If you wait for failure and then respond manually,
the labor compounds and the downtime spreads
and downtime isn't abstract.
In some sectors, unplanned downtime
averages $260,000 per hour.
You don't need to import that number directly
into every M365 workflow, but you do need to understand
the pattern behind it.
When a business critical automation stalls,
the cost isn't the failed run.
The cost is the approvals that stop moving,
the accounts that don't get provisioned,
the reports that don't land,
and the people who now need to investigate by hand.
So maintenance debt isn't a pile of isolated bugs.
It's system debt.
It compounds through dependencies, ownership gaps,
undocumented logic, and repeated manual intervention.
That's why teams feel slower even while they keep automating more.
Now, basic try-catch logic still matters.
Scopes, retries, fallback branches, all of that helps locally.
You should use it, but local error handling
doesn't change the model.
It just makes one flow less fragile in one moment.
It doesn't create memory across failures,
and it doesn't turn exceptions into signals
the wider system can learn from.
So if the model is wrong, the next layer
can't be more error emails.
It has to be something that watches patterns,
classifies drift, and changes behavior
before people get pulled back in.
The telemetry-driven logic layer.
So what replaces that model?
A telemetry-driven logic layer, not another dashboard,
not a prettier failure report.
A logic layer is a control plane inside your flow estate
that watches signals, classifies what kind of failure is happening,
and then changes behavior based on what it sees.
The flow still does the business job,
but now something else supervises
how that job behaves when conditions shift.
That separation matters more than most people think.
Business logic should answer one question.
What work needs to happen?
Approved the request, create the account,
send the report, update the list.
Supervisory logic answers a different question,
and it's the one that usually gets ignored.
What should happen when the environment stops
matching the assumptions this flow depends on?
Especially when the same failure pattern starts
repeating across runs, owners, and connectors.
If you mix those two jobs inside one pile of actions,
the flow turns into its own confused operator.
It tries to process the business task,
diagnose the failure, decide policy, log history,
and recover all at once.
That's where things get messy fast,
because the flow is no longer just doing work.
It's guessing about itself.
The better model is explicit.
You define a desired state.
Then the system checks for drift from that state.
It decides what kind of drift it is.
It applies a response.
Then it records the outcome
so the next decision can improve.
Desired state detection, decision, remediation, learning.
That's the loop.
And if you remember nothing else, remember this.
The remediation is not the smart part.
The decision is.
Now what feeds that decision?
Telemetry.
And not all telemetry is equally useful.
A lot of teams collect whatever the platform already gives them
and call that observability.
But decision-grade telemetry is narrower.
It captures what helps the system choose a safe next action.
Run history matters, yes.
Duration drift matters because of flow
that suddenly takes three times longer,
maybe nearing a timeout or dependency issue.
Retry patterns matter because repeated retries
often point to a class of problem, not a one-off glitch.
Connector failures matter, throttling matters,
payload size matters, owner context matters,
business criticality matters.
This clicked for me when I stopped asking what failed.
And started asking,
what does the system need to know to respond differently next time?
That's a different design question.
One is descriptive, the other is operational.
So there are really two kinds of data in a flow estate.
First, normal flow data, inputs, outputs, records,
message bodies, form responses, created items.
That's the content the process is moving around.
Then decision-grade telemetry, error class,
execution duration trends, dependency health,
remediation history, confidence level,
allowed fallback paths, escalation thresholds.
That data doesn't exist to complete the task.
It exists to supervise the task.
And this is the shift.
Governance usually lives in documents, standards,
naming rules and review meetings.
Useful but static.
The telemetry driven logic layer
moves governance into runtime.
It asks, in the moment of failure,
what policy applies here, what action is allowed,
what confidence do we have,
and when should a human step in?
That's governance doing work, not governance,
waiting in a folder.
Which means the logic layer is not
some extra technical decoration around your flows.
It's the part that turns automation from task execution
into supervised adaptation.
Without it, every failure still depends
on people reading symptoms.
With it, the estate starts classifying its own conditions,
marrowing its own uncertainty,
and acting within defined limits.
And once that model is in place,
the next question isn't whether self-correction is possible.
The next question is, what this loop needs to store?
So its decisions stay grounded instead of improvising.
Building the telemetry nerve center.
Once you accept that the flow needs supervision,
you need one place where every exception turns into structured evidence.
That's the nerve center.
Not a dumping ground for logs, not a giant archive nobody reads.
A small, usable system that records enough context
for the next decision to be better than the last one.
Because if failure stayed trapped inside run history,
they stay local.
They don't accumulate into pattern knowledge.
So the first job is the data model.
For each event, capture the flow ID,
the environment, and the trigger type.
Then at the dependency involved, the error class,
how often that class has appeared,
the last known successful state,
the remediation that was attempted,
and the outcome of that remediation.
I would also add a confidence score,
because a retry after a time out is not the same thing as rewriting a path,
changing a destination, or re-routing a business step.
One action can run safely with high confidence.
Another should stop instantly unless a policy allows it.
That confidence field matters because without it,
every exception looks equally actionable,
and that's how noisy systems become reckless systems,
especially when the same connector behaves differently
across environments, owners, or payload sizes.
And your logic layer needs to know whether it's seeing a known pattern
or just a symptom.
Keep the model lean.
More logs don't create better judgment.
They create more storage, more noise, and more false certainty.
The system doesn't need every output body forever.
It needs the minimum evidence required to classify the issue,
compare it to previous events,
and choose from a narrow set of approved responses.
That's the shortcut nobody teaches.
Useful telemetry is selective.
Storage depends on maturity.
If you're early, a SharePoint list or database table can be enough,
because the point at first is consistency, not elegance.
If you need more scale or tighter operational control,
Azure table storage can work for structured records.
If your estate is larger and you need deeper search, analytics,
or broader observability, then log analytics or application insights
starts to make more sense.
The decision isn't about prestige.
It's about volume query needs retention
and who needs access to the evidence.
I wouldn't bury all of this inside every flow.
Use child flows for the shared supervisory functions instead.
One child flow classifies the error.
Another enriches the context.
Another decides an allowed action.
Another records the result.
That way the business flow stays focused on business work,
while the supervisory layer stays reusable, testable,
and easier to update when your classification logic changes.
If you hard-code all of that into each production flow,
every improvement becomes a manual retrofit project.
You also need policy context in the record,
not just technical context, who owns this flow.
What SLA tier is attached to it?
Does it touch a sensitive data path?
What actions are allowed to run automatically
and what escalation rule applies if confidence drops
or repeat frequency rises?
That's where things change because a timeout
on a low-risk notification flow and a timeout
on an identity workflow should not trigger the same response,
even if the connector error code looks similar.
And one level deeper, the nerve center should separate
event signals from state signals.
An event signal tells you what just happened, a run failed,
a retry succeeded, a token refresh path worked.
Those are moments.
A state signal tells you what has drifted over time,
and that sentence matters because many failures are only obvious
once you compare current behavior with prior healthy behavior.
Looking at slower trends like repeated duration increases,
rising retry counts, or a growing gap
since the last clean success.
If you mix those together, the system reacts to noise.
If you separate them, the system starts seeing drift.
So the nerve center is really a filter.
It turns scattered incidents into comparable records,
and it turns raw failure into operational memory.
That is what gives the recursive loop something solid
to work with because once the telemetry is structured,
the next challenge isn't collecting more.
It's designing how the system re-enters the problem,
changes its behavior, and stops before self-correction
becomes self-inflicted damage.
Engineering the recursive loop, now the loop itself.
When I say recursion in power automate,
I don't mean some elegant computer science demo
where a flow keeps calling itself forever.
In this environment recursion has to mean control re-entry.
The system hits a problem, records what happened,
chooses a narrower next move, and then re-enters
with more context than it had before.
If that second pass doesn't reduce uncertainty or change the state,
it shouldn't run.
That's the rule.
Every pass must do one of two things.
It must either learn something new,
or it must alter the conditions enough
that the next result could reasonably differ.
If all you're doing is repeating the same action
against the same broken dependency with the same parameters,
you don't have a feedback loop.
You have automated panic, and that burns actions,
clutter, telemetry, and drags humans back in later
to clean up the noise.
Power automate gives you a few practical ways to build this.
The simplest is a child flow pattern.
A parent flow detects the issue, passes context to a child flow,
and the child handles classification,
decisioning, and response.
That works well because direct self-invocation
isn't the model here.
You want separation.
Another option is do, until where the loop stops only
when a condition flips, but that condition has
to be tied to state improvement, not hope.
Then you have queue-like hand-off patterns,
where one pass records the issue, and another process
picks it up later after a delay, or after some dependency
window changes.
And then there are bounded retry windows,
where retries exist, but inside a tighter decision frame
instead of brute force repetition.
The thing most people miss is workload reduction.
A healthy recursive design should
shrink the problem each time.
Smaller batch, narrower scope, better classification,
more specific fallback, maybe the first pass tries
the primary connector, the second delays,
the third reduces payload size, and the fourth isolates
one bad item from a larger set.
That is a recursive loop doing useful work
because each pass changes the search space.
It doesn't just keep knocking on the same locked door.
So the decision tree needs to be explicit.
Start with retry, but only when the signal
suggests a temporary issue.
Move to delay when the pattern looks
like throttling or transient service pressure.
Switch connector path, if your architecture allows
an alternate route.
Reduce batch size if payload or volume appears
to be the cause.
Try a token refresh path when the problem points
to authentication drift.
Re-root to a fallback process, when continuity matters more
than elegance.
Escalate to a human when the system reaches the edge
of its confidence or authority.
That confidence gate is where beginners and serious operators
split.
A low risk action with a known pattern can run automatically.
A medium risk action might need a policy check first
because the system knows a possible remedy,
but also knows the blast radius isn't trivial.
A high risk action should stop and ask for human approval,
especially if it touches identity, permission, sensitive
records, or downstream financial impact.
The loop is not there to prove autonomy.
It's there to preserve continuity safely.
So you need breaks, set max attempts,
add cooling periods, suppress duplicates,
so the same issue doesn't keep spawning parallel remediation
paths.
Isolate poison items, so one bad record
doesn't contaminate the whole run.
And make termination conditions obvious
because hidden loop endings are how maintenance logic turns
into its own support incident.
Most recursive designs fail for one reason.
They repeat action without improving diagnosis.
The system sees an error, retries it, waits, retries again,
and logs each failure as if more volume somehow counts
as more intelligence.
It doesn't.
The reason recursion works is not repetition.
It's guided reentry based on stronger evidence.
That's why the telemetry layer and the recursive loop
have to stay tightly connected.
One gather signals.
The other converts those signals into narrower decisions.
And once a loop can take action like that,
a new problem shows up fast, cost, safety, and platform
limits, cost, scale, and platform trade-offs.
Now we need to talk about the part people usually skip,
because self-healing sounds elegant right up
until the bill arrives, and the flow count starts climbing.
A recursive design doesn't just add intelligence.
It adds activity, more checks, more branches,
more child flow calls, more rights to telemetry storage,
more connector traffic.
So if you design this badly, the system
can spend half its time supervising itself
and still not improve outcomes.
That's where the architecture starts
fighting its own economics.
Power automate is strong when the workload
lives close to business process context.
Approvals.
Notifications.
SharePoint changes.
Teams actions.
Microsoft 365 signals.
Short decision chains.
Human touch points.
That is the environment where supervised recursion works well,
because the flow can detect an issue.
Classified.
Take one bounded action and either recover or escalate.
The platform is good at that kind of operational rhythm,
especially when the remediation path is narrow,
and the business owner is still part of the model.
But the limits show up fast when the recursion gets deep.
Loops over large data sets slow down.
Child flow chains get harder to trace.
Action counts rise.
Branches multiply.
A design that felt smart at 10 runs per day
starts feeling heavy at 10,000, especially
when every pass adds logging, retry logic, policy checks,
and fallback evaluation.
And when all of that remains packed inside one giant flow,
maintenance doesn't disappear.
It just moves to a more complicated place.
So there is a threshold where the right answer is not
add more logic in power automate.
The right answer is to externalize part of the pattern.
If you need heavy state handling, wider observability,
high volume recursion, queue-driven processing,
or orchestration across multiple systems
with stronger runtime control, then you
should look beyond one low-code flow
carrying the entire burden.
This is exactly where Azure Logic app starts to matter,
because the decision isn't about prestige.
It's about fit logic apps gives you a different cost
and scale model.
In consumption, every extra action matters.
In standard, fixed compute can make more sense
once the volume is predictable and the recursive workload
is large enough because you're no longer
thinking only in per-action terms.
You're thinking in throughput, hosting model,
and how much supervised re-logic you can run
without turning every improvement into a direct action text.
Research on logic apps.
Standard points to fixed compute becoming the better deal
when action volume gets high enough, which
is the kind of shift enterprise teams need to understand
before they build the wrong control layer in the wrong place.
That doesn't mean power automate is the wrong tool.
It means power automate is the right tool
for supervised recursion close to the business process,
and the wrong tool for every kind of recursive ambition.
That distinction saves a lot of pain.
You can keep the business flow in power automate,
keep the decision surface clear, and move deeper orchestration
or observability to logic apps as your storage
or another service when the recursion starts acting
more like platform engineering than workflow automation.
And cost can't be judged by license lines alone.
If a better supervisory layer cuts manual intervention,
shortens recovery, and prevents repeated incidents,
then the cost discussion has to include a void at downtime,
a void at support effort, and a void at rework.
Teams often compare platform pricing
and ignore the labor that are quietly burning every week
inside manual triage after hours fixes
and repeated business interruptions.
That comparison is incomplete.
There is also a governance cost to bad design.
Telemetry has to live somewhere.
Someone has to own retention.
Someone has to control access.
Someone has to decide what evidence must be kept,
what can be deleted, and how the system proves
what it changed.
If you collect too much, storage and review costs rise.
If you collect too little, the loop loses trust
because nobody can verify why it acted.
So scale is never just compute.
Scale is storage, auditability, ownership,
and the ability to explain behavior later.
And this is the line.
A self-healing pattern either becomes a safe operating model
with clear boundaries or it becomes a noisy automation layer
that multiplies actions, hides risk,
and leaves people cleaning up after a system
that looks clever on paper.
Governance, AI, and autonomy with breaks.
That brings us to the part that decides whether this architecture
belongs in production at all.
Self-healing without governance doesn't reduce drift.
It accelerates it.
The moment a system can react to failure on its own,
you've given it operational influence,
maybe narrow influence, maybe tightly scoped,
but still influence.
And if the permissions are wrong, the data boundaries are weak
or the remediation rules are vague,
the system can apply the wrong fix faster than a human ever could.
That's not resilience.
That's speed without judgment.
AI raises the stakes because bad structure gets exposed faster.
Copilot, agents, and automated assistance
all depend on data access, identity context,
and policy clarity.
If those foundations are weak,
then adding a recursive healing loop
doesn't solve the problem.
It just creates another actor inside the same broken model.
Research around Microsoft 365 governance
keeps pointing to the same issue.
Manual reviews can't keep pace.
And AI surfaces oversharing and misconfiguration almost immediately.
So the loop has to respect the same boundaries
your human operators should respect,
only more consistently.
Start with risk tiers.
Low risk fixes can run automatically.
A bounded retry, a timed delay,
a known fallback on a non-sensitive notification flow.
Fine, medium risk fixes need policy checks.
Maybe the flow wants to switch path,
alter batch size, or move to a fallback connector.
That can still work, but only inside approved conditions.
High risk fixes need a person.
If the remediation touches identities, permissions,
records with sensitive data,
or decisions with business impact,
the system should pause and ask.
Not because the technology is weak,
but because accountability still matters.
Every remediation also needs evidence.
Why did it act?
What signal triggered it?
What policy allowed it?
What changed?
Who owns the outcome if it goes wrong?
Those questions can't be answered with the automation decided.
That sentence is useless in an audit,
useless in a post-incident review,
and useless when trust starts falling
across the platform team.
So the model is autonomy with breaks,
not full autonomy, not automation theater,
controlled autonomy,
where the system can act inside known boundaries,
stop at confidence limits,
and produce a record each time it crosses from observation
into intervention.
That record is what makes the architecture governable,
because now the loop isn't just doing something.
It's doing something explainable.
Once you put those breaks in place,
the design stops being a clever pattern for specialists
and starts looking like an operating model
other teams can actually adopt.
Implementation path.
From brittle flow to self-healing estate,
start with one painful production flow,
add telemetry first, then add classification,
then allow one safe remediation path
that everybody agrees on ahead of time.
Measure mean time to repair,
repeat failures, manual touches, and false positives.
If the pattern lowers support effort
without creating confusion, reuse it,
expand by pattern, not by enthusiasm,
because the final shift isn't really about tooling,
it's about role.
So the shift is simple.
Stop treating failures as tickets
and start treating them as training data
for the logic layer that supervises your flows at runtime.
Pick one production flow this month,
map the signal, the decision, the safe remediation,
and the point where a human still needs to step in.
That's where the new model starts.
If this changed how you think about automation,
subscribe to the M365FM podcast.
Leave a review if you want more of this
and connect with me,
Mirko Peters, on LinkedIn with the next system
you want me to break down.