Dynamics 365: Troubleshooting OnHold Time Issues in Unified Interface SLAs

Table of Contents

Service Level Agreements (SLAs) are a cornerstone of effective customer service management within Dynamics 365. They provide a structured framework for ensuring timely and efficient resolution of customer cases, fostering customer satisfaction and operational excellence. Understanding how SLAs function, particularly the nuances of time tracking such as “OnHold Time,” is crucial for administrators and customer service teams alike. This article addresses a common challenge encountered when utilizing Unified Interface SLAs: the apparent absence of the OnHold Time attribute at the case level. We will explore the reasons behind this behavior and clarify how on-hold durations are effectively managed and tracked within the modern Dynamics 365 Unified Interface.

Understanding Service Level Agreements (SLAs) in Dynamics 365¶

Service Level Agreements in Dynamics 365 Customer Service are designed to define and track performance metrics for support operations. They establish clear expectations for response and resolution times, ensuring that customer issues are addressed promptly and within agreed-upon timeframes. SLAs are not merely about meeting deadlines; they are about proactively managing service delivery, improving agent productivity, and ultimately enhancing the customer experience. By configuring and monitoring SLAs, organizations can gain valuable insights into their service performance, identify areas for improvement, and ensure consistent service quality across all customer interactions. These agreements are configurable and can be tailored to different customer segments, case priorities, and business needs.

Legacy SLAs vs. Unified Interface SLAs: A Shift in Approach¶

Dynamics 365 has evolved significantly over time, particularly with the introduction of the Unified Interface. This evolution has brought about changes in how SLAs are structured and how certain attributes, like “OnHold Time,” are handled. In older, or “legacy,” versions of Dynamics 365 SLAs, the onholdtime attribute played a central role in tracking the total duration a case was placed on hold. This attribute was directly associated with the case entity itself, providing a straightforward way to see the accumulated on-hold time for any given case. However, the Unified Interface SLA framework introduces a more granular and flexible approach to SLA management, leading to a change in how on-hold time is tracked. This shift is important to understand to effectively interpret SLA data within the modern Dynamics 365 environment.

Legacy SLA “OnHold Time”: Case-Centric Tracking¶

In the legacy SLA model, the onholdtime attribute was directly tied to the case entity. When a case was placed on hold, the system would automatically begin accumulating time against this attribute. This provided a simple and readily accessible metric for understanding how long a case had been paused. Reporting and analysis were often based on this case-level onholdtime attribute, offering a consolidated view of on-hold durations across the entire case lifecycle. While straightforward, this approach lacked granularity when dealing with more complex SLA configurations, especially those involving multiple key performance indicators (KPIs) and varied pause conditions.

Unified Interface SLA “Elapsed Time” and KPI Instances: Granular KPI-Focused Tracking¶

The Unified Interface SLA framework introduces a more sophisticated and KPI-centric approach. Instead of directly updating an onholdtime attribute at the case level, the system now tracks on-hold durations at the SLA KPI Instance level. This is a fundamental shift in perspective and offers several advantages. In the Unified Interface, a single case can be associated with multiple KPIs, each potentially having different pause conditions and even different operational calendars. For instance, a case might have separate KPIs for First Response Time and Case Resolution Time, each with its own set of rules for when the SLA timer pauses, including different “on hold” statuses.

The Elapsed Time is tracked at the KPI instance level because each KPI instance operates independently and may have unique pause configurations and associated schedules. This granular approach provides a much more accurate and detailed picture of SLA performance for each specific KPI being tracked on a case. This is particularly useful for complex service scenarios where different aspects of case resolution need to be monitored against distinct timelines and pause criteria. Therefore, while the case entity might not directly display a cumulative onholdtime attribute in the Unified Interface SLA context, this information is meticulously recorded and available within the relevant SLA KPI Instances.

Symptoms of the “OnHold Time” Issue: Where Did It Go?¶

The primary symptom of this perceived “issue” is simply the observation that the onholdtime attribute, as it was understood in legacy systems, appears to be missing or not populated for cases when using Unified Interface SLAs. Users accustomed to seeing a running total of on-hold time directly on the case form may find themselves looking for this attribute and not finding it readily available. This can lead to confusion and the impression that on-hold time is no longer being tracked. Furthermore, reports or dashboards that relied on the case-level onholdtime attribute from legacy SLAs will no longer function as expected when migrated to the Unified Interface. It is crucial to recognize that this is not a malfunction, but rather a change in how the system is designed to manage and present this data. The information is still being tracked, but in a different, more granular, and ultimately more powerful way.

Root Cause Analysis: Why the Change?¶

The shift away from a case-level onholdtime attribute in Unified Interface SLAs is driven by the need for greater flexibility and accuracy in SLA management. The legacy approach, while simple, was limited in its ability to handle complex SLA scenarios. Consider these factors that necessitate the change:

1. Multiple KPIs per Case: Modern customer service often involves tracking multiple KPIs for a single case. For example, a case might have SLAs for initial response time, first fix resolution time, and overall case closure time. Each of these KPIs may have different pause conditions. If a case is put on hold for a customer response, this pause might apply to the resolution time KPI but not necessarily to the first response KPI if that target has already been met. Tracking on-hold time at the KPI instance level allows for this nuanced management.

2. Varied Pause Conditions: Different KPIs may have different criteria for when the SLA timer should pause. One KPI might pause only when the case status is set to “On Hold” with a reason of “Waiting for Customer,” while another KPI might pause for different “On Hold” reasons or even based on custom conditions. KPI-level tracking ensures that pause conditions are applied correctly and specifically to each relevant SLA.

