Skip to main content
Skip table of contents

DEX score NQL examples

Use Nexthink Query Language (NQL) to access DEX score data and other relevant information.

NQL data structure

The dex.scores and  dex.application_scores tables contain score data. The system computes each score once a day at 00:00 UTC for a combination of user and device objects, and device dimensions active over the last 7 days. For example, employee A who used device 1 and device 2 over the last 7 days will have two sets of score data for the current day.

DEX score V3 primarily focuses on user-centric experience management rather than a device-centric approach, which differs from previous versions. Even though starting an NQL query with the device table is technically possible, you may witness deviations between the device's metric value and its score. Refer to the FAQ section of the Computation of the DEX score (available to Nexthink Community users) documentation for more information.

dex.scores table

The dex.scores table contains score data for the endpoint and collaboration scores and their subscores. The system structures a set of scores as follows:

Each node of the DEX score has a score value with the syntax [node name]_value. For example, if you want the score for logon speed, you would enter score.endpoint.logon_speed_value.

dex.application_scores table

The dex.application_scores table contains score data for the application scores and their subscores. This table is linked to users, devices and application objects. The system structures a set of scores as follows:

  • node.type represents the type of node of the application score structure:

    • page_loads

    • transactions

    • web_reliability

    • crashes

    • freezes

    • application

  • node.value indicates the score of a node of the application score structure. It must be used with the field application_score.node.type to specify the target node score.

Refer to the List of hard metrics and their default thresholds documentation (available for Nexthink Community users) for the full list of nodes and their respective NQL names.

Examples of NQL queries

Get the overall latest DEX score of your company.
| include dex.scores during past 24h
| compute DEX_score_per_user = value.avg(), c1 = count()
| where c1 > 0
| summarize Overall_DEX_score =  DEX_score_per_user.avg()
Get the latest virtual session lag score values for employees in Switzerland
| include dex.scores during past 24h
| where == "Switzerland"
| compute Virtualization_score = endpoint.virtual_session_lag_value.avg(), c1 = count()
| where c1 > 0
| summarize Overall_virtualization_score = Virtualization_score.avg()
Compare DEX score values per operating system platform.
| include dex.scores during past 24h
| compute DEX_score_per_device = value.avg(), c1 = count()
| where c1 > 0
| summarize Overall_DEX_score_per_OS_platform = DEX_score_per_device.avg() by operating_system.platform
Get the application score and the corresponding page load score.
| include dex.application_scores during past 24h 
| where == "miro" and node.type == application 
| compute application_score_per_user = value.avg()
| include dex.application_scores during past 24h 
| where == "miro" and node.type == page_loads 
| compute page_load_score_per_user = value.avg()
| summarize Overall_application_score = application_score_per_user.avg(), Overall_page_load_score = page_load_score_per_user.avg() 
Get the top 50 users suffering from poor digital experience.
| with dex.scores during past 24h
| compute DEX_score = score.value.avg()
| list name, DEX_score
| sort DEX_score asc
| limit 50


Timeframe associated with the dex.score table

  • A user or device object without any data over the last 7 days will have no score.

  • The score computed today at 00:00 UTC is associated with today's date, not yesterday's date.

This means that querying the dex.scores data with during past 7d is not correct, as this returns seven days of data points, and each data point is already a rolling window of 7 days. The data should be queried for only 1 day, for example

  • dex.scores during past 24h

  • dex.scores on 2023-10-30


| include dex.scores during past 24h
| compute software_reliability_score_per_user = endpoint.software_reliability_value.avg()

The daily computation of the scores starts at 00:00 UTC, but may take several hours to complete. Once the computation is finished, Nexthink tags the outcome with 00:00 UTC. This means that if you try to call the latest DEX score value with dex.scores during past 24h during the time window when the score is computed, no result will be returned until the computation is complete. This may impact timezones far from UTC, like AEDT (Australian Eastern Daylight Time).

Timeframe associated with raw data tables

To compare raw metric tables, for example, session.logins, web.page_views with corresponding scores, the timeframe must mimic the one used in the DEX score computation:

00:00 UTC today - 7d to 00:00 UTC today

Ensure that your timeframe matches the timezone of your browser.


  • Your browser timezone is CET (i.e., UTC + 1).

  • You want to compare the raw metrics with the DEX score of 2024-01-17.

  • You are interested in checking the page loads trends of Outlook.

web.page_views from 2024-01-10 01:00:00 to 2024-01-17 01:00:00
| where == "outlook" and == "TBD"
| summarize average_page_load_per_hour = page_load_time.overall.avg() by 1h

Hourly samples

The DEX scores take into account hourly samples of data. This data is either an average of a field or a sum of events over the past hour, depending on the metric type. To understand if a metric has breached the configured score thresholds, use hourly aggregation, not 5-minute or 15-minute time buckets.


Session.logins from 2024-01-10 01:00:00 to 2024-01-17 01:00:00
| summarize average_logon_time = time_until_desktop_is_visible.avg() by 1h

Computing DEX scores for populations

Computing the DEX scores of a population requires first computing the score of each employee and then averaging them across the entire population.

First, aggregate the DEX score per user or device and then for the population.

In this case, you should not start an NQL query with dex.scores during past 24h, but with the users or the devices table to compute individual scores. Use the summarize statement to compute the DEX score for the population.


| include dex.scores during past 24h
| compute dex_score_per_user = value.avg()
| summarize dex_score = dex_score_per_user.avg()

Looking at the right combination of user, device, and device dimensions

The system computes a score for a combination of user, device, and device dimensions such as geolocation, or location type. The rationale behind this approach is to enable advanced filtering on each employee context to extract insights.

This means employees who have changed their location during the last 7 days will have several scores for different geolocation or location types. Additionally, a device used by multiple employees will also have several scores.

To compare the raw metric with its corresponding score, you must:

  1. Understand the different dimensions associated with the score data.

  2. Apply the same dimensions when looking at the raw data.


CODE from 2024-01-31 01:00:00 to 2024-02-06 01:00:00
| where == "TBD" and context.location.type == "Remote" and context.location.state == "Vaud"
| summarize average_boot_duration_per_hour = duration.avg() by 1h

Device events without an employee associated with the device

Some metrics used in the DEX score computation do not have any user association in the Nexthink data model, for example:



  • device_performance.hard_resets

  • device_performance.system_crashes


The DEX score pipeline keeps a list of recent users on a device so that these events can be associated with these users’ DEX scores. If no recent users can be found on the device, these events will not be factored into the device’s DEX scores.

Employees working on multiple devices during the same hourly time bucket

Suppose an employee is working on multiple devices simultaneously. In this case, we collect all the data received on the user object for the hourly time bucket, but we only associate one context, for example, device, geo-location, location type to the bucket. This means that the system associates the last context of the hour with the time bucket, extracting the last data message received for the hour.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.