Tuesday, September 8, 2026

Nexthink Infinity — Complete Study Guide

A self-contained learning resource covering every topic in the Nexthink Infinity curriculum: DEX foundations, platform architecture, the Digital Experience Score, NQL, dashboards, campaigns, remote actions, alerts, platform administration, integrations, Amplify, troubleshooting, application experience, workflows and automation, and Nexthink Adopt.

How to use this guide

Each module follows the same shape: concepts (what it is and why it exists), mechanics (how it actually works), practice (worked examples and walkthroughs), pitfalls (what goes wrong in real deployments), and self-check questions. Answers are at the end.

Work through Modules 1–5 in order regardless of your role — they are cumulative. After that you can jump to whichever specialisation applies to you.

Sourcing note. Product-specific content in this guide has been checked against Nexthink's official documentation at docs.nexthink.com and docs-adopt.nexthink.com; see the References section at the end for the pages used. Methodology sections — troubleshooting sequence, alert design, automation governance, dashboard design — are general IT operations practice and are not attributable to Nexthink documentation. Where a claim is a judgement rather than a documented fact, it says so. Two areas remain unverified and are marked ⚠ in place: the DEXOps/Navigator material, and the maturity model in Module 17, which is a framing of my own and not an official Nexthink model.

Documentation tip: every docs.nexthink.com page is available as Markdown by appending .md to the URL, and a full index lives at docs.nexthink.com/platform/llms.txt.

PART I — FOUNDATIONS

Module 1: Digital Employee Experience as a discipline

Concepts

Traditional IT monitoring answers the question "is the service up?" Availability monitoring, infrastructure metrics, APM traces and synthetic checks all measure the system. DEX asks a different question: "is the employee able to do their work, and how does it feel?"

These two questions diverge more often than most IT organisations expect. A server can report 99.99% availability while a specific department's laptops take 90 seconds to load the application because of a local antivirus exclusion problem. The service dashboard is green; the experience is red.

DEX closes that gap by measuring at the point of consumption — the endpoint, the browser, the employee's actual session — and by combining two fundamentally different kinds of evidence:

Evidence type	Also called	Source	Example
Objective telemetry	"Hard" data	Endpoint agent, browser extension	Boot time 142s; app crashed 4× this week; page load 6.2s
Subjective feedback	"Soft" data	In-product surveys	"How satisfied are you with your laptop performance?" → 2/5

Neither is sufficient alone. Hard data tells you what is happening but not whether employees care. Soft data tells you what hurts but not why. The value of a DEX platform is the correlation: discovering that the department reporting the lowest satisfaction is the same one running a specific driver version.

The three operating modes of DEX

Reactive — an employee reports a problem, and DEX data shortens diagnosis. This is where most programmes start and where the fastest wins appear (reduced average handle time, fewer escalations).

Proactive — the platform detects a degrading condition and IT acts before tickets arrive. Requires alerting, baselines and someone whose job it is to respond.

Predictive / preventive — patterns are used to prevent recurrence entirely: fleet-wide remediation, changed standard builds, or a rollout blocked because pilot telemetry looked wrong.

Programmes that stall almost always stall between reactive and proactive, because proactive work requires dedicated ownership rather than spare capacity from the service desk.

Where DEX sits alongside other tools

Tool category	Measures	Vantage point	Overlap with DEX
ITSM (ServiceNow, Jira SM)	Tickets, workflow, SLAs	Process	DEX feeds context into tickets; DEX metrics can trigger them
Endpoint management (Intune, SCCM, Jamf)	Compliance, patch, config	Device state	DEX shows the experience impact of config choices
APM / observability	Application internals	Server-side	DEX covers the last mile the APM cannot see
Network monitoring	Links, latency	Infrastructure	DEX measures perceived network quality per employee
Survey / EX platforms	Sentiment	Employee	DEX ties sentiment to technical cause

DEX is not a replacement for any of these. Its distinguishing property is the vantage point: it is the only category that sits where the employee sits.

Self-check

Give an example where infrastructure monitoring shows green but DEX shows a serious problem.
Why is sentiment data insufficient on its own for prioritising remediation work?
What organisational change is required to move from reactive to proactive DEX?

Show answers

1. An application server reports full availability while a specific department's devices take minutes to load it because of a local security-agent exclusion issue. Server-side monitoring cannot see the endpoint.

2. Sentiment tells you what hurts but not why or how widespread the technical cause is; without telemetry you cannot identify the population to fix or verify that a fix worked.

3. Dedicated ownership — someone whose actual job is responding to proactively detected issues, rather than spare capacity from a reactive team.

Module 2: Nexthink Infinity architecture and platform components

Concepts

Nexthink Infinity is a cloud-hosted (SaaS) DEX platform. Data is collected at the edge by lightweight agents and a browser extension, transmitted to a customer-specific cloud instance, and consumed through a web interface and APIs.

The data collection layer

Nexthink Collector is the endpoint agent, described as a lightweight agent based on patented technology that gathers hardware, software and activity data, capturing network connections, program executions and installations among other telemetry. It is available for Windows and macOS, plus a lightweight variant for IGEL OS thin clients.

Its user-activity collection is shared between a kernel driver and a helper service (or daemon). Running close to the operating system is what allows it to report information only visible at that level. Because the Windows driver is kernel-mode, a CrashGuard feature exists: it detects system crashes and, by default, disables the Collector driver if the system crashes more than five times in a row after installation. On Windows the kernel components are signed with a Microsoft certificate; the macOS Collector is signed with Nexthink's Developer ID and goes through Apple notarization.

Two operational properties matter in practice. Depending on the telemetry type, data is buffered and retried for up to 15 minutes, or persisted locally for up to 7 days and guaranteed for delivery once connectivity returns — so a laptop offline for a few days does not create a permanent hole. And configuration changes and Collector updates apply on the fly, without an OS restart.

The Collector is bidirectional. It does not only send telemetry upward; it also receives instructions — a campaign to display, a remote action script to execute — which is what turns Nexthink from a monitoring tool into an operational one.

There are several endpoint agents, not one. Confusing them is a common source of deployment error:

Component	Purpose
Collector	The main endpoint agent for Windows, macOS and IGEL OS
VDI Client Extension	Sends VDI-related data from devices where Collector cannot be installed. Included as a component within Collector — install it standalone only on personal or unmanaged devices
Nexthink Mobile app	Collects performance data from company-managed mobile devices and from personal devices with a configured work profile
Nexthink browser extension	Collects web application data for performance monitoring, and enables Adopt guides
Amplify browser extension	A separate extension, for Amplify-licensed customers, which surfaces Nexthink insights in a pop-up inside the configured ITSM

Nexthink browser extension. The Collector can see that a browser process is running and how much CPU it consumes, but it cannot see inside it. The extension closes that gap: it lets Nexthink monitor, target and interact with websites, collecting website performance and usage data or displaying in-browser guidance depending on the product. The products that depend on it are Application Experience, Adopt and AI Drive.

It is available for Chrome (Web Store, extension ID miinajhilmmkpdoaimnoncdiliaejpdk), Edge (Edge add-ons) and other supported browsers. Deployment is normally via browser policy; a dedicated remote action can also deploy it, and for a new environment it can be installed through Collector — though that route is not recommended at scale because it can conflict with existing policies.

One deployment warning from the documentation is worth repeating: the remote action and the Collector install the extension by setting a registry key at the local machine level, which can overwrite existing browser-extension policies set at the current user level, potentially uninstalling them. Check existing policy with chrome://policy or edge://policy before deploying. Equally, without a proper browser policy in place, existing policies may strip the extension out and Applications will silently collect nothing.

If the extension is installed, usage data is collected by default, and this can be disabled; additional data such as web application URLs is gathered when configured.

Without the extension, web application experience data and Adopt guides do not work. This is the single most common cause of "why is the Applications module empty?"

Data retention and resolution

Two tiers of data coexist, and knowing which you are querying prevents a lot of confusion:

Tier	Granularity	Retention
Operational data	Granular and extensive event-level data	Up to 30 days
Trends	Event data aggregated into 1-day or 7-day samples, reduced to relevant metrics and properties	Up to 13 months
Software metering	Module-specific	Up to 90 days

Aggregation is what makes long retention affordable. For example, CPU load is sampled every 30 seconds and aggregated into stored values rather than kept sample by sample — which is also why count() on sampled events returns sample counts rather than event counts (Module 4).

Trends only appear after the system has collected enough operational data, so a newly configured module will look empty on long-range views for a while. That is expected, not a fault.

The platform layer

The cloud instance ingests, stores and indexes telemetry, computes scores, evaluates alert conditions, runs workflows, and serves the web interface and API. Key functional modules:

Module	Purpose
Experience Central	Landing surface — scores, trends, top issues, prioritisation
Investigations / NQL	Ad-hoc querying of the full data model
Live Dashboards	Curated, shareable visual views built on NQL
Campaigns	Employee-facing surveys delivered to the endpoint
Remote Actions	Scripts executed on endpoints for diagnosis or remediation
Alerts	Threshold and condition monitoring with notification
Workflows (Nexthink Flow)	Low-code orchestration across actions, campaigns and integrations
Applications	Application-centric experience and adoption views
Amplify	Contextual DEX data surfaced inside the service-desk tool
Adopt	In-application guidance and digital adoption
Library	Packaged content (dashboards, remote actions, campaigns, workflows) ready to import
Administration	Users, roles, permissions, hierarchies, connectors, configuration

