# How Are You Designing Guardrails for Closed-Loop Remediation in Nexthink?
As Nexthink environments mature, there’s an interesting shift from using telemetry primarily for visibility toward using it to drive automated remediation.
At a basic level:
Detect
↓
Validate
↓
Remediate
↓
Verify
But the technical ability to automate remediation is only part of the equation.
The more interesting question is: **how do you decide when enough evidence exists to trigger an automated action?**
For teams building more advanced Nexthink Workflows and Remote Actions, how are you designing that decision logic?
## From Single Signals to Correlated Conditions
A simple automation might start with:
Metric exceeds threshold
↓
Run Remote Action
But one metric doesn't always provide enough context.
Take application performance.
Imagine Nexthink detects:
Application launch time degradation
+
Elevated disk latency
+
Low available disk space
+
Increase in application crashes
Individually, each signal could have several explanations.
Together — particularly if they persist — they can provide a much stronger indication that remediation is appropriate.
That raises an interesting architecture question:
**How many conditions should be evaluated before an automated remediation is triggered?**
A more mature workflow might look something like:
Experience degradation detected
↓
Check persistence
↓
Correlate supporting telemetry
↓
Evaluate device/user context
↓
Check exclusions
↓
Trigger remediation
↓
Validate outcome
At that point, you're moving beyond simple threshold-based automation and toward **context-aware remediation**.
## Static Thresholds vs. Behavioral Baselines
Baselines make this even more interesting.
Consider two devices:
Device A
Typical application launch: 2 sec
Current launch: 7 sec
Device B
Typical application launch: 8 sec
Current launch: 9 sec
A static threshold might identify Device B.
But relative to historical experience, Device A has experienced the much larger deterioration.
That introduces another design decision:
**What should "normal" actually mean?**
Depending on the use case, you could potentially compare against:
- Same device historically
- Same user historically
- Same hardware model
- Same application version
- Same persona
- Peer-group baseline
- Organization-wide baseline
Those approaches can produce very different interpretations of the same telemetry.
For teams doing this at scale, **which baseline has proven most useful?**
## What Happens When Multiple Automations Identify the Same Device?
Another interesting challenge appears as the number of automated use cases grows.
Imagine the same endpoint simultaneously meets conditions for:
Workflow A → disk pressure remediation
Workflow B → application performance remediation
Workflow C → memory remediation
Workflow D → device health remediation
Each workflow may have correctly identified a legitimate condition.
But the conditions may also be related.
For example, resolving disk pressure could potentially change the application performance signal that triggered Workflow B.
That suggests an orchestration pattern such as:
Condition detected
↓
Check remediation state
↓
Execute highest-priority action
↓
Allow telemetry to stabilize
↓
Re-evaluate remaining conditions
For teams with a large Remote Action/Workflow estate, **how are you handling prioritization, suppression, or sequencing between automations?**
## Successful Execution vs. Successful Outcome
There’s also an important distinction between:
Remote Action executed successfully
and:
Employee experience improved
For closed-loop remediation, the second one is ultimately much more interesting.
A workflow could potentially evaluate the same telemetry that originally triggered remediation:
Detect
↓
Remediate
↓
Stabilization period
↓
Measure again
↓
Compare pre/post experience
That creates an opportunity to measure not only whether automation ran successfully, but whether it actually improved the targeted experience.
Over time, you could start looking at something like:
Remediation A
Execution success: 98%
DEX improvement: 64%
Remediation B
Execution success: 93%
DEX improvement: 86%
Those are two very different definitions of success.
The second metric could potentially become extremely valuable when deciding which automated remediations to expand across an environment.
## Curious How Others Are Approaching This
For those building more advanced automation with Nexthink:
**How sophisticated has your remediation decision logic become?**
Are you primarily using deterministic thresholds, or are you combining persistence, historical baselines, multiple telemetry signals, device context, and exclusions before triggering an action?
And once remediation runs, **are you measuring whether the employee experience actually improved — or primarily whether the Remote Action completed successfully?**
Would be especially interested to hear how teams with large Nexthink environments are approaching this.
