Dynamics 365: Fix On-Hold SLA KPIs with Null PausedOn Dates

Table of Contents

Service Level Agreements (SLAs) are critical components within Dynamics 365 for managing customer expectations and ensuring timely service delivery. They define measurable metrics, known as Key Performance Indicators (KPIs), to track the performance of service operations. When an SLA is placed On-Hold, or paused, the system is expected to record the exact moment of this pause to accurately calculate the elapsed time against the SLA’s targets. However, a common issue arises when the pausedon property of an SLA KPI instance is unexpectedly set to null during an On-Hold status. This can lead to system errors and inaccurate SLA tracking, impacting service management and reporting. This article delves into the symptoms, causes, and resolutions for this specific Dynamics 365 challenge.

Symptoms of the Null PausedOn Date Issue¶

The most prominent symptom of this issue is the occurrence of error messages when interacting with cases or records associated with affected SLAs. Specifically, users might encounter an error message similar to the following when attempting to update a case:

Exception Message: Exception occurred in SLAInstance management custom action : System.InvalidOperationException: Nullable object must have a value.

This error message, while seemingly generic, points directly to a problem with the SLA instance management. The “Nullable object must have a value” part of the message is crucial. It indicates that the system is expecting a value for a property that is currently null, and in the context of SLAs and pausing, this property is highly likely to be the pausedon date. The error typically arises during case updates because these updates often trigger SLA evaluations and calculations in the background. When the system attempts to process an SLA instance that is On-Hold but lacks a pausedon date, it encounters this exception, halting the update process and potentially disrupting workflows. The error isn’t always immediately apparent; it might surface only when specific actions are taken on related records, making troubleshooting slightly more complex.

Furthermore, beyond the explicit error messages, there can be less obvious symptoms. SLA timers on case records might behave erratically, displaying incorrect remaining time or even failing to update at all. Reports based on SLA performance could become inaccurate, showing misleading data due to the flawed time calculations caused by the missing pausedon date. This inaccurate reporting can have significant implications for service managers who rely on SLA data to monitor team performance and identify areas for improvement. Therefore, even if the error message is not consistently appearing, investigating potential pausedon null values is crucial if you observe unusual SLA behavior or reporting discrepancies in your Dynamics 365 environment.

Root Cause: Custom Logic Interfering with PausedOn Property¶

The primary cause of the pausedon property becoming null when an SLA KPI instance is in the On-Hold status is typically attributed to custom logic or workflows implemented within Dynamics 365. While Dynamics 365 provides robust out-of-the-box functionality for managing SLAs, organizations often implement custom workflows or plugins to tailor the system to their specific business processes. These customizations, while intended to enhance functionality, can sometimes inadvertently interfere with the core SLA logic if not carefully designed and tested.

Specifically, the issue arises when a custom workflow or plugin is designed to update the SLA KPI instance’s status to On-Hold, but in doing so, it incorrectly sets the pausedon property to null. This could happen due to a variety of reasons within the custom logic itself. For instance, a developer might have unintentionally included a step to clear the pausedon field while implementing other status transition logic. Alternatively, a poorly designed workflow might be triggered by a different event and unintentionally modify the SLA instance, setting the pausedon to null as a side effect.

It is important to understand that the out-of-the-box SLA functionality in Dynamics 365 automatically populates the pausedon property with the current date and time when an SLA instance transitions to the On-Hold status. This is a fundamental part of how the system tracks paused time. When custom logic overwrites this behavior and sets the pausedon to null, it breaks this core functionality, leading to the errors and symptoms described earlier. Therefore, the investigation should always begin by examining any custom workflows, plugins, or scripts that are involved in SLA status transitions or updates, especially those related to the On-Hold status. The complexity of Dynamics 365 customizations means that identifying the problematic logic might require careful debugging and analysis of workflow execution logs and plugin code.

Resolution: Disabling Custom Logic and Utilizing Out-of-the-Box Functionality¶

The recommended resolution for this issue revolves around identifying and disabling the problematic custom logic or workflow that is causing the pausedon property to be set to null. The core principle is to revert to using the out-of-the-box SLA functionality provided by Dynamics 365 for pausing and resuming SLAs. This built-in functionality is designed to correctly manage the pausedon property and ensure accurate SLA tracking.

The first step in resolving this is to thoroughly review all custom workflows, plugins, and scripts that are configured to interact with SLA KPI instances, particularly those that are triggered during status transitions or record updates. Focus on any logic that is executed when an SLA instance is put On-Hold or resumed. Examine the steps within these customizations to see if there is any action that explicitly sets or modifies the pausedon property. Look for any update steps on the SLA KPI instance entity that might be inadvertently clearing the pausedon field.

Once you have identified the custom logic that is likely causing the issue, the most straightforward solution is to disable it temporarily. In Dynamics 365, workflows can be deactivated, and plugins can be disabled within the plugin registration tool. After disabling the suspected customizations, thoroughly test the SLA functionality, specifically the On-Hold and resume processes. Create test cases and transition SLAs to the On-Hold status and then resume them, observing the behavior of the SLA timers and checking for any error messages during related record updates. Monitor the pausedon property of the SLA KPI instances to confirm that it is being populated correctly when the SLA is paused and that it retains its value.

If, after disabling the custom logic, the issue is resolved and the pausedon property is correctly managed by the out-of-the-box functionality, then it confirms that the custom logic was indeed the root cause. In this case, you have a few options:

1. Eliminate the Custom Logic: If the custom functionality is not essential or if its benefits do not outweigh the issues it introduces with SLA management, consider permanently removing it. Relying on the standard Dynamics 365 SLA features can simplify your system and reduce the risk of future conflicts.

2. Redesign the Custom Logic: If the custom functionality is necessary for your business processes, you will need to redesign it to avoid interfering with the pausedon property. Carefully review the logic and ensure that it does not inadvertently set the pausedon to null. If the custom logic needs to update the SLA status, ensure it leverages the Dynamics 365 SDK methods or actions designed for SLA management, rather than directly manipulating the pausedon property. Thorough testing in a non-production environment is crucial after redesigning the custom logic before deploying it to production.

3. Refactor to Utilize Out-of-the-Box Features: Explore if the desired custom functionality can be achieved using the out-of-the-box features of Dynamics 365, such as business rules, workflows, or Power Automate flows, in a way that is compatible with the standard SLA behavior. Often, complex customizations can be replaced by more maintainable and less error-prone configurations using the platform’s built-in capabilities.

Ultimately, the goal is to ensure that the pausedon property is correctly managed by Dynamics 365 when SLAs are placed On-Hold. By prioritizing the use of out-of-the-box functionality and carefully managing any custom logic, organizations can avoid this common issue and maintain accurate and reliable SLA tracking within their Dynamics 365 environments. Proper SLA management is essential for providing excellent customer service and meeting service level commitments.

If you have encountered this issue or have further questions about managing SLAs in Dynamics 365, feel free to leave a comment below! We encourage discussion and sharing of experiences to help the community benefit from collective knowledge.