3. Operational Calendars: Unified Interface SLAs allow for the association of operational calendars with individual SLA items. This means that different KPIs can operate based on different business hours and holidays. For example, a high-priority SLA might operate 24/7, while a lower-priority SLA might only operate during standard business hours. Accurately calculating elapsed time, including on-hold time, requires considering the specific calendar associated with each KPI instance.

4. Enhanced Reporting and Analytics: Tracking elapsed time at the KPI instance level provides richer data for reporting and analysis. It allows for a deeper understanding of SLA performance for specific KPIs, enabling more targeted improvements and better insights into service bottlenecks. Reporting can be tailored to analyze performance against individual KPIs, rather than just a general case-level SLA status.

In essence, the move to KPI instance-level tracking in Unified Interface SLAs is a move towards greater precision, flexibility, and analytical power. While it may initially seem like a missing feature, it is actually a more sophisticated and capable approach to SLA management that aligns with the demands of modern customer service operations.

Resolution and Workarounds: Working with Elapsed Time¶

The resolution to the “missing onholdtime” issue is to understand and utilize the Elapsed Time tracked at the SLA KPI Instance level. Here’s how to effectively work with this:

1. Accessing SLA KPI Instances: SLA KPI Instances are entities within Dynamics 365 that are related to cases and SLAs. To view the Elapsed Time (which includes on-hold time), you need to navigate to the relevant SLA KPI Instance records. This is typically done programmatically or through customized views and dashboards. Directly viewing SLA KPI Instances from the case form may require customization of the form or the use of related entity views.

2. Understanding the “Elapsed Time” Field: The SLA KPI Instance entity contains fields that track various time metrics, including Elapsed Time. This field represents the total time that has passed for the KPI instance, taking into account pause conditions and the associated operational calendar. When a case is placed on hold (according to the pause conditions defined for the KPI), the timer for the Elapsed Time pauses and resumes when the case is taken off hold.

3. Custom Views and Dashboards: To make this information readily accessible, create custom views and dashboards that display SLA KPI Instances related to cases. These views can include fields such as:

   • Case Title: To easily identify the associated case.
   • SLA KPI Name: To identify which KPI instance it is (e.g., First Response, Resolution).
   • Elapsed Time: The crucial field showing the total elapsed time, including on-hold time.
   • Status Reason: The current status of the KPI instance (e.g., In Progress, Succeeded, Nearing Non-Compliance).
   • Warning Time Reached/Failure Time Reached: To understand SLA performance against targets.

   By creating these views and dashboards, you can effectively monitor SLA performance and on-hold durations at the KPI level.

4. Reporting and Analytics: Use Dynamics 365’s reporting and analytics capabilities (Power BI, Advanced Find, FetchXML reports) to analyze SLA KPI Instance data. This allows you to:

   • Calculate average Elapsed Time for specific KPIs or across teams.
   • Identify bottlenecks by analyzing KPIs that frequently breach SLA targets.
   • Track trends in on-hold durations and identify potential areas for process improvement.
   • Create reports that show SLA compliance rates and identify cases at risk of breaching SLAs.

5. Workarounds for Case-Level “OnHold Time” (If Absolutely Necessary): If there is a strong business requirement to have a cumulative “OnHold Time” attribute directly on the case entity (for example, for specific legacy reporting needs), you can implement a workaround using Power Automate or custom workflows. This would involve:

   • Creating a custom field on the Case entity to store the cumulative “OnHold Time.”
   • Creating a Power Automate flow or workflow that triggers when a case is placed on hold and taken off hold.
   • The flow/workflow would calculate the duration of the on-hold period and update the custom “OnHold Time” field on the case, accumulating the time each time the case is placed on hold.

   However, it is generally recommended to embrace the KPI instance-level tracking as it provides a more accurate and flexible approach to SLA management. Workarounds should be considered only when absolutely necessary for specific reporting or integration requirements that cannot be met using the standard SLA KPI Instance data.

Best Practices for Managing On-Hold Time in Unified Interface SLAs¶

To effectively manage on-hold time within Unified Interface SLAs, consider these best practices:

1. Clearly Define Pause Conditions: Carefully define the pause conditions for each KPI within your SLAs. Ensure that these conditions accurately reflect when the SLA timer should pause based on your business processes. Use specific statuses and status reasons to ensure precise control over SLA pausing.

2. Educate Your Team: Train your customer service team and administrators on the differences between legacy and Unified Interface SLAs, particularly regarding on-hold time tracking. Ensure they understand how to access and interpret SLA KPI Instance data.

3. Customize Views and Dashboards for Visibility: Create user-friendly views and dashboards that provide clear visibility into SLA performance and elapsed times at the KPI instance level. Make this information readily accessible to agents and managers.

4. Regularly Monitor SLA Performance: Establish a process for regularly monitoring SLA performance using the available dashboards and reports. Identify trends, potential issues, and areas for improvement in your SLA configurations and processes.

5. Iterate and Refine SLAs: SLAs are not static. Periodically review and refine your SLAs based on performance data, changing business needs, and feedback from your customer service team. Optimize pause conditions, targets, and operational calendars to ensure your SLAs are effective and aligned with your service goals.

6. Leverage Operational Calendars Effectively: Utilize operational calendars to accurately reflect your business hours and ensure that SLA calculations are based on your actual service availability. This is crucial for accurate SLA tracking and reporting.

By understanding the shift to KPI instance-level tracking and implementing these best practices, organizations can effectively manage and monitor on-hold time within Dynamics 365 Unified Interface SLAs, ensuring optimal customer service performance and SLA compliance.

Do you have any questions or experiences to share regarding managing OnHold Time in Unified Interface SLAs? Please leave a comment below!