Hierarchies and scoping — an underrated concept

A hierarchy is the organisational structure you overlay on devices and users: for example Region → Country → Site → Department. Hierarchies matter for three reasons:

Analysis — "which department has the worst experience" is only answerable if the platform knows what a department is.
Permissions — role-based access can be scoped so a regional admin sees only their region.
Targeting — campaigns, remote actions and guides can be aimed at a branch of the hierarchy.

Hierarchies are usually populated from Active Directory / Entra ID attributes or an imported CSV. Getting hierarchy design right early is one of the highest-value decisions in a deployment, because retrofitting it means re-scoping every piece of content you have already built.

Pitfalls

Deploying Collector without the browser extension, then concluding that web visibility "doesn't work."
Treating hierarchy as an afterthought; ending up with a flat estate where no comparison is meaningful.
Ignoring Collector version drift — an estate running four Collector versions produces inconsistent metric availability.

Self-check

What can the Collector see about a browser, and what can it not see?
Name three distinct uses of hierarchies.
Why is the Collector described as bidirectional?

Show answers

4. The Collector sees the browser as a process — CPU, memory, crashes, focus time. It cannot see inside it: pages, web application performance, or in-page errors. That requires the browser extension.

5. Analysis and segmentation; scoping role-based permissions; targeting campaigns, remote actions and guides.

6. It both sends telemetry to the platform and receives instructions from it — campaigns to display and remote actions to execute.

Module 3: The Digital Experience Score

Concepts

The DEX score condenses technical measurement and employee sentiment into a single interpretable figure. The scale is 0–100, computed daily, and it is deliberately employee-centric rather than device-centric: the documentation describes it as a solution focused primarily on employees, not their devices.

The structure has two branches rather than a flat list of dimensions:

DEX score  (0–100, combined)
├── Technology score
│   ├── Endpoint score      — device reliability and device performance
│   ├── Applications score  — smooth use and response time of applications
│   └── Collaboration score — collaboration tools (e.g. Teams, Zoom)
└── Sentiment score          — from a DEX score campaign

The Endpoint score reflects the ability of employees to start and use their device without interruption and with good response times; the Applications score reflects smooth application use and response time; the Collaboration score covers collaboration applications such as Microsoft Teams and Zoom, fed by the corresponding connectors. The Sentiment score comes from an employee's answer to an opinion-scale question about satisfaction with IT.

If no sentiment campaign is configured, the system computes the DEX score from the Technology score alone.

Bands and colour coding

The score maps to three experience levels, and these thresholds are the default:

Band	Range	Colour
Frustrating	0–30	Red
Average	31–70	Yellow
Good	71–100	Green

"Employees with issues" means employees scoring below 70 — that is, anyone in the average or frustrating bands. That definition catches people out: an employee at 65 is counted as having issues even though the band is labelled "average."

How the score is computed

Rolling window. The metrics behind the score are based on data from the past 7 days. The score is computed daily and stored as a punctual event at the computation time, even though it reflects the whole 7-day period.

This has a consequence that trips up almost everyone writing their first score query: querying the score data during past 7d returns seven daily data points, each of which is already a 7-day rolling window. That is usually not what you want. Take the latest value instead.

No data, no score. A user or device object with no data over the last 7 days has no score at all, rather than a zero. Absent scores and bad scores are different things.

Thresholds are configurable. Score metrics are configured per node with Average and Frustrating thresholds, under the Score metrics tab in Digital Experience Score Management. Baselining these to your own environment is an explicit part of the product design, not a workaround.

Structure changes are opt-in. Changes Nexthink pushes to the score structure — new default thresholds, new score-metric nodes — are not enabled automatically for existing customers, because they would move the overall score. You activate them deliberately from the Score metrics tab. This is a well-designed safeguard for trend integrity, and it means two tenants on the same release can be scoring differently.

Configuring the sentiment half

Sentiment requires a standardised DEX score campaign. You can download the sentiment campaign from the Nexthink Library, copy a default campaign, or build one from scratch, then enter its NQL ID on the Sentiment tab of the score configuration. Without that, you have a Technology score only.

The critical interpretive point

A score is a prioritisation instrument, not a diagnosis. It tells you where to look and gives IT and the business a shared, trendable number. Score movement is not evidence of a fault: scores also move because thresholds changed, because structure updates were activated, or because the population changed.

Three rules for using scores well:

Look at distribution, not just the average. A healthy organisational figure can conceal a substantial minority below 30. Those employees generate most of your tickets and all of your reputational damage.
Compare like with like. The product supports sorting scores by operating system, OS version, device type, manufacturer and model, and by country, state and department — use those breakdowns rather than comparing dissimilar populations.
Never change thresholds or activate structure updates silently. Both break the trend line. Record the date and annotate long-run charts.

Practice: decomposing a score drop

Split the DEX score into Technology and Sentiment — did the hard metrics move, the soft ones, or both?
Within Technology, identify which of Endpoint, Applications or Collaboration fell.
Drill into the contributing node. The interface lets you click through from a node to the underlying data, and in places opens Investigations with a pre-written NQL statement behind the score.
Segment by the technical and working-environment breakdowns — OS, model, country, department.
Correlate with change: deployments, patches, policy changes, agent updates.
Check whether a score-structure update or threshold change was activated in the same period before concluding anything about the estate.

That last step is the one people skip, and it is the cheapest.

Self-check

Why can an organisational average score be misleading?
What are the two top-level branches of the DEX score, and what feeds each?
Give two non-fault reasons a score could move.

Show answers

7. Averages conceal distribution. A healthy mean can hide a substantial minority in the frustrating band (0–30), and that minority generates most tickets and most dissatisfaction. Note also that "employees with issues" is defined as below 70, so a large group can sit in the average band without moving the headline much.

8. Technology score (Endpoint, Applications and Collaboration subscores, from telemetry and connectors) and Sentiment score (from an employee opinion-scale question in a configured DEX score campaign). If no sentiment campaign is configured, only Technology counts.

9. Changed Average/Frustrating thresholds, or activation of a Nexthink-pushed score-structure update; also a changed population, since objects with no data in the past 7 days have no score at all rather than a low one.

PART II — QUERYING AND CONTENT

Module 4: Nexthink Query Language (NQL)

NQL is the foundation under nearly everything else in the platform. Dashboards, alerts, score metrics, application metrics and workflow conditions are all NQL underneath. Time spent here pays back across every other module.

Concepts

NQL is a pipeline language: you name a table, then pass the result through a sequence of clauses separated by the pipe character, each transforming the stream. It is read-only — you can query data but not create or modify records.

Two practical constraints worth knowing up front: a query can be at most 16,000 characters, and the investigations editor shows 50 results by default with a Load more button for further batches. What you see is also filtered by the View domain permission on your role, so two people running the same query can legitimately get different result sets.

Specifying the table

Every query starts by naming a table as <namespace>.<table>:

execution.events

Five shortcuts let you drop the namespace: applications, binaries, campaigns, devices, users. So devices is equivalent to device.devices.

If you list no fields, the system returns a default set of fields most relevant to identifying the records.

Time frames

The time selection goes immediately after the table name, before any pipe:

execution.crashes during past 7d
execution.crashes on Feb 8, 2024

You can also apply a time frame to inventory objects — devices, users, binaries — in which case the system refers to the events behind that object's activity. These two are equivalent:

devices during past 7d

devices
| with device_performance.events during past 7d

Core clauses

Clause	Purpose
`where`	Filter rows by condition
`list`	Select which fields to display
`sort`	Order results — `sort size desc`
`limit`	Cap the number of results
`with`	Bring in related event data
`include`	Bring in related event data and keep objects without matches
`compute`	Append a metric per object; only usable after `with` or `include`
`summarize` / `summarize by`	Aggregate, optionally grouped by field or time period

Note the syntax: it is sort size desc, not sort by size desc. The by belongs to summarize by, not to sort.

Comparison and pattern matching

The comparison operators are == (or =), !=, >, <, >=, <=. String comparison is case-insensitive.

There are no startswith, endswith or contains operators. Partial matching uses wildcards inside the compared string:

Wildcard	Meaning	Example
`*`	Any number of characters	`where application.name = "Microsoft*"` — names starting with Microsoft
		`where application.name = "Microsoft"` — names containing Microsoft
`?`	Any single character	`where device.operating_system.name == "Windows 1?"`

Logical operators include in for list membership:

| where package.name in [ "MS Teams", "Zoom" ]

Combine conditions with and / or.

Functions

The aggregation functions are avg(), count(), countif(), sum(), sumif(), min(), max(), last(), as() and time_elapsed(), plus a set of datetime functions. Syntax is <metric>.<function>().

There is no dcount(). This matters, because counting distinct objects is a core analytical need. The mechanism in NQL is <object>.count(), which counts unique inventory objects rather than events:

