Troubleshooting Dynamics 365: Resolving Missing Standard SLAs During Migration

Table of Contents

This article addresses a specific challenge encountered during Dynamics 365 Customer Service migrations, focusing on the absence of standard Service Level Agreements (SLAs) within the migration tool. Understanding the nuances of SLA types in Dynamics 365 is crucial for a smooth transition and maintaining service level management in the updated environment. This document will delve into the symptoms, underlying causes, and effective resolutions for this issue, ensuring a comprehensive understanding for administrators and migration teams.

Symptoms¶

The primary symptom of this issue is the conspicuous absence of standard SLAs when utilizing the Dynamics 365 Customer Service migration tool. Users expect to see a comprehensive list of all existing SLAs within their legacy system, ready for migration to the new environment. However, in this scenario, the migration tool interface fails to display the standard SLAs. This can lead to confusion and potential oversights in the migration process, as administrators might assume that SLAs are being migrated when, in fact, a subset of them are not even recognized by the tool.

Specifically, when navigating through the migration tool, users might find that:

• The list of available SLAs for migration appears incomplete.
• Upon closer inspection, only enhanced SLAs are listed, while standard SLAs are nowhere to be found.
• There are no error messages or warnings indicating that standard SLAs are being excluded or are incompatible. The tool simply does not present them as migration candidates.
• This issue is observed even when standard SLAs are actively configured and functioning within the legacy Dynamics 365 environment.
• Users may initially suspect a problem with their user permissions or tool configuration, but further investigation reveals the issue to be related to the inherent design and limitations of the migration tool concerning standard SLAs.

This absence of standard SLAs can create significant challenges for organizations relying on these agreements to manage their customer service operations. It is vital to understand why this occurs and how to address it to ensure a complete and accurate migration of service level management configurations.

Cause¶

The root cause of standard SLAs not appearing in the migration tool lies in the architectural evolution of Service Level Agreements within Dynamics 365 Customer Service. To fully grasp this, it’s essential to understand the historical context of SLAs in the platform.

Historically, Dynamics 365 offered two distinct types of SLAs:

1. Standard SLAs (Legacy SLAs): These were the original SLA type, designed for simpler service level management scenarios. They were functional within the older, or “legacy,” web client interface of Dynamics 365.
2. Enhanced SLAs: Introduced later, enhanced SLAs provided a more robust and feature-rich approach to service level management. They offered capabilities such as SLA KPIs (Key Performance Indicators), multiple SLA items, and improved monitoring and reporting. Enhanced SLAs are designed to work seamlessly within the Unified Interface, the modern and recommended interface for Dynamics 365 applications.

The critical point is that standard SLAs have been deprecated. Deprecation in software terms means that a feature or technology is no longer being actively developed or supported and is intended to be phased out over time. In the context of Dynamics 365, standard SLAs are considered a legacy feature and are not aligned with the future direction of the platform, which is centered around the Unified Interface and its enhanced capabilities.

Consequently, the Dynamics 365 migration tool is specifically designed to support the migration of configurations and data that are compatible with the Unified Interface. Since standard SLAs are deprecated and not supported within the Unified Interface, the migration tool is intentionally built to recognize and migrate only enhanced SLAs.

Therefore, the absence of standard SLAs in the migration tool is not a malfunction or an error. It is a direct consequence of:

• The deprecation of standard SLAs.
• The migration tool’s focus on supporting only features compatible with the Unified Interface.
• The strategic shift towards enhanced SLAs as the standard for service level management in Dynamics 365.

Understanding this design choice is crucial for migration planning. Organizations relying on standard SLAs need to acknowledge that these SLAs will not be directly migrated using the standard migration tool. They must adopt a different approach, which leads us to the resolution strategies.

Resolution¶

The resolution to the issue of missing standard SLAs in the migration tool involves a two-pronged approach: understanding your current SLA landscape and adapting your migration strategy accordingly.

1. Identify SLA Types in the Legacy Web Client:

The first and most critical step is to accurately determine the types of SLAs currently in use within your legacy Dynamics 365 environment. Since standard SLAs are only accessible through the legacy web client interface, you must access Dynamics 365 using this interface to perform this check.

