SRE: Example: DEX Specialist Workflow

Prev Next

This video walks through an example of using SRE to identify Experience Index issues, create and manage problem investigations, and analyze affected systems to determine root causes. It demonstrates how to turn sensor data into actionable improvements that enhance the digital employee experience and drive higher Experience Index scores over time.

Video Transcript

The DEX Specialist workflow helps you move from identifying Experience Index impacts to actively investigating and improving the issues behind them.

Start by reviewing the Experience Index Impact Navigator. This view shows which categories are contributing most to the overall score, helping you determine where to focus your attention. For example, computing resources may be responsible for 15% of the impact, while network issues account for another 11%.

Select a category to drill into the sensors contributing to that impact. Choosing the Network category displays the sensors associated with network-related issues, along with their severity and the number of instances. Selecting a sensor, such as Low Wi-Fi Signal Strength, allows you to see how many systems were affected, what types of systems are impacted, where they are located, and how the issue has changed over time. This helps determine which issues are isolated and which may require broader action.

Once you've identified an issue that warrants investigation, you can create a problem directly from the sensor view. In this example, the Extended Low Available Memory sensor is impacting hundreds of systems, making it a good candidate for further investigation. Create a new problem and give it a meaningful name, such as Investigate Low Memory Thresholds.

Creating the problem establishes a central location for investigation and collaboration while capturing a snapshot of the current state. Other users with access to the Reliability Engineering workflow can see the problem, understand what is being investigated, and follow its progress.

You can add notes to document discoveries and next steps. For example, you might record that the default threshold for low available memory is 20% for longer than 1,800 seconds and note that the threshold should be reviewed to determine whether it is appropriate for the environment.

With the problem created and documented, the next step is to investigate the systems affected by the sensor. Open the impacted systems and select a system to investigate in Resolve. There, you can review the system's hardware configuration, applications, and activity to understand what may be causing the memory issue.

For example, a device with only 8 GB of memory may genuinely require additional resources. Alternatively, a device with 16 GB or 32 GB of memory may be consuming that capacity because of the applications or user activity running on it. This additional context helps determine whether the issue is caused by a hardware limitation, user or application behavior, or a sensor threshold that is too aggressive.

Based on the investigation, you can determine the appropriate action. If the threshold is too aggressive, the sensor may be adjusted to better reflect the needs of the environment. It is a good practice to consult your Customer Success team for guidance on best practices. If the investigation identifies an actual system or user issue, that issue can be addressed directly.

As the investigation progresses, use the problem notes to record findings, decisions, and next steps. This creates a shared record of the work and keeps everyone involved informed. Finally, update the problem status as work progresses and close it when the investigation is complete.

This workflow turns Experience Index data into actionable work. By identifying the issues having the greatest impact, creating and managing problems, investigating affected systems, and addressing root causes, you can proactively improve the user experience and see that improvement reflected in your Experience Index over time.