devices during past 7d
| include execution.events during past 7d
| compute number_of_devices = device.count()

Two further traps around counting:

Used with summarize, count() always returns the number of records in the root table — so on a devices root it counts devices, not events. To count events in that position, use sum() on the aggregated metric instead.
count() is not recommended on sampled events, because it returns the number of data samples rather than the actual number of events.

Also distinguish aggregated metrics (fields stored in the data model — <metric>.avg, .sum, .count, .min, .max, used in where) from smart aggregates (computed on the fly — <metric>.avg(), .sum(), etc., used in compute and summarize). The dot-with-parentheses distinction is easy to miss and produces confusing errors.

Worked examples

1. Filter, project, order, cap

binaries during past 24h
| where binary.name == "dllhost.exe"
| list name, version, platform, architecture, size
| sort size desc
| limit 10

Filter first, then project, then order, then cap. Filtering before projecting reduces what flows through the rest of the pipeline.

2. Crash counts grouped by time

execution.crashes during past 7d
| summarize total_number_of_crashes = count() by 1d
| sort start_time asc

summarize ... by 1d groups by day rather than by a property — useful for trend widgets.

3. Crashes by OS for one application

execution.crashes during past 31d
| where application.name == "Microsoft 365: Teams"
| summarize number_of_crashes_ = number_of_crashes.sum() by context.os_name

Two things here. The trailing underscore on the metric name is deliberate: metric names cannot collide with existing field names, and appending an underscore is the documented workaround — the results display the original header without it. And context.os_name is the OS recorded at the time of the event, whereas device.operating_system.name is the OS now; on a device that upgraded yesterday, these differ.

4. Counting distinct affected devices

devices during past 7d
| include execution.crashes during past 7d
| compute number_of_crashes = count()
| where number_of_crashes > 0

The analytical point remains the most important one in this module: many crashes on few devices is a device problem; moderate crashes across many devices is an application problem. Because there is no dcount(), you get at this by rooting the query on the object table and counting per object, rather than by counting distinct values inside a flat event aggregation.

5. Boots per device

devices during past 7d
| include device_performance.boots during past 7d
| compute nb_boots = count()

6. Wildcards and escaping

binaries during past 24h
| where binary.name == "dll*.exe"
| list size, name, version
| sort size desc
| limit 100

Backslash is the escape character in literal strings — \", \\, and \\u#### for Unicode. Windows paths therefore need doubling: "C:\\Program Files\\".

Naming rules

Computed metric names may use letters, numbers, dashes and underscores only; no spaces, no leading digit, case-insensitive. They cannot match an existing field name — append an underscore to avoid the collision.

Content items such as campaigns and custom fields have an NQL ID, which starts with #, uses lowercase letters, numbers and underscores, and strips accents. For example a campaign named "Application Survey – Québec" generates #application_survey_quebec. You reference content items by these IDs elsewhere in the product, which is how a campaign gets wired into the DEX score.

Comments

Use /* and */. Comments are valid in most positions but not between a pipe and its keyword, inside expressions, between an operator and its operand, or inside function calls. Ctrl + / (Windows) or Cmd + / (macOS) toggles a line comment in the editor.

Query design method

State the question in words first. If you cannot state it, you cannot query it.
Choose the root table deliberately. Rooting on an object table (devices) versus an event table (execution.crashes) changes what count() means and what you can compute. This is the single most consequential structural decision in an NQL query.
Set the narrowest useful time frame. Widen only once the logic is correct.
Filter early.
Aggregate deliberately — events, objects, or both.
Segment with summarize ... by to answer "is it everyone or someone."
Sort and limit.
Validate against a device you can inspect. A query that runs is not a query that is correct.

Pitfalls

Assuming KQL or SQL habits transfer. No dcount, no dedup, no startswith, and sort without by. The pipeline shape is familiar; the vocabulary is not.
Misreading count() under summarize — it counts root-table records, not events.
Using count() on sampled events, which counts samples.
Confusing .avg with .avg() — a stored field versus a computed aggregate.
Confusing context.os_name with device.operating_system.name — event-time versus current state.
Querying score data with during past 7d — each point is already a 7-day rolling window.
Averaging away the problem. Averages hide tails; segment and look at the frustrating band rather than the mean.

Self-check

Why does the choice of root table matter so much for what count() returns?
How do you count distinct devices, given that NQL has no dcount()?
What is the difference between context.os_name and device.operating_system.name?

Show answers

10. Under summarize, count() always returns the number of records in the root table. Rooted on devices it counts devices; rooted on an event table it counts events. To count events from an object root, use sum() on the aggregated metric instead.

11. Root the query on the object table and use <object>.count() — for example compute number_of_devices = device.count() after an include — which counts unique inventory objects rather than events.

12. context.os_name is the operating system recorded at the time the event occurred; device.operating_system.name is the device's current operating system. They differ for any device that has been upgraded within the query window.

Module 5: Investigations with the Visual Editor

Concepts

The visual editor is a graphical query builder that produces the same result as hand-written NQL. Its purpose is to remove the syntax barrier so that a support engineer can ask a precise question on day one rather than in month three.

The workflow mirrors the NQL pipeline: pick a data source, add filters through form controls, choose aggregation and grouping, select fields to display, and set sort order and result limits.

How to use it well

The most valuable habit is to build in the visual editor, then read the generated NQL. Most implementations expose the underlying query. Treating the editor as a syntax tutor rather than a permanent crutch is how support engineers become platform power users. You get the answer now and the skill over time.

The editor's practical limits appear when you need multi-stage logic, derived computed fields, or combinations the form controls do not express. That is your cue to switch to NQL, and by then you will have read enough generated queries to do it.

Practice walkthrough: "Finance says Excel is slow"

Source: application execution / performance events. Time: past 7 days.
Filter: binary name matches the Excel executable; department equals Finance.
Aggregate: count of not-responding events and distinct device count, grouped by device.
Sort: descending by not-responding events.
Read the result: if five devices dominate, this is a device problem — check their hardware, memory pressure and installed add-ins. If the distribution is flat across two hundred devices, this is an application, file-location or add-in-policy problem.
Widen: re-run grouped by device model, OS build, and file location (local vs network share) to test each hypothesis.

That escalation-from-symptom-to-segmentation pattern generalises to almost every ticket you will investigate.

Self-check

When should you stop using the visual editor and switch to raw NQL?
In the Excel example, what does a flat distribution across many devices tell you?

Show answers

13. When you need multi-stage logic, computed fields, or combinations the form controls cannot express — and by then you should have been reading the generated NQL long enough to write it.

14. That it is not a device-specific problem — look at the application version, add-ins, file location (network vs local), or a recent policy or deployment change affecting the whole group.

Module 6: Live Dashboards and data visualisation

Concepts

A dashboard is a curated set of NQL-backed widgets, refreshed against live data, designed for a specific audience and a specific decision. That last clause matters: dashboards fail when they are built to display everything available rather than to answer a defined question for a defined reader.

Choosing the right visualisation

Widget	Best for	Avoid when
KPI	A single headline number, optionally with trend and threshold colour	You need to compare across categories
Gauge	One value against a target or threshold range	The value has no meaningful target; more than one metric
Table	Detail, ranked lists, drill-through to specific devices or users	The audience needs a pattern, not records
Line / time series	Trend and change over time	You have fewer than a handful of time points
Bar / column	Comparison across categories, top-N	Categories exceed roughly a dozen

On gauges specifically. A gauge encodes one number against a range. It is excellent for a score against a target and poor at almost everything else — it consumes a great deal of screen space for a single value. Use a gauge when the reader's question is "are we within tolerance right now?" Use a line chart when the question is "which way are we heading?" Most dashboards benefit from having exactly one gauge, or none.

On KPI widgets. The KPI plus trend indicator is the highest information-density element available. A number, a direction, and a threshold colour answer "what, which way, and is it OK" in one glance. Build the top row of every dashboard from these.

On tables. Tables are where dashboards become operational rather than informational, because a table row is usually an actionable item — a device to fix, a user to contact. Make sure table columns include enough identity to act on (device name, user, department) and not just metrics.

Dashboard design principles

Design for one audience. An executive dashboard and a service-desk dashboard should never be the same artefact. Executives want three numbers, a trend, and no jargon. The service desk wants ranked tables they can work through. Trying to serve both produces something that serves neither.

Follow the inverted pyramid. Top row: headline KPIs. Middle: trends and breakdowns explaining the headline. Bottom: detail tables for action. A reader should be able to stop at any row and have a complete, coherent picture at that level of detail.

Every widget earns its place. For each one, answer: what decision does this change? If a widget has never changed anyone's behaviour, remove it. Dashboards decay by accretion.

Label thresholds explicitly. A red number with no stated threshold generates arguments instead of actions. State "target < 60s" on the widget.

Set an appropriate time window per widget. A "current state" KPI over a 90-day window is not current state. Mixed windows on one dashboard need visible labels or you will mislead your own readers.

Filter at the dashboard level. A well-built dashboard with hierarchy and time filters at the top serves twenty regional managers; twenty dashboards serve twenty managers and cost twenty times as much to maintain.

Practice: building a service-desk dashboard

