Flow is Nexthink's low-code workflow orchestration engine. It turns the platform's ability to detect problems into the ability to fix them: automatically, consistently, and at the speed of the endpoint fleet. Flow is what Spark executes when it resolves an issue autonomously, and it's what your most experienced engineers' best troubleshooting logic looks like once it's been codified and made repeatable.
Context
Nexthink has always had the ability to push executable actions to managed devices: originally called Remote Actions, these were PowerShell or shell scripts that IT teams could trigger on-demand or automatically. Flow is the evolution of that capability into something substantially more capable: a full workflow orchestration layer with visual design, conditional logic, multi-step sequences, and native integration with the rest of the platform.
If you built a Remote Actions library before Flow was introduced, most of that work carries forward: the execution model is the same. What Flow adds is the orchestration layer around those actions: the ability to chain them, branch based on results, and connect them to Spark, Engage, and Amplify without custom scripting.
Core Capability
Flow workflows follow four main patterns in practice. Understanding which pattern fits a given scenario determines how you structure the workflow and what triggers you attach to it. Most mature DEX programs use all four, covering different points in the incident and experience lifecycle.
Detect and fix before the employee notices
Self-healing workflows are bound to telemetry events: a condition that Nexthink detects on a device fires the workflow automatically, without human involvement. The employee may never know the problem existed. This is the highest-value pattern in Flow: it eliminates a class of issues from reaching the service desk entirely.
Good candidates are issues that are: reliably detectable via telemetry, remediable by a scripted action, and safe to execute without employee confirmation. Disk space cleanup, certificate renewal, agent restart, VPN reconnect, and printer queue clearance are classic examples. The key design criterion is that false positives, running the workflow when the device doesn't actually need it,must be harmless.
Event-triggered No human approval Runs silentlyGive technicians a structured investigation path
Guided diagnostic workflows run on-demand, typically triggered by a service desk agent through Amplify or by Workspace during an investigation. Rather than a technician running a series of ad-hoc commands and interpreting raw output, a Flow workflow packages the diagnostic steps into a single execution with structured output: what was checked, what was found, what the result means.
These workflows embody institutional knowledge. The best diagnostic workflows are built by capturing what your most experienced engineers actually do when a certain issue is reported, then codifying it as a repeatable sequence that any agent can run. The senior engineer's troubleshooting instinct becomes a workflow that a tier-1 agent can execute without knowing why each step matters.
Triggered by Amplify or Workspace Structured output On-demandWhat Spark runs when it resolves issues autonomously
When Spark, the employee-facing AI agent, commits to resolving an issue rather than just diagnosing it, it executes a Flow workflow to perform the actual fix. This is the mechanism that enables Spark's 77% first-contact resolution rate: Spark isn't improvising a fix in the moment, it's selecting and executing a pre-approved, validated workflow from the Flow library.
Workflows intended for Spark execution have stricter design requirements than on-demand flows. They must be safe to run without a technician in the loop, produce output that Spark can translate back to the employee in plain language, and have clear rollback steps if the remediation doesn't achieve the expected result. Approving a workflow for Spark use is a governance decision, not just a technical one.
Spark-approved library Safe without human approval Plain-language outputFleet maintenance that runs on a defined cadence
Scheduled workflows run on a defined time cadence across a target device population: nightly, weekly, or on a rolling basis. Unlike the other three patterns, these aren't event-driven or reactive. They're preventive maintenance tasks that keep the fleet in a known good state: clearing temporary files, resetting network adapters, validating certificate chains, enforcing software configurations.
Scheduled flows are the equivalent of a maintenance window, except they can target only devices that actually need the action (using a Nexthink filter rather than a flat population), run at low-impact times on each device based on activity patterns, and report their results back into the platform for visibility.
Time-based trigger Preventive maintenance Fleet-wide or filteredExecution Model
Understanding the execution model helps you design workflows that behave predictably and produce output the platform can act on. The sequence from trigger to result follows the same path regardless of which workflow pattern you're using.
A telemetry event, a Spark resolution attempt, an Amplify button click, a scheduled time, or an ITSM webhook causes the workflow to be queued for execution on one or more target devices.
The workflow engine resolves which specific devices to execute against: either the single device that fired the event, or a filtered population for fleet-wide workflows.
The Nexthink Collector on each target device receives the workflow package from the cloud platform. Execution happens locally on the endpoint: the device doesn't need to remain connected throughout the workflow run.
Each step in the workflow executes in order. Conditional branches evaluate their criteria and route to the appropriate next step. If a step fails, the workflow follows the defined failure path: remediation, notification, or escalation.
Structured results, success/fail status, diagnostic values, changed configuration states,are returned to the Nexthink platform and made available to Workspace, Amplify, dashboards, and reporting.
A workflow can trigger an Engage campaign as its final step: asking the employee to confirm whether the issue is resolved. This closes the feedback loop and adds employee confirmation to the technical execution record.
In Practice
Every organization's Flow library eventually grows to hundreds of workflows, but the ones that demonstrate immediate value, and build confidence in the platform,tend to be the same ten or fifteen scenarios across most environments. These are the highest-return starting points.
The Closed Loop
Flow's value compounds when you treat it as the action layer of a larger closed loop rather than a standalone automation tool. The most effective DEX programs wire together detection, remediation, communication, and measurement: Flow is the engine that makes all four steps possible in sequence.
Workspace surfaces anomalies and identifies affected device populations. When Workspace's investigation points to a remediable condition, it can trigger the appropriate Flow workflow directly: completing the detection-to-action cycle without leaving the AI environment.
Flow executes the remediation on affected devices, structured output returns to the platform, and results are available to every connected component. It's the execution engine, not a standalone product.
Spark selects a Flow workflow when it commits to resolving an employee issue. The workflow executes on the device, returns a structured result, and Spark translates that result back to the employee in conversational language. Spark's resolution capability is entirely dependent on the quality and breadth of the approved Flow library.
A Flow workflow's final step can trigger an Engage campaign on the same device. After a remediation completes, whether autonomous or technician-initiated,a short survey confirms from the employee's perspective whether the experience is now resolved. Employee confirmation becomes part of the workflow's success metric.
Design Guidance
A Flow workflow that works in testing and a workflow that works reliably across 30,000 heterogeneous endpoints at 2am are different things. These are the design principles that separate a sustainable Flow library from one that creates more noise than it eliminates.
The majority of workflow failures occur in edge cases: the device is offline when the workflow runs, the target application isn't installed, the user doesn't have the required permissions. Design the failure path, what the workflow does when a step doesn't succeed,before you optimize the success path. A workflow with no failure handling creates invisible failures that look like successes.
Build workflows in this order: first confirm that the detection condition (the trigger) is reliably identifying the right devices, then build the diagnostic logic, then build the remediation. Remediating the wrong devices because the trigger is too broad is worse than not remediating at all. Use NQL to query the target population before writing a single workflow step.
Self-healing workflows in particular should be validated on a small, representative group of devices before fleet-wide deployment. The canary group should include edge cases in your fleet: legacy hardware, non-standard OS builds, devices with elevated privileges or restricted environments. Issues that only appear at scale almost always appear first on unusual device configurations.
Workflows that output raw logs, long text blocks,are difficult for Workspace, Amplify, and Spark to use. Design workflows to output structured values: boolean success/fail, numeric measurements, categorical results. A workflow that returns "disk_freed_mb=2847, cleanup_status=success" is far more useful to the platform than one that returns a 40-line PowerShell transcript.
Treat Flow workflows like code: version-controlled, peer-reviewed before promotion to production, and documented with the rationale for each step. This matters especially for workflows approved for Spark execution: Spark is executing these on employees' devices without a technician in the loop. The approval process is the only quality gate.
A workflow is idempotent if running it twice produces the same result as running it once. Self-healing workflows are sometimes triggered multiple times on the same device if the condition persists. A workflow that's not idempotent, for example, one that appends to a config file rather than replacing it,can corrupt device state if it runs more than once. Check for this explicitly during design.
Before You Start
Flow can technically be deployed on day one of a Nexthink implementation, but the conditions for running it safely and getting real value from it take time to establish. These are the prerequisites experienced practitioners consistently identify before investing heavily in the Flow library.
Self-healing workflows execute on devices where the Collector is running. A fleet with 70% coverage means 30% of affected devices never receive the remediation, and your results will look inconsistent without an obvious reason. Target 90%+ coverage and maintain it before deploying proactive flows. Coverage gaps also mean detection is incomplete: your triggers won't fire for uncovered devices.
Flow remediation is only as good as the detection that precedes it. Before building remediation workflows, confirm that your Nexthink metrics and event definitions are reliably identifying the issues you want to fix. If the telemetry that feeds your triggers is noisy or misconfigured, you'll remediate the wrong devices, build distrust in automation, and spend more time managing false positives than fixing real problems.
Decide before building who can approve a workflow for self-healing use, who can approve for Spark execution, and what testing is required before promotion. These are different approval tiers with different risk levels. A workflow that runs diagnostics on a device is low risk; a workflow that modifies system configurations is not. Without a governance process, high-risk workflows will drift into production without adequate review.
Flow's visual builder handles most diagnostic and simple remediation workflows without scripting. But the highest-value scenarios, security posture enforcement, complex application repair, multi-stage configuration management,require PowerShell or shell script steps. Make sure someone on the team can write and review scripts before planning workflows that depend on them. The visual builder is the interface; the scripts are still doing the work.
Identify a set of devices, ideally representing your hardware and OS diversity,that can receive new workflows before production rollout. Production issues from untested workflows are hard to reverse quickly in a large fleet, and they erode trust in automation among both employees and IT leadership. The canary group doesn't need to be large; 50–100 devices across your key hardware and OS variants is usually sufficient.
Decide how you'll measure whether a workflow is working before you deploy it. For self-healing flows, this means tracking the frequency of the condition being remediated over time: if a workflow is working, that frequency should decline. For diagnostic flows, track technician time-to-resolution before and after. Without these baselines, you can build a large Flow library and not be able to demonstrate what value it's producing.
Continue
Flow and Amplify are closely related: Amplify surfaces Flow workflows inside ITSM tools and writes results back to tickets. If you're building a service desk integration alongside your Flow library, Amplify is the next natural step.
Technical details and workflow execution model on this page are sourced from Nexthink official documentation, product pages, and release notes for the Nexthink Infinity platform. View full references →