Steps to Identify SLA Types:

1. Access Dynamics 365 via the Legacy Web Client: Ensure you are logged into your Dynamics 365 instance using the legacy web client interface. This is typically accessed through a URL that may differ slightly from your Unified Interface URL. You may need to consult your Dynamics 365 documentation or administrator for the specific legacy web client URL.
2. Navigate to Service Management: Within the legacy web client, locate the “Service Management” area. This is usually found within the main navigation menu.
3. Access Service Level Agreements (SLAs): Under “Service Management,” find and select “Service Level Agreements.” This will display a list of all SLAs configured in your system within the legacy interface.
4. Examine the SLA List: Review the list of SLAs presented. In the legacy web client, there was no explicit labeling to differentiate between “standard” and “enhanced” SLAs within the user interface itself. However, if you created SLAs a long time ago and have not actively migrated to enhanced SLAs, it is highly likely that these are the older “standard” type. If you have been using Dynamics 365 for a longer period and have not specifically upgraded your SLAs, they are likely to be standard SLAs. Enhanced SLAs were introduced later and often require a more deliberate configuration.
5. Document SLA Types: Carefully document which SLAs are present in your legacy environment. While you might not see a type designation directly, the fact that they are visible in the legacy web client and not appearing in the migration tool is a strong indicator that they are standard SLAs.

2. Adopt Enhanced SLAs for Migration:

Once you have confirmed that you are using standard SLAs and understand that they are not directly migratable via the standard tool, the recommended resolution is to transition to enhanced SLAs for your service level management needs in the Unified Interface.

Strategies for Transitioning to Enhanced SLAs:

• Recreate Standard SLAs as Enhanced SLAs: The most straightforward approach is to manually recreate the functionality of your existing standard SLAs using enhanced SLA configurations. This involves:

  • Analyzing the logic and rules defined in your standard SLAs. Understand the conditions, actions, and timings associated with each standard SLA.
  • Reconfiguring these rules and logic within the enhanced SLA framework. Enhanced SLAs offer more granular control and features, so you can often replicate and even improve upon the functionality of your standard SLAs.
  • Testing the newly created enhanced SLAs thoroughly in a non-production environment to ensure they function as expected and meet your service level management requirements.

• Prioritize and Migrate Critical SLAs: If you have a large number of standard SLAs, prioritize those that are most critical to your operations. Focus on recreating these as enhanced SLAs first. You can then address less critical SLAs in a phased manner.

• Consider Data Migration for SLA History (If Necessary): While the configurations of standard SLAs are not directly migratable, you might have historical data associated with SLA performance that you wish to retain. Depending on your reporting and historical analysis needs, you may need to explore custom data migration strategies to extract and potentially import relevant historical SLA data. However, this is often a complex undertaking and should be carefully evaluated based on the value of the historical data and the effort involved. In most cases, focusing on migrating the functionality through enhanced SLAs is the primary concern.

• Leverage Enhanced SLA Features: Take advantage of the advanced features offered by enhanced SLAs. Explore SLA KPIs, multiple SLA items, and the improved monitoring and reporting capabilities. This is an opportunity to not just replicate your old SLAs, but to potentially enhance your service level management processes.

• Training and Documentation: Ensure your team is adequately trained on the use of enhanced SLAs and the Unified Interface. Update your internal documentation to reflect the transition to enhanced SLAs and the deprecation of standard SLAs.

In summary, the resolution is not about forcing the migration tool to recognize standard SLAs, but about adapting your SLA strategy to align with the current and future direction of Dynamics 365. By transitioning to enhanced SLAs, you not only resolve the migration issue but also benefit from a more powerful and feature-rich service level management framework within the Unified Interface.

By understanding the distinction between standard and enhanced SLAs, recognizing the deprecation of standard SLAs, and proactively transitioning to enhanced SLAs, organizations can effectively navigate this migration challenge and ensure a smooth and successful transition of their service level management configurations to the modern Dynamics 365 environment.

If you have further questions or require more specific guidance on migrating your SLAs, please feel free to leave a comment below! We encourage you to share your experiences and challenges with SLA migration to help build a community knowledge base.