Audience: L1/L2 team leads. Decision: what should the team work on today?

Top row (KPI): devices below score threshold; open critical alert count; devices with crash events in 24h; average boot time trend.
Middle (charts): score trend over 30 days; top ten applications by distinct affected devices; breakdown of failing devices by model.
Bottom (tables): the specific devices below threshold with owner and department; devices with repeated crashes ranked by frequency; devices missing the current Collector or extension version.
Filters: hierarchy, time window, device model.

Each bottom-row row is a task. That is what makes it a working dashboard rather than a wall display.

Pitfalls

Building dashboards nobody asked for and nobody opens.
Averaging across the whole estate on every widget, hiding every real problem.
Using pie charts for anything with more than three categories.
Leaving no path from "something is wrong" to "here is which device."

Self-check

What single question should you be able to answer about every widget on a dashboard?
Why should executive and service-desk dashboards be separate artefacts?

Show answers

15. What decision does this widget change? If none, remove it.

16. They serve different decisions. Executives need a small number of interpretable indicators and trend; the service desk needs actionable ranked detail. A single artefact serving both serves neither well.

Module 7: Campaigns — collecting employee sentiment

Concepts

A campaign is a short survey delivered directly on the employee's device by the Collector, rather than by email. That delivery mechanism matters enormously: response rates for in-context, on-device prompts vastly exceed those for emailed survey links, because the prompt arrives in the flow of work and takes seconds.

Campaigns supply the "soft" half of DEX data. They also produce something telemetry cannot: intent and perception. Telemetry can tell you a video call had packet loss. Only the employee can tell you they gave up and used their phone.

Campaign types by purpose

Type	Trigger	Example question	Use
Baseline / periodic	Scheduled, recurring	"How satisfied are you with your laptop?"	Trend sentiment over time; feeds the score
Targeted diagnostic	Sent to a defined population	"Have you experienced freezes in [app] this week?"	Confirm or refute a hypothesis from telemetry
Post-event / triggered	After a technical event or remediation	"Did that fix resolve your issue?"	Validate remediation actually worked
Change / rollout	Before, during, after a deployment	"How easy was the migration to [tool]?"	Measure change impact
Informational	Broadcast	Notification with acknowledgement	Communicate, not survey

The triggered post-remediation campaign is the most underused and most valuable of these. It closes the loop between "we ran a fix" and "the employee's experience improved," which is exactly the evidence a DEX programme needs to justify itself.

Designing questions that work

Keep it to one to three questions. Every additional question reduces completion and increases annoyance. If you need ten answers, you need a different instrument.

Ask about experience, not technology. "Is your laptop slow?" is answerable. "Are you experiencing memory pressure?" is not, and the answers you get will be noise.

Use a consistent scale. Pick one rating scale and use it everywhere. Mixing 1–5 and 1–10 across campaigns makes longitudinal comparison impossible.

Make the follow-up conditional. Branch so that only dissatisfied respondents get the "what is the main problem?" question. This respects the time of the satisfied majority and increases the quality of the responses that matter.

Always include a free-text option on diagnostic campaigns, but expect to read them qualitatively rather than aggregate them.

Timing and fatigue management

Campaign fatigue is the primary failure mode. Rules that keep it under control:

Set a global frequency cap per employee across all campaigns, not per campaign.
Never prompt during focus-sensitive activity — mid-presentation, mid-call, immediately at logon.
Deduplicate: an employee who answered a baseline survey this week should not receive a targeted one too.
Make responses visibly consequential. Response rates collapse when employees conclude that nothing happens. Where possible, close the loop: "you told us X; we did Y."

Practice: a diagnostic campaign

Situation: telemetry shows elevated Teams call quality problems in one office, but the network team reports no issues.

Population: employees in that office who joined at least three calls in the past week (defined by NQL).
Question 1: "In the past week, how would you rate the quality of your video calls?" (1–5).
Question 2, conditional on 1–2: "What did you experience most?" (choices: audio dropouts / video freezing / could not join / others could not hear me / other).
Question 3, conditional: free text.
Analysis: cross-reference responses against device model, headset, network connection type and Wi-Fi access point.
Outcome: if the dissatisfied cluster shares a device model or headset driver, the network team was right and it is an endpoint problem.

Pitfalls

Surveying without a plan for what you will do with the answers.
Long surveys, which produce a biased sample of the unusually patient.
Asking about technical internals rather than experience.
Never closing the loop, which trains employees to dismiss the prompt.

Self-check

Why does in-product delivery outperform email survey links?
What makes a post-remediation triggered campaign so valuable to a DEX programme?

Show answers

17. It arrives in the flow of work, in context, and takes seconds to answer — no inbox, no click-through, no context switch. Response rates are substantially higher and less biased.

18. It provides direct evidence that a technical remediation improved the employee's actual experience, which is the causal link a DEX programme needs to justify its existence.

Module 8: Remote Actions

Concepts

A remote action is an executable script that accepts parameters and optionally returns outputs to Nexthink's data layer, where they feed dashboards, support investigations and enrich device and user data. Windows uses PowerShell; macOS uses shell scripts.

Remote actions are what make Nexthink operational rather than observational. Three purposes:

Purpose	Description
Information gathering	Collect something that resides only on the device — a registry value, a certificate expiry, a config file setting
Remediation	Fix a known condition
Prevention	Act before failure, silently and at fleet scale

They can be run on demand, on a schedule, from automated processes, from workflows, through the Remote Actions API (so a self-service portal or ticketing system can trigger them), and they can be exposed for employee self-service.

The platform ships system remote actions that are auto-installed with the module, plus more in Library packs. System remote actions do not count against your maximum licence count. Check what already exists before writing your own — a large fraction of common needs is already covered.

Mechanics

A definition comprises the script, input parameters, output parameters, targeting, trigger, execution context and a timeout.

Parameters. When you upload a PowerShell script, the system reads its param() block and lists the parameters for you to fill in. Values are always passed to the script as text, so if you declare a non-string type, supply something convertible.

Outputs. You may define up to 50 outputs, each with a name, description and data type. Outputs are written through a .NET assembly, nxtremoteactions.dll, installed on the device alongside the Collector. It exposes a class called Nxt with write methods that each take an output name and a value:

Add-Type -Path "$env:NEXTHINK\RemoteActions\nxtremoteactions.dll"

[Nxt]::WriteOutputString("Status", $Status)
[Nxt]::WriteOutputSize("FileSize", $FileSize)

When you upload the script, the system detects these calls and lists the output variables under the Outputs section. This is the mechanism by which a remote action extends the data model — outputs become queryable.

Success and failure are determined by the exit code of the PowerShell process: 0 is success, non-zero is an error. Unhandled exceptions can terminate a script without setting an appropriate exit code, so Nexthink recommends starting every script with a default error handler, placed after the DLL inclusion and the parameter declaration.

Execution context is chosen at configuration time:

Context	Use for
Local system user (default)	Tasks needing system rights — uninstalling software, reading drivers or registry keys
Interactive user	Actions for a specific logged-on user — their recycle bin size, closing an application they have open
Service	Running under a dedicated service account, e.g. on a Windows proxy server to update Active Directory. Windows and PowerShell only, requires service setup on the target and Collector 24.5 or later

Choosing wrong is a classic failure: run a per-user task as Local system user and you get the system account's recycle bin, or you try to close applications the system account is not running.

Timeout is set in seconds; the system terminates the script if it overruns.

Example: service health check and remediation

param (
    [string]$ServiceName = "Spooler"
)

Add-Type -Path "$env:NEXTHINK\RemoteActions\nxtremoteactions.dll"

$Status = "Unknown"
$ActionTaken = "None"

$Service = Get-Service -Name $ServiceName -ErrorAction SilentlyContinue

if ($null -eq $Service) {
    $Status = "NotInstalled"
} elseif ($Service.Status -ne "Running") {
    try {
        Start-Service -Name $ServiceName -ErrorAction Stop
        $Status = "Recovered"
        $ActionTaken = "Started"
    } catch {
        $Status = "FailedToStart"
        $ActionTaken = "StartAttemptFailed"
    }
} else {
    $Status = "Healthy"
}

[Nxt]::WriteOutputString("Status", $Status)
[Nxt]::WriteOutputString("ActionTaken", $ActionTaken)

Note the structure: outputs are initialised before the branching, and every path leaves both set. A remote action that returns nothing on failure is one you cannot report on — and failure rates are exactly what you need to see.

Safety discipline

Remote actions execute code on thousands of endpoints. Treat them as fleet-wide change.

Ring deployment, always. Test devices → IT department → pilot → region → fleet.

Make them idempotent. Running twice must be safe. Scripts get retried, triggered by overlapping conditions, and re-fired by workflows.

Target precisely by NQL condition, so the action reaches only devices that exhibit the problem.

Return structured status — success, failure, no-action-needed, error reason — then build a dashboard on those outputs and monitor execution statistics.

Fail safe, not silent. Use the recommended default error handler and make sure the exit code reflects reality.

Version and review. Fleet-wide scripts deserve peer review and change control.

