Building Self-Healing Workflows for Automated Device Remediation

Self-Healing Workflow: An Overview

Traditional device environments require constant monitoring to detect issues that can hinder its operational capacity. Being tedious in nature, it has become inevitable for a modern workflow to take its place in the detection and troubleshooting of issues. Self-Healing workflow is by definition, a system which can identify and resolve potential issues that may come up in it without the need for any human intervention.

Overview: What is Self-Healing?

Self-Healing refers to an automated, closed-loop system where the environment detects and corrects compliance deviations without human intervention.

Traditionally, endpoint management is linear: an admin pushes a configuration, and if a user alters it (e.g., deletes an app, changes a setting), the admin must manually push it again.

Self-Healing creates a continuous loop where the device’s own state triggers the necessary repair through the portal. This reduces the need for human intervention for troubleshooting issues and gives rise to the automation of detecting and resolving the issues.

The Architecture: How Hexnode “Heals”

Hexnode does not have a single button labeled “Self-Heal.” Instead, this ability is engineered by chaining two core features in Hexnode UEM:

• Dynamic Groups (The Detector): Unlike Static Groups, Dynamic Groups populate automatically based on device criteria. We use this to create a “Trap” for non-compliant devices.
• Policy Association (The Enforcer): We associate a policy acting as a remediation to that “Trap” group.

The Logic of Self-Healing

Device breaks rule —> Moves to Dynamic Group —> Receives Fix —> Complies with rule —> Leaves Dynamic Group.

Implementation Recipe: Automated App Persistence

Scenario: You need to ensure a critical business application (e.g., a security agent) is never removed. If a user uninstalls it, the system must immediately reinstall it.

Step A: Configure the “Detector”

We need to identify devices that have lost the application. We do this by creating dynamic groups into which the devices are placed into when an app is missing from the device.

1. Create a Dynamic Group named Missing Critical App.
2. Set the Rule Logic under Choose Condition filters:
   • Compliance Info | Missing apps count | Equal to | [No of apps selected as critical apps in the Required Apps policy]
3. Result: As long as devices have the app, this group remains empty. As soon as the app is removed, the device is automatically sucked into this group.

Step B: Configure the “Enforcer”

We need a policy that specifically targets the issue identified in Step A.

1. Create a New Policy named Remediation: Force Install App.
2. Navigate to Required Apps.
3. Add the critical application and ensure Install Silently is selected (platform dependent).
Note:


Do not apply this policy to your entire fleet. It is reserved for the “Drifted” group.

Step C: Activate the Loop

1. Assign the Enforcer Policy (Step B) to the Detector Group (Step A).
2. The Outcome:
   1. User uninstalls the app.
   2. Hexnode syncs and sees the app is missing.
   3. Device moves to the group Missing Critical App.
   4. The remediation policy hits the device and reinstalls the app.
   5. Device now has the app, so it leaves the Drifted group.

Strategic Enterprise Scenarios

This logic can be applied to security, data usage, and compliance scenarios.