Consider employee impact. An action that restarts a service, closes an application or forces a reboot should be scheduled sensitively or paired with a campaign that asks first. Combining remote actions with campaigns to detect, fix and notify — without involving the support team — is a documented design pattern, not an improvisation.

Pattern: detect → confirm → act → verify

Detect the condition via NQL or an alert.
Confirm with an information-gathering remote action, since telemetry can be stale.
Act with a remediation action, scoped to confirmed devices.
Verify with a follow-up query and, ideally, a post-remediation campaign.

That is also precisely what workflows automate (Module 15).

Self-check

Why must remote actions be idempotent?
How does a PowerShell remote action return data to Nexthink, and how does the platform decide whether it succeeded?
What is the risk of choosing the wrong execution context?

Show answers

19. Because they get retried after transient failures, triggered by overlapping alert conditions, and re-fired by workflows. A non-idempotent action can compound damage on the second run.

20. By loading nxtremoteactions.dll and calling the Nxt class write methods, each taking an output name and value — for example [Nxt]::WriteOutputString("Status", $Status). Success is judged by the process exit code: 0 means success, non-zero means error. Because unhandled exceptions can bypass the exit code, scripts should start with a default error handler.

21. Local system user cannot access per-user state (the user's recycle bin, their open applications, per-user registry); Interactive user needs a logged-on user and runs with their rights; Service requires a configured service account and Windows PowerShell. Choosing wrong produces actions that appear to work in testing and return the wrong thing — or nothing — at scale.

Module 9: Alerts

Concepts

Alerts move the platform from "someone looks at a dashboard" to "the platform tells someone." An alert is a condition — usually an NQL query with a threshold — evaluated on a schedule, which raises a notification and, optionally, triggers a workflow when it is met.

There are two broad alert shapes:

Threshold alerts — a metric crosses a fixed line. "More than 50 devices with boot time over 180 seconds." Simple, predictable, easy to explain.

Change / anomaly alerts — a metric departs from its own baseline. "Crash rate for this application is triple last week's." Better at catching new problems, harder to tune.

⚠ Available alert types, evaluation frequencies and notification channels vary by version.

Designing alerts that get acted on

The failure mode of alerting is universal across every monitoring tool ever built: too many alerts, so people stop reading them. Discipline in design is the whole game.

Every alert needs an owner and an action. Before creating one, answer: who receives this, and what do they do when it fires? If either answer is missing, the alert is decoration.

Set thresholds from your own baseline. Query the metric's distribution over the past month first. Set the threshold where it would have fired a useful number of times — a handful, not hundreds.

Alert on impact, not on events. "Application X crashed 500 times" may be one broken device. "Application X crashed on more than 50 distinct devices" is an incident. Use distinct entity counts in alert conditions almost always.

Require persistence. A condition that must hold for two consecutive evaluations eliminates most transient noise.

Match severity to response. Reserve the highest severity for conditions that genuinely warrant interrupting someone. If everything is critical, nothing is.

Review quarterly. Track fire counts per alert. Any alert that has fired fifty times without producing an action should be retuned or deleted. Any that has never fired should be tested — a silent alert is often a broken one.

Practice: a well-formed alert

Condition: distinct devices exhibiting boot time above 180 seconds, in the past 24 hours, exceeds 25, sustained across two consecutive evaluations. Severity: High. Owner: Endpoint engineering team. Runbook: Open the linked dashboard; segment by model and OS build; if concentrated in one model, check recent driver or firmware deployment; if spread, check for a recent policy or security agent change; run the boot-analysis remote action against affected devices. Automation: trigger the diagnostic workflow that gathers boot phase detail on the affected devices.

The runbook is not optional. An alert without a documented response is a notification that generates anxiety rather than resolution.

Self-check

Why should alert conditions usually count distinct devices rather than events?
What are the two questions to answer before creating any alert?

Show answers

22. Because event counts can be dominated by a handful of pathological devices, producing alerts that fire on a single broken machine rather than on genuine fleet-wide impact.

23. Who receives this, and what will they do when it fires? If either has no answer, do not create the alert.

PART III — PLATFORM OPERATIONS

Module 10: Platform administration

Collector deployment and lifecycle

Deployment is normally through your existing endpoint management tooling — Intune, SCCM, Jamf, or equivalent — using a package configured with your tenant endpoint and credentials.

Planning considerations:

Consideration	Why it matters
Coverage target	Partial deployment produces partial data and misleading fleet metrics
Phasing	Ring deployment applies here too: pilot, then department, then fleet
Version consistency	Mixed versions mean inconsistent metric availability and confusing gaps
Update mechanism	Automatic updating with a controlled ring plan is the usual choice
Coexistence	Verify behaviour alongside security agents; add mutual exclusions where recommended
Network path	Endpoints must reach the cloud instance, including from VPN and split-tunnel configurations
Health monitoring	Monitor the agent fleet as a fleet: reporting devices vs expected devices

Treat Collector coverage as a first-class metric. Build a dashboard showing expected devices (from your CMDB or directory) versus reporting devices, broken down by hierarchy. Silent coverage decay is one of the most common quiet failures in a deployment, and it corrupts every metric above it.

Browser extension deployment

Deploy via browser management policy rather than asking users to install it: Chrome and Edge policies through group policy, Intune or the respective admin consoles; Firefox through enterprise policy.

Key points:

Force-install rather than allow-install. Voluntary installation produces a biased and incomplete population.
Cover every managed browser. A fleet where half the users are on Edge and half on Chrome, with the extension in only one, produces data you will misread.
Communicate before deploying. A silently appearing extension generates privacy concerns and help-desk tickets. Explain what it does and what it does not collect.
Be explicit about privacy scope internally. Know and be able to state what the extension observes so you can answer the works council, the privacy team and individual employees credibly.
Verify coverage after rollout and monitor it continuously alongside Collector coverage.

Configuration and UI customisation

Administrative configuration typically covers users and roles, role-based access scoping (often by hierarchy), hierarchy definition and import, data privacy and anonymisation settings, retention configuration, and interface customisation such as default landing pages and branding.

Two principles worth holding to:

Least privilege by default. Most users need read access to a scoped set of content. Remote action execution and workflow publishing are powerful capabilities and should be deliberately granted, not assumed.

Privacy settings are a design decision, not a checkbox. Anonymisation options, what is visible to whom, and retention periods should be agreed with privacy and employee-representative stakeholders before rollout, and documented. In several jurisdictions this is a legal requirement, not a courtesy — and in all of them, a DEX programme that is perceived as surveillance will fail politically regardless of its technical merit.

Self-check

Why is Collector coverage itself a metric worth dashboarding?
Why force-install the browser extension rather than allowing opt-in?

Show answers

24. Because every other metric depends on it. Silent coverage decay corrupts all fleet-level analysis without producing any visible error.

25. Voluntary installation produces incomplete and biased coverage, which yields web application data that misrepresents the estate.

Module 11: Integrations — inbound connectors, webhooks and data export

Concepts

A DEX platform that only knows about endpoints is limited. Integration works in three directions:

Direction	Mechanism	Purpose
Inbound	Connectors	Bring external data in to correlate with experience data
Outbound (event)	Webhooks	Push events out to trigger action in other systems
Outbound (bulk)	Bulk data export	Move large datasets to a warehouse, lake or BI platform

Inbound connectors

Inbound connectors ingest third-party performance or contextual data so it can sit alongside endpoint telemetry. Typical sources include service management systems, identity providers, endpoint management platforms, network and infrastructure monitoring, and SaaS application usage data.

The value is correlation. Endpoint data alone tells you a device is slow. Endpoint data plus ticket data tells you that slow devices generate 3.2× the ticket volume, which is a number that funds a hardware refresh. Endpoint data plus CMDB data lets you segment by asset age and lease date.

Practical guidance: start with one connector that answers a specific question you already have. Connector projects that begin with "let us bring in everything" produce large data volumes and no insight.

Webhooks

A webhook sends a structured HTTP request to an external endpoint when something happens — an alert fires, a workflow reaches a step, a condition is met. It is the mechanism by which Nexthink causes action in systems it does not control.

Design guidance for reliable webhooks:

Design the payload deliberately. Include enough context for the receiving system to act without calling back: device identity, user, condition detected, severity, timestamp, and a link back to the relevant view. A webhook that says "something happened" forces a lookup and defeats the purpose.

Handle authentication properly. Use token or key-based authentication, store secrets in the platform's credential store rather than in URLs, and rotate them on a schedule.

Assume delivery can fail. Understand retry behaviour and whether the receiver is idempotent. A retried ticket-creation webhook against a non-idempotent endpoint produces duplicate tickets, which is worse than no ticket.

Include a correlation identifier so that events can be traced end to end across systems during debugging. You will need it.

Test against a request-capture endpoint first, then a sandbox of the target system, then production. Never develop webhooks directly against a production ITSM instance.

Rate-limit awareness. A fleet-wide condition can fire thousands of webhooks in minutes. Confirm what the receiving system tolerates and aggregate where appropriate.

Bulk data export

Bulk export moves large volumes on a schedule to a destination such as cloud object storage, for use in a data warehouse or BI tool. Use it when the question you want to answer requires joining DEX data with data that will never live in Nexthink — HR data, financial data, multi-year historical analysis beyond platform retention.

Do not use it to rebuild dashboards you could have built natively. Exported data is a copy, and copies drift, cost money and require their own pipeline maintenance.

Self-check

What does correlating ticket data with endpoint data let you demonstrate that neither can alone?
Why does webhook idempotency matter?

Show answers

26. The correlation between poor experience and ticket volume or cost — the quantified business case that neither dataset supports alone.

27. Because delivery retries are normal, and a non-idempotent receiver turns a retry into duplicate tickets or duplicate actions.

PART IV — OPERATING AND SUPPORTING

Module 12: L1 support with Amplify

Concepts

Amplify brings DEX context into the tool where support agents already work, rather than requiring them to switch to a separate console. The design intent is that an agent handling a ticket sees the device's health, recent events and available remediations in the same pane as the ticket.

Why context placement matters so much

The economics of tier-one support are dominated by two numbers: average handle time and escalation rate. Both are driven heavily by information gathering. A large portion of a typical call is the agent asking the employee questions the platform already knows the answer to — device model, OS version, when it last rebooted, what crashed, whether the network is degraded.

Surfacing that context does three things:

Cuts handle time, because the diagnostic conversation is replaced by reading.
Cuts escalation, because an agent with evidence and a one-click remediation can resolve what previously had to be passed on.
Improves the employee's experience of support, because the agent appears to already understand the problem. This effect is easy to dismiss and is often the largest perceived improvement.

What good L1 practice with DEX context looks like

Read before asking. Open the device context first. Confirm rather than interrogate: "I can see your laptop has restarted three times since Monday" is a different conversation from "have you tried restarting?"

Check whether it is one person or many. Before treating a report as an individual issue, check whether the same symptom appears across a department, model or location. This is the single highest-value habit for an L1 agent, because it converts a stream of individual tickets into one identified incident.

Use guided remediation rather than ad-hoc fixes. Pre-built, approved remote actions exposed to L1 are safe and auditable in a way that improvised local fixes are not.

Record the outcome. Whether the remediation worked is the data that improves the remediation library.

Escalate with evidence, not narrative. An escalation that includes the device's telemetry and what was already tried saves the L2 engineer the entire rediscovery step.

Practice: a call with and without DEX context

Without: "My laptop is slow." Agent asks a series of questions, receives partial answers, attempts a generic fix, escalates. Twelve minutes, unresolved, one escalation.

With: Agent opens context, sees memory pressure at 94% for three days, sees a specific process consuming it, sees eleven other devices in the same department with the same profile since a software deployment last Tuesday. Agent runs the approved remediation, confirms the metric drops, and raises one problem record covering all twelve devices. Four minutes, resolved, one problem record instead of twelve future tickets.

The second version is the actual value proposition of DEX in support, and it depends less on the tool than on the agent's habit of asking "is this one person or many?"

Self-check

What is the highest-value habit for an L1 agent with DEX context available?
Why does escalating with telemetry attached reduce total resolution effort?

Show answers

28. Checking whether the reported symptom affects one person or many before treating it as an individual issue — this converts streams of tickets into identified incidents.

29. It eliminates the rediscovery step, so the L2 engineer starts from evidence and from what has already been ruled out rather than from the beginning.

Module 13: Troubleshooting methodology

This module is about method rather than features. The features are covered elsewhere; what distinguishes a strong analyst is the routine they apply.

The universal DEX troubleshooting sequence

1. Characterise the symptom precisely. "Slow" is not a symptom. "Application takes 45 seconds to open a file from the network share, on first open only, since Monday" is. Push for specificity before touching the platform.

2. Establish scope: one, some, or all. Query the symptom across the estate. This single step determines everything that follows:

Scope	Likely cause class	First move
One device	Local state, hardware, profile corruption	Device-level detail; consider rebuild vs repair
One model / OS build	Driver, firmware, image	Compare against another model as control
One location / network	Network path, local infrastructure	Correlate with network telemetry
One department / group	Policy, group-scoped software, workflow difference	Compare group configuration
One application, everywhere	Application version, back end, integration	Correlate with deployment and back-end events
Everything, everywhere	Platform-wide change	Check change records first

3. Establish timing. When did it start? Correlate the start point against your change record: deployments, patches, policy changes, agent updates, certificate rotations, back-end releases. The overwhelming majority of new problems are caused by a change, and the correlation of onset time with change time is the fastest available diagnostic.

4. Find a control group. Identify a population that should have the problem but does not, or vice versa. The difference between the affected and unaffected sets is your cause. This is the most underused technique in IT troubleshooting and the most reliable.

5. Form one hypothesis and test it. Write it down as a falsifiable statement: "if the cause is the new driver version, then devices still on the previous version will not show the symptom." Query that. Do not change three things at once.

6. Confirm with sentiment. For experience issues, verify with a targeted campaign that the technical symptom corresponds to actual employee impact. Sometimes it does not, and that is worth knowing before you spend a sprint on it.

7. Remediate, verify, and prevent. Fix the affected population, verify the metric moves, then ask what stops recurrence — a build change, a policy change, a proactive alert.

Web application issues specifically

Web issues are harder because the failure can live in the browser, the extension ecosystem, the device, the local network, the corporate network path, the identity provider, a CDN, or the application back end. A structured elimination order:

Is it the whole application or one page/function? One function points at the back end or a specific integration.
Is it all browsers or one? One browser points at an extension, a browser policy, or a rendering/compatibility issue.
Is it all locations or one? One location points at network path, proxy, or local DNS.
Is it all users or one group? One group points at permissions, licence tier, or identity configuration — a slow experience is quite often an authentication or authorisation retry loop rather than a performance issue.
Where in the load sequence is the time going? Time to first byte versus rendering time separates back-end and network causes from client-side ones.
Are there client-side errors? Page-level errors captured by the extension often name the failing component directly.
Is the device itself constrained? A browser cannot be fast on a device at 98% memory pressure with forty tabs open; check that before blaming the application.

Step 4 deserves emphasis. Authentication problems — token renewal loops, conditional access re-evaluation, misconfigured SSO — routinely present to users as "the app is slow" and routinely get misrouted to application teams. Checking whether the affected population maps to an identity group rather than a network or device group catches these early.

Pitfalls

Investigating the reported cause rather than the observed symptom. Users diagnose; treat their diagnosis as a hypothesis, not evidence.
Changing several things at once, making the eventual fix unattributable.
Stopping at remediation without asking what prevents recurrence.
Failing to check the change record first, which would have answered it in two minutes.

Self-check

Why is establishing scope the second step rather than a later one?
What is a control group in this context, and why is it so effective?
Why do authentication problems frequently get misdiagnosed as performance problems?

Show answers

30. Because scope determines the entire class of likely cause and therefore which investigation path is worth pursuing. Investigating a fleet-wide change as a device problem wastes hours.

31. A population that should exhibit the symptom but does not (or vice versa). The difference between the affected and unaffected sets isolates the cause faster than any amount of examining affected devices alone.

32. Because token renewal loops, conditional access re-evaluation and SSO misconfiguration present to users as slowness, and the affected population maps to an identity group rather than to a device or network group — so scope analysis misroutes them unless identity is one of the segments tested.

Module 14: Application Experience Management

Concepts

The Applications module shifts the unit of analysis from the device to the application. This matters because budget, ownership and vendor negotiation are all organised by application, not by laptop. "Which of our applications delivers the worst experience, to how many people, at what licence cost" is a question that changes decisions.

Application experience has two halves:

Performance and reliability — is the application fast and stable for the people using it? Load times, errors, crashes, freezes, availability from the employee's perspective.

Adoption and usage — is it being used at all, by whom, how often, and which features? This half connects DEX to licence management and to change programmes.

Configuring the module

Configuration generally involves defining the applications you care about — mapping web applications to their domains and URL patterns, and desktop applications to their executables — then deciding what constitutes meaningful use, and setting the thresholds against which experience is judged.

⚠ The specific configuration model and terminology vary by version; check current documentation for exact steps.

Three configuration decisions worth thinking about carefully:

Define the application boundary correctly. A single business application may span several domains, or a domain may host several applications. Getting this wrong means your metrics measure something other than what you named them.

Define "active use" deliberately. Is opening the application use? Thirty seconds of focus? A completed transaction? Licence reclamation decisions depend on this definition, and a loose one will get challenged the moment you propose removing someone's licence.

Set thresholds per application, not globally. Three seconds is poor for a lightweight internal tool and excellent for a heavy engineering application. Global thresholds produce a ranking of application weight rather than application quality.

Measuring adoption

Adoption analysis usually answers four questions:

Reach — how many licensed employees have used it at all in the period?
Frequency — how often do users return? Daily, weekly, occasional?
Depth — which parts of it are used? Breadth of feature use separates real adoption from token use.
Trend — is usage growing, flat or declining since rollout?

The classic finding is a large gap between licensed and active populations. That gap has three possible explanations, and distinguishing them is the analytical work:

Explanation	Evidence	Response
People do not need it	Consistent zero use, no complaints	Reclaim licences
People cannot use it well	Use starts then stops; poor experience metrics; negative sentiment	Fix experience, then re-measure
People do not know how	Low feature depth; high use of an older alternative	Guidance and enablement (Adopt — Module 15)

Jumping to licence reclamation without excluding the second and third explanations is the most common error, and it is the one that produces the "IT took away my tool" backlash.

Practice: building the case on a collaboration tool

Suppose 12,000 licences, 4,200 employees active in the last 30 days.

Segment the inactive population by department, location and role. Concentration points at a workflow reason; even distribution points at an enablement reason.
Check experience metrics for the active population. If experience is poor, low adoption is a symptom, not a cause.
Check the alternative — are the inactive users heavy users of a competing or legacy tool? That is a migration problem.
Run a targeted campaign to a sample of inactive users asking why.
Only then split the population into reclaim, fix, and guide cohorts, and act differently on each.

Self-check

Why should experience thresholds be set per application rather than globally?
What are the three explanations for a licence-to-usage gap, and why does distinguishing them matter?

Show answers

33. Because the same absolute threshold represents excellent performance for a heavy application and poor performance for a lightweight one; a global threshold ranks applications by weight rather than by quality.

34. Not needed, cannot use it well, or do not know how. They call for reclamation, experience remediation, and enablement respectively — and reclaiming licences from people in the second or third category creates a backlash and does not solve the underlying problem.

PART V — AUTOMATION AND ADOPTION

Module 15: Workflows and DEX automation

Concepts

Nexthink Flow is a low-code orchestration engine. A workflow chains together steps — remote actions, campaigns, integration calls, conditional branches, waits and notifications — into an end-to-end process that runs without a human at each step.

Automation is where DEX programmes generate their strongest numbers, because the alternative scales linearly with headcount and automation does not.

Anatomy of a workflow

Element	Role
Trigger	What starts it: an alert, a schedule, an API/webhook call, a manual launch, or an ITSM event
Scope / target	Which devices or users it acts on, usually defined by an NQL condition
Steps	Remote actions, campaigns, connector calls, notifications
Conditions / branches	Different paths depending on step outputs
Thinklets / connectors	Reusable building blocks that call external systems
Outputs and logging	Results per target, for reporting and audit

Connector thinklets are the reusable integration components — pre-built steps for common external operations such as creating a ticket, updating a record, or posting a notification. Using thinklets rather than raw HTTP calls gives you consistent authentication handling, error handling and maintainability. Build your own for repeated organisation-specific operations rather than duplicating logic across workflows.

The canonical automation pattern

Nearly every valuable workflow follows the same skeleton, which is the detect-confirm-act-verify pattern from Module 8, made autonomous:

Trigger on a detected condition.
Confirm the condition still holds on the specific device (telemetry can be minutes stale, and acting on a stale condition is how automation earns a bad reputation).
Check consent or timing if the action is disruptive — a campaign asking permission, or a wait for out-of-hours.
Act with the remediation.
Verify the condition cleared.
Branch on failure — retry once, then escalate by creating a ticket with full context.
Close the loop — notify the employee, update the ticket, record the outcome.

Steps 2, 5 and 6 are what separate a production-grade workflow from a demo. Most failed automation projects skip them.

Worked design: low disk space remediation

Trigger: alert — free disk below 10% on more than N devices, or scheduled evaluation of the condition. Step 1: remote action to confirm current free space and enumerate reclaimable space by category. Branch A — reclaimable space is sufficient: run safe cleanup (temp files, caches, update artefacts), then re-measure. If resolved, notify the employee that space was recovered and end. Branch B — cleanup insufficient, user data is the cause: deliver a campaign explaining the situation and offering options (guidance on archiving to cloud storage, or request assistance). Wait for response. Branch C — response requests assistance, or no response within the window: create an ITSM ticket via connector thinklet, populated with device identity, disk figures, cleanup already performed and the employee's response. Failure path: remote action fails → retry once → on second failure create a ticket flagged for endpoint engineering. Reporting: devices processed, space recovered, resolution rate without human involvement, tickets avoided.

That last line is the one that goes in the programme's quarterly report.

Automation governance

Automation that runs at fleet scale needs the same governance as any production system.

Start with high-frequency, low-risk, well-understood problems. The first automation should be something the service desk fixes manually fifty times a week with a known, safe procedure. Do not start with the interesting hard case.

Ring deployment applies. Test scope, pilot scope, then full scope, with time between rings to observe.

Build a kill switch. Know how to disable a running workflow immediately, and make sure more than one person knows.

Instrument everything. Success rate, failure rate, failure reasons, and time saved. A workflow you cannot report on is a workflow you cannot defend.

Review regularly. Conditions change, applications change, a workflow that was correct in March may be acting on a stale assumption in September.

Preserve human override. Employees should have a way to defer or decline a disruptive action, and support staff should have a way to exclude a device.

Consider the failure blast radius before enabling. Ask explicitly: if this workflow behaves wrongly on every targeted device simultaneously, what is the worst outcome? If the answer is unacceptable, add confirmation steps or narrow the scope until it is not.

Self-check

Why must a workflow re-confirm the condition after being triggered?
What characteristics make a problem a good candidate for the first automation?
What is the purpose of the failure branch, and why do demos usually omit it?

Show answers

35. Because the triggering telemetry may be minutes old and the condition may have resolved. Acting on a stale condition produces unnecessary and sometimes disruptive changes, which quickly destroys confidence in automation.

36. High frequency, low risk, well-understood procedure, and a clearly verifiable resolution. Save the interesting hard case until the platform and the team have a track record.

37. To escalate to a human with full context when automation cannot resolve the issue, and to make failure rates visible. Demos omit it because demos only show the happy path.

Module 16: Digital adoption and Nexthink Adopt

Concepts

Digital adoption is the discipline of ensuring deployed technology is actually used, used correctly, and used to the extent that the investment assumed. It exists because deployment and adoption are different events, frequently separated by months and sometimes never connected at all.

The classic pattern: an organisation buys a platform, migrates data, runs a launch communication, delivers a training webinar that 20% attend, and then discovers a year later that 35% of licences are inactive and half the active users are using it as a replacement for the one feature the old tool had.

Nexthink Adopt addresses this with in-application guidance — contextual overlays, walkthroughs, tooltips and announcements delivered inside the application, at the moment of need, through the browser extension.

The pedagogical argument for in-app guidance over training is straightforward: training happens before the need and is forgotten; documentation requires the user to stop, leave, search and interpret; in-app guidance appears at the moment of need, in the context of the actual task, and requires no context switch. Retention and completion rates differ accordingly.

Content types

Adopt's content types are more specific than generic digital-adoption vocabulary suggests:

Type	What it is
Guides	Step-by-step in-application guidance through a process
Tooltips	Contextual information shown on hover or click of an element, or via a hint icon. Independent of guided flows, user-discoverable, non-interrupting
Tours	Sequenced guidance across a set of steps
Playlists	Grouped content presented as a sequence
Context help	A pop-up surface from which employees find available guidance; its appearance and behaviour are configured per web application
Journeys and rules	Conditions governing when guidance appears, plus a Journey Tracker for progress

Match interruption level to importance. Tooltips are deliberately just-in-time and non-interrupting; a full guide that autostarts should be reserved for something the employee genuinely must complete correctly.

Configuration structure

Adoption settings are configured per web application, in tabs that map directly to the advanced-path course topics:

Settings — default guide behaviours, and how Adopt Editor captures page elements, based on a predefined set of Element selector instructions
Localization — select languages to activate AI-generated translations, which Adopt displays based on the employee's browser settings
Theme — default colour scheme for guide components
Context help — how the Context help pop-up appears and behaves by default

Guides are then created under the Adoption content tab, with a target URL that Adopt Editor opens on. Publishing is a distinct step, and published guides cannot be edited — you must unpublish first. Build that into your change process rather than discovering it under time pressure.

Element selectors — the make-or-break detail

A guide attaches to elements in the application's interface, and the selector is how it identifies them. Selector fragility is the largest cause of failure in digital adoption programmes: when an application updates its interface, guides pointing at moved or renamed elements break, and a broken guide is worse than no guide because it highlights the wrong control and misleads.

Adopt's Element Selector is interactive, working in three stages — Select, Refine, Confirm. Hover to pick the element; use the control panel's up and down arrows to adjust which element in the hierarchy is captured. The panel shows captured attribute data, which lets you spot dynamically generated classes or IDs, and an Element Strength indicator (a power bar) that tells you how robust the current selection is. Treat a weak strength reading as a defect to fix now, not a warning to ignore.

Beyond the interactive selector:

Selector systems influence how Adopt interprets the page's DOM structure globally. You can configure ignored element IDs, ignored element class names, and — most usefully — included element custom attribute names, a comma-separated list of stable custom attributes that should be used when constructing selectors. If your own development team owns the application, asking them to add a stable test attribute and then registering it here is a permanent fix that costs them minutes.

An important caveat: changing a Selector System affects only element selections made afterwards. It does not retroactively update selectors already configured in existing Tour steps or Tooltips.

Per-step overrides. Element selectors configured in the global Adoption settings can be enabled or disabled for an individual step, and you can override with an Element XPath or JSPath selector in the step's Position tab. Nexthink publishes worked configurations for specific SaaS applications where default detection struggles.

Shadow DOM. Some applications nest elements inside a shadow root, which standard selection handles poorly. Confirm by inspecting in browser developer tools and checking whether the element sits under a shadow-root (open) region; Nexthink provides selectors and documented configurations for these cases.

Localised selectors. An Element XPath override can itself be localised where it targets a specific block of text — necessary when the application renders in different languages.

iframes. When working inside an application with iframes, the Show matches option cannot display the matching key page for the iframe containing the target element; reselect the element to resolve it.

Monitor guide display and completion rates proactively. A sudden drop to zero after an application release means a selector broke, and users will not report it.

Localisation

Adopt supports a multilingual environment. It checks whether a translated version of a guide exists in the user's language and displays it; if not, it falls back to a designated fallback language. English is the default. Language selection can be automated, including matching languages via the Identity API.

Two things to hold onto. First, adding a language does not automatically translate existing step content — AI-generated translations are activated per web application in the Localization settings, and content still has to exist. Second, machine translation is a strong first draft and a weak final version for internal terminology, product names and compliance wording; have a native speaker review anything with consequences. Localisation also extends beyond guide steps to Context help content and guide names.

Remember that translated text length differs from the source — German and Finnish commonly expand — so test the rendered guide in each language, not just the translated string.

Multi-page and multi-step guides

Guides spanning several pages must handle the transition: knowing the user navigated, waiting for the next page and target element to render, and resuming at the right step. Adopt provides step properties for this class of problem, including conditions for completing a step, position recalculation on scroll (with the option to restrict scrolling to a named container when the page has multiple scroll areas), how long a step displays, and persisting a step after completion.

Design defensively: let steps wait for their element rather than assuming it exists, and handle abandonment gracefully.

Measuring adoption impact

Guide analytics typically report views, starts, completions, drop-off by step, and dismissal rates. Interpretation:

Low view count — the targeting or trigger is wrong; the guide is not reaching the intended population. High views, low starts — the opening is not compelling or is not perceived as relevant. High drop-off at a specific step — that step is confusing, too long, or the selector is pointing at the wrong element. Step-level drop-off is your most precise diagnostic. High completion, no behaviour change — the guide taught something that was not the actual barrier. Go back and re-identify the failure point. Falling completion after an application release — suspect a broken selector.

The metric that matters, though, is not any of these. It is the downstream behaviour: did expense claims with receipts on first submission increase? Guide analytics measure the intervention; business metrics measure the outcome. Report both, and never report the first without the second, because a well-completed guide that changed nothing is a cost, not a success.

Self-check

Why is a broken guide worse than no guide?
What does high drop-off at one specific step usually indicate?
Why is machine translation insufficient on its own for guide localisation?

Show answers

38. Because it highlights the wrong element and actively misleads the user, while also being invisible to IT — users rarely report a broken guide; they simply proceed incorrectly.

39. That the step is confusing, too long, or its selector is attached to the wrong element. Step-level drop-off is the most precise diagnostic available in guide analytics.

40. Because internal terminology, product names, compliance wording and tone need human review, and because translated text length differs enough to break layouts sized for the source language.

Module 17: Experience Central, DEX maturity and DEXOps

Experience Central

Experience Central is the consolidated starting point for managing digital employee experience — scores, trends, prioritised issues and entry points into investigation. Its role in the operating model is to be the surface a DEX team opens at the start of the day: what changed, what is worst, what is worsening, what is worth doing.

Used well, it drives a routine rather than a browsing session. A workable weekly rhythm:

Daily: check for score movement and new critical alerts; triage anything that appeared overnight. Weekly: review the worst-performing segments; select one or two issues for focused work; check remediation and automation success rates. Monthly: review trend against targets; review the alert inventory for noise; review campaign response rates and act on what employees said. Quarterly: revisit thresholds and weights (deliberately, with annotation); review programme metrics; re-baseline targets.

DEX maturity

⚠ The five stages below are my own framing, not an official Nexthink maturity model. Nexthink publishes its own DEX maturity material; do not present this as theirs. Maturity models are only useful if they describe a path you can actually walk.

Stage 1 — Visibility. The platform is deployed with adequate coverage. You can see the estate. Scores exist. Nothing systematic is done with them yet. Exit criterion: coverage above target and a score baseline you trust.

Stage 2 — Reactive efficiency. DEX context is in the hands of the service desk. Handle time and escalation rates improve. Exit criterion: measurable reduction in handle time or escalation, and L1 habitually checking scope before treating a ticket as individual.

Stage 3 — Proactive detection. Alerts are tuned and owned; issues are found before tickets arrive; someone's job description includes responding. Exit criterion: a meaningful share of issues identified proactively, with a named owner and a runbook for each alert.

Stage 4 — Automated remediation. Defined problem classes are resolved by workflows without human involvement, with verified outcomes and reported deflection. Exit criterion: measurable ticket deflection attributable to automation, with failure handling in place.

Stage 5 — Experience-led IT. Experience data informs decisions upstream: what to buy, what to retire, how to design the standard build, when to block a rollout. Adoption and sentiment are inputs to portfolio decisions. Characteristic: other teams request DEX data rather than the DEX team pushing it.

Two honest observations about this progression. First, most organisations stall between stages 2 and 3, and the reason is almost never technical — it is that nobody owns proactive work as their actual job. Second, stages are not cleanly sequential; you can be at stage 4 for one problem class and stage 1 for another. Assess by domain, not globally.

DEXOps and Navigator

DEXOps applies the operating-model thinking of DevOps and SRE to digital employee experience: continuous measurement, defined ownership, feedback loops, automation of repetitive response, and treating experience as a service with targets rather than as a project with an end date.

⚠ Unverified section. Unlike the rest of this guide, the Navigator material below has not been confirmed against product documentation and is extrapolated from the course description. Treat it as orientation, not description.

Navigator, in this context, is the guided path through that operating model — the structured route from where an organisation is to a higher-maturity practice, with the concepts and sequencing to get there. ⚠ Navigator's specific capabilities and content are product features that evolve; check current documentation for the detail.

The transferable principles, regardless of tooling:

Experience needs owners, not just observers. Named ownership per experience domain — devices, collaboration, key applications — with targets.

Define targets, not just measurements. Something analogous to an SLO for experience: what score, for what population, by when.

Close every loop. Detection connects to response, response to verification, verification to prevention. Loops that stop at detection produce dashboards; loops that close produce improvement.

Automate the repetitive. Anything the team does manually more than weekly with a known procedure is an automation candidate.

Feed learning upstream. Experience findings should change procurement, standard builds, deployment practice and application design. If nothing upstream ever changes because of DEX data, you are running a very expensive reporting function.

Self-check

At which stage do most DEX programmes stall, and why?
What distinguishes a DEXOps operating model from having a DEX tool?

Show answers

41. Between reactive efficiency and proactive detection — because proactive work requires dedicated ownership, and organisations typically try to fund it from the spare capacity of a reactive team, which has none.

42. Defined ownership with targets, closed loops from detection through verification to prevention, systematic automation of repetitive response, and findings that change upstream decisions. A tool without those produces dashboards; the operating model produces improvement.

Reference

Glossary

Term	Definition
Adopt	Nexthink's digital adoption module for in-application guidance
Alert	A condition evaluated on a schedule that notifies and optionally triggers a workflow
Amplify	DEX context surfaced inside the service-desk agent's workflow
Campaign	An on-device survey delivered to employees to gather sentiment
Collector	The endpoint agent that gathers telemetry and executes actions
Connector (inbound)	Integration bringing third-party data into the platform
DEX	Digital Employee Experience — the discipline of measuring and improving technology experience at the point of consumption
DEX Score	Hierarchical composite metric summarising experience, conventionally 0–10
DEXOps	An operating model applying continuous-improvement practice to DEX
Element selector	The mechanism by which a guide identifies a UI element to attach to
Entity	A thing with current state in the data model (device, user, binary)
Event	A time-stamped occurrence in the data model (crash, execution, page view)
Experience Central	The consolidated entry point for managing DEX
Flow	The low-code workflow automation engine
Hierarchy	Organisational structure overlaid on devices and users for analysis, permissions and targeting
NQL	Nexthink Query Language — the pipeline query language underpinning the platform
Remote action	A script executed on endpoints for information gathering, remediation or prevention
Thinklet	A reusable workflow building block, typically for external system integration
Webhook	An outbound HTTP call triggered by a platform event

Suggested study sequence

If you are	Work through	Approximate depth
L1 support agent	Modules 1, 2, 3, 5, 12	Concepts and method; no build skills required
L2/L3 engineer	Modules 1–6, 9, 13	Full query and investigation capability
Platform administrator	Modules 1–11, 15	Build, operate and integrate
DEX analyst	Modules 1–7, 14	Query, visualise, and interpret
Automation engineer	Modules 1–4, 8, 9, 11, 15	Actions, alerts, integration, workflows
DEX lead / strategist	Modules 1, 3, 14, 17	Interpretation, maturity, operating model
Change / adoption owner	Modules 1, 14, 16	Adoption practice end to end