Fix Your Dynamics 365 SLA Migration Issues: A Customer Service Troubleshooting Guide

Table of Contents

Migrating Service-Level Agreements (SLAs) in Dynamics 365 Customer Service from the legacy web client to the Unified Interface is a critical step for organizations modernizing their service delivery processes. While the migration tool is designed to facilitate this transition, users may encounter various issues that prevent SLAs from functioning correctly in the new environment. This guide outlines common scenarios where SLA migration may fail or result in unexpected behavior and provides detailed steps to resolve these problems. Understanding these potential pitfalls and their solutions is essential for a smooth and successful migration, ensuring your service commitments are met and tracked accurately within the Unified Interface.

Successfully migrating SLAs ensures continuity in service metrics and compliance monitoring. Issues during this process can lead to incorrect reporting, missed deadlines, and ultimately, impact customer satisfaction. The scenarios discussed below cover a range of problems, from basic migration errors to complex issues related to workflow automation and email templates, offering practical troubleshooting steps for each.

Scenario 1: Error 404 During SLA Migration¶

When attempting to run the SLA migration tool within Dynamics 365, you might encounter a “404 Error” accompanied by the specific message “Resource not found for segment mdyn_MigrateSla.” This error indicates that a required component or process needed for the migration is not accessible or properly configured.

Cause¶

The primary reason for this specific 404 error during the SLA migration process is that the necessary custom action workflow designed to handle the migration logic is not active within your Dynamics 365 environment. Custom actions, like workflows, must be activated to be callable and executable by the system processes, including the migration tool. If the mdyn_MigrateSla workflow is in a draft or deactivated state, the tool cannot find or execute the required operations, leading to the “Resource not found” error.

Resolution¶

To resolve the 404 error caused by a deactivated custom action, you need to locate and activate the relevant workflow process. The process specifically responsible for the SLA migration is typically named MigrateSla or similar, corresponding to the mdyn_MigrateSla segment mentioned in the error message. Activating this workflow will make it available for the migration tool to use, allowing the process to proceed as intended.

1. Navigate to the classic interface settings area if the modern interface doesn’t provide access to workflow processes directly, or use the Power Apps maker portal. Typically, this is found under Settings > Processes in the legacy web client, or by accessing Solutions and finding the relevant solution containing the SLA migration components in Power Apps.
2. Locate the workflow process named MigrateSla or the process associated with the unique name mdyn_MigrateSla. You might need to filter processes by type (Workflow) or category (Action).
3. Check the status of the MigrateSla workflow. If its status is “Draft” or “Deactivated,” select the workflow.
4. From the command bar or the workflow’s options, select the Activate button. Confirm the activation if prompted.
5. Once the workflow status shows as “Activated,” return to the SLA migration tool and attempt to run the migration again. The 404 error related to the missing resource should now be resolved, allowing the migration process to continue.

Ensuring core processes like migration workflows are active is a fundamental troubleshooting step for many system-level operations in Dynamics 365.

Scenario 2: SLA Warning Email Doesn’t Display Correct Values After Migration¶

A common issue observed post-SLA migration involves the warning emails sent out by the system when an SLA approaches non-compliance. Although the migration itself might complete successfully, the dynamic fields within these emails may show the underlying technical expression or placeholder instead of the actual formatted data from the case or related record. This affects the readability and usefulness of the warning notifications.

Symptoms¶

The issue manifests specifically after migrating an SLA item that includes a “Send Email” action configured using an email template. The steps to reproduce this involve setting up a legacy SLA and item with a “Send Email” step that uses dynamic content in its description, migrating it to the Unified Interface, activating it, applying it to a case, and waiting for the SLA status to trigger the warning email. When the email arrives, fields that should display values like “Case Number” or “Customer Name” instead show something like ${case.ticketnumber;} or a similar dynamic expression syntax.

This happens despite the SLA functioning correctly in terms of timer and status updates. The problem is isolated to how the dynamic content placeholders within the email template are interpreted or processed by the system after migration, particularly when moving from the legacy rendering engine to the Unified Interface’s framework, which often leverages Power Automate flows for these actions.

Resolution¶

The resolution involves manually adjusting the dynamic content within the Power Automate flow that represents the migrated “Send Email” action for the specific SLA item. The system incorrectly maps certain dynamic fields from the legacy template to their raw value representation rather than their user-friendly formatted value in the new flow context. By updating the dynamic expression to explicitly reference the FormattedValue option for option set or lookup fields, you can ensure the email displays the intended text or formatted numerical value.

1. Access the Service Level Agreements configuration area within your Dynamics 365 environment. In the modern interface, this is typically found under Service Terms in the Copilot Service admin center or Customer Service admin center.
2. Locate the SLA that was migrated and is experiencing this email issue from the list or grid and select it to view its details.
3. Within the SLA details, find the SLA Items grid. Identify the specific SLA item that contains the problematic “Send Email” action. Select this SLA item and expand its details or open it for editing.
4. Opening the SLA item in the Unified Interface usually reveals a link or control to view the underlying Power Automate flow that was automatically generated or updated during the migration to handle the SLA item’s actions. Access this Power Automate flow.
5. Navigate through the steps within the Power Automate flow, expanding actions until you find the step corresponding to “Send Email” or the email template content. This step will contain the body or description where the dynamic fields are used.
6. Examine the dynamic expressions used for the fields that are not displaying correctly in the email. For fields like Status, Option Sets, or Lookups, the expression might be referencing the raw value or ID.
7. Modify the dynamic expression for each problematic field. Instead of selecting the default value field, locate and select the corresponding FormattedValue field available for that attribute. For example, if a “Status Reason” field was showing the numerical status code, remove that dynamic content and add the Status Reason (Value) or Status Reason (Formatted Value) field that provides the text description.
8. After updating all necessary dynamic expressions to use FormattedValue where appropriate, save the changes to the Power Automate flow.
9. Test the fix by creating a new case that triggers the modified SLA item’s warning email action. Verify that the email now displays the correct, formatted text values for the dynamic fields. You may need to deactivate and reactivate the SLA or SLA item for the changes to take effect immediately.

This manual adjustment within Power Automate is necessary because the automated migration might not perfectly translate all nuances of legacy dynamic field mapping, especially for presentation formats.

Scenario 3: Status Value Displayed Instead of Text in Email After Migration¶

Similar to Scenario 2, this issue involves dynamic fields in emails after SLA migration, but it specifically concerns the display of status fields. When an action like “Assign Case” or “Change Status” is part of a migrated SLA item and triggers an email notification, the email might display the numerical value of the status (e.g., “5”) instead of the human-readable text description (e.g., “Resolved”). This makes the email difficult to interpret without knowing the mapping between status values and their labels.

Cause¶

This problem typically occurs because the SLA migration code or the resulting Power Automate flow references the underlying numerical Status or Status Reason field directly when constructing the email content. While this raw value is correct from a data perspective, email templates are intended for end-users who expect to see the localized, descriptive text label associated with that status value, not the internal code. The system fails to use the Formatted or FormattedValue property of the status field, which holds the display text, defaulting instead to the raw integer value.

This discrepancy arises from how dynamic field binding is handled differently between the legacy workflow engine and the Power Automate platform used by the Unified Interface for SLA actions. The migration process might not always correctly translate the intent to show the display text of an option set or status field.

Resolution¶

To ensure the correct text description of the status is displayed in the email, you need to modify the associated Power Automate flow generated for the SLA item. The goal is to explicitly reference the formatted value of the status field instead of its raw numerical value.

1. Access the Dynamics 365 Service Level Agreements configuration. Navigate to Service Terms > SLAs within the Copilot Service admin center or Customer Service admin center.
2. Find the migrated SLA that contains the item triggering the email with the incorrect status display and open its details.
3. From the SLA Items grid, select the specific SLA item that performs the “Assign Case” or similar action and sends the email notification. Open or expand this SLA item.
4. Access the underlying Power Automate flow associated with this SLA item. This is usually done via a link or button within the SLA item form in the Unified Interface.
5. Within the Power Automate flow designer, expand the steps until you locate the action that sends the email or prepares the email content (e.g., an “Send an Email” step, or a step manipulating variables used in the email).
6. Locate the point in the flow where the status value is being inserted into the email body or subject. This will be represented by a dynamic content placeholder.
7. Delete the existing dynamic content placeholder for the status field (which currently uses the raw value).
8. Re-add the dynamic content for the status field, ensuring you select the option that provides the formatted or text value. For example, if the field is Status Reason, look for Status Reason (Formatted Value) or a similar option that explicitly indicates the display text. You might need to search the dynamic content pane for the relevant entity and then browse its fields to find the FormattedValue property.
9. Save the changes made to the Power Automate flow.
10. Test the resolution by triggering the SLA item’s action on a new case that will send the email. Verify that the status field in the received email now shows the descriptive text (e.g., “Resolved”) instead of the numerical code. Remember to potentially deactivate and reactivate the SLA or SLA item after saving the flow changes.

This fix ensures that user-facing communications use the correct textual representation of status values, improving clarity and usability.

Scenario 4: Email “Subject” Field Is Empty When “Send Email with Template” Action is Triggered¶

Another issue related to migrated email actions involves the email subject line appearing empty. This occurs when an SLA item’s “Send Email” action, utilizing an email template, is executed, but the generated email arrives without any text in the subject field, even though a subject was defined in the original template or workflow step.

Cause¶

This issue is frequently caused by incorrect syntax in the email subject definition, particularly when using dynamic fields. A common pattern that causes this problem is using complex dynamic expressions within braces {} in a way that the Power Automate engine doesn’t parse correctly. For instance, subject lines defined in legacy workflows like “Hello,{Case Number(Case);Case Title(Case)}” contain syntax that might be misinterpreted during migration or when processed by the newer flow engine. Extra or misplaced braces or incorrect separators within dynamic expressions can lead to the subject field being rendered as empty because the system fails to extract or construct the subject string properly. The migration function itself might sometimes add extra braces, compounding the problem.

Resolution¶

Rectifying an empty email subject requires navigating to the underlying Power Automate flow of the problematic SLA item and correcting the dynamic content syntax within the email action’s subject field. The fix involves ensuring the dynamic fields are inserted using the correct method recognized by Power Automate and removing any extraneous syntax artifacts carried over from the legacy system.

1. Access the Service Level Agreements configuration area in Dynamics 365, located under Service Terms > SLAs within the Copilot Service admin center or Customer Service admin center.
2. Select and open the details of the migrated SLA that contains the SLA item sending emails with empty subjects.
3. From the SLA Items grid, identify and open the specific SLA item that triggers the “Send Email with template” action.
4. Access the Power Automate flow associated with this SLA item. This link is typically available within the SLA item form in the Unified Interface.
5. Within the Power Automate flow designer, locate and expand the step responsible for sending the email or constructing the email content. This will contain the configuration for the email’s subject.
6. Examine the content of the Subject field in the email action step. Look for dynamic content placeholders and any surrounding syntax, such as braces {} or semicolons ;, that might be causing parsing issues.
7. Clear the contents of the Subject field to remove any problematic legacy syntax.
8. Reconstruct the subject line by typing any static text required (e.g., “Hello, “). Then, use the dynamic content picker to insert the required dynamic fields one by one. Select the desired entity (e.g., Case) and then the specific field (e.g., Case Number, Case Title). The Power Automate dynamic content picker inserts fields using the correct internal representation, avoiding syntax errors.
9. Ensure that no manual braces or incorrect separators are added around or between the dynamic content placeholders inserted via the picker. The resulting subject line should be a mix of static text and correctly inserted dynamic tags.
10. Save the changes to the Power Automate flow.
11. Test the fix by triggering the SLA item’s email action on a new case. Verify that the sent email now has the correct subject line with dynamic fields populated properly. You might need to deactivate and reactivate the SLA or SLA item for the flow changes to become active.

Correcting the subject syntax within the Power Automate flow ensures that the subject line is constructed correctly using the new platform’s methods, resolving the empty subject issue.

Scenario 5: SLA Migration Fails with “VisitSetStateStep: There doesn’t exist a valid state code for the status code value 100000000”¶

During the SLA migration process, you might encounter a failure message specifically referencing “VisitSetStateStep” and indicating that a “valid state code for the status code value 100000000” does not exist. This error points to an issue with a specific status code used in one of the SLA item actions being invalid or missing in the target entity’s definition.

Cause¶

This issue typically arises when a customization has removed or altered a status code (statuscode) that was previously used in a “Change record status to” action within a legacy SLA item. Dynamics 365 uses a pair of values: statecode (state) and statuscode (status reason). Each statuscode must be valid for a specific statecode. If a statuscode used in an SLA action is deleted from the entity’s metadata (e.g., Case entity status reasons) or if its mapping to a statecode is corrupted, the migration process, which attempts to validate and translate these actions, will fail upon encountering the invalid status code. The value 100000000 mentioned in the error is an example of a specific status code that might be problematic in your environment.

Resolution¶

To resolve this migration failure, you must identify the SLA item action that is attempting to set the status to the invalid code and either remove that action or modify it to use a valid status code that exists for the target entity.

1. The error message often provides clues about which SLA item or entity is causing the problem, but you may need to review your legacy SLA items.
2. Examine the “Change record status to” actions configured within each legacy SLA item that is part of the migration batch.
3. For each “Change record status to” action, note the specific status code it is configured to set.
4. Compare these status codes against the current valid status codes defined for the target entity (e.g., the Case entity). You can find valid status codes and their corresponding states by navigating to Customizations > Customize the System > Entities > [Target Entity, e.g., Case] > Fields > find the statuscode field and check its options.
5. Identify the SLA item action that is configured to set the status to the code mentioned in the error (e.g., 100000000).
6. You have two main options:
   • Option A (Modify): If the intention was to set the record to a particular state/status, but the specific status code used was incorrect or deleted, modify the action in the legacy SLA item to use a currently valid statuscode that corresponds to the desired statecode.
   • Option B (Remove): If the action is no longer necessary or relevant, remove the “Change record status to” action entirely from the legacy SLA item.
7. After correcting or removing the problematic action in the legacy SLA item, save the changes to the SLA.
8. Attempt to run the SLA migration tool again. The tool should now be able to process the modified SLA item without encountering the invalid status code error.

Ensuring that all actions within your legacy SLAs reference valid and existing configurations within the target environment is crucial for a successful migration. This error highlights the importance of validating dependent configurations before migration.

Scenario 6: SLA Migration Fails with “A process operation associated with this process is not activated”¶

Another migration failure you might encounter presents the message “A process operation associated with this process is not activated.” This indicates that a specific background process or custom action required by the migration utility to perform certain data transformations or validations is currently deactivated.

Cause¶

This error is typically caused by the deactivation of the msdyn_ConditionXmlConversion custom action. This process is specifically designed to handle the conversion of condition XML used in legacy workflows (like those defining “Applicable When” or “Success Conditions” in SLA items) into the FetchXML format used by the Unified Interface and the new SLA engine, and vice versa. If this crucial conversion process is not active, the migration tool cannot properly process and translate the complex condition logic defined within your legacy SLA items, leading to the reported failure.

Resolution¶

To resolve this migration failure, you need to locate and activate the msdyn_ConditionXmlConversion custom action workflow. This process is essential for translating the complex logical conditions used in your SLA items into a format compatible with the Unified Interface and its underlying technologies like FetchXML.

1. Navigate to the process management area in Dynamics 365. In the classic interface, go to Settings > Processes. In the Power Apps maker portal, you might find processes listed under Solutions or a dedicated “Processes” area depending on your navigation setup.
2. Filter or search for processes of type Action.
3. Locate the action process with the unique name msdyn_ConditionXmlConversion. The display name might be something like “Convert legacy xml to fetchxml format and vice versa”.
4. Check the status of the msdyn_ConditionXmlConversion process. If its status is “Draft” or “Deactivated,” select the process.
5. From the command bar or the process’s options, select the Activate button. Confirm the activation if prompted.
6. Verify that the status of the msdyn_ConditionXmlConversion process now shows as “Activated.”
7. Return to the SLA migration tool and attempt to run the migration again. With the condition conversion process active, the tool should now be able to process the logic within your SLA items and complete the migration successfully without the “process operation not activated” error.

Ensuring all necessary supporting processes and custom actions provided by Microsoft’s solutions are active is a prerequisite for many advanced features and migration utilities within Dynamics 365.

Scenario 7: SLA Items Don’t Function As Expected After Migration¶

After successfully running the SLA migration tool, you might observe that although the SLAs appear in the Unified Interface, their associated SLA items don’t trigger correctly, the SLA timer doesn’t display on relevant records (like Cases) as anticipated, or some items seem stuck or incomplete during the migration process itself. This indicates deeper configuration or compatibility issues post-migration.

Symptoms¶

The symptoms of this scenario are varied and can include:
* SLA items not applying to records even when the “Applicable When” conditions are met.
* The SLA timer control, which visually tracks the remaining time for the SLA item (like First Response By or Resolve By), not appearing on the form, appearing incorrectly, or not updating.
* SLA statuses (like Nearing Non-compliance or Non-compliant) not being updated by the system despite the elapsed time exceeding the defined milestones.
* Specific SLA items remaining in a “Migrating” or pending state within the SLA configuration area, failing to become fully active.

These issues suggest that while the structural migration of the SLA and its items may have occurred, the underlying logic or dependencies are not correctly translated or compatible with the Unified Interface environment.

Cause¶

Several factors can contribute to SLA items not functioning as expected after migration:
* Incomplete Migration: Some SLA items might not have fully completed the migration process and are stuck due to transient errors or issues encountered during their individual conversion.
* Unsupported Configurations: The legacy SLA items might contain conditions, actions, or dependencies that are not fully supported or have changed behavior in the Unified Interface or the new SLA engine. This could include complex FetchXML conditions, deprecated actions, or configurations that rely on legacy client-side scripting no longer present.
* Incorrect Field Mappings: Dynamic fields used in conditions or actions might be incorrectly mapped or referenced in the underlying Power Automate flows generated during migration, preventing the logic from evaluating correctly.
* Data Discrepancies: Issues with the data on the target records (e.g., missing required fields, incorrect data types) might prevent the SLA conditions from being met.
* Cache or Metadata Issues: Sometimes, system cache or metadata synchronization problems can prevent the newly migrated configurations from being fully recognized and applied by the client interface or background processes.

Resolution¶

Troubleshooting non-functioning SLA items after migration requires a systematic approach involving verification, configuration review, and targeted testing.

1. Verify Migration Completion: First, check the status of all SLA items within the migrated SLA. Navigate to the Copilot Service admin center (or Customer Service admin center) > Service terms > SLAs. Open the migrated SLA and review the SLA Items grid. Confirm that all items show a status indicating successful migration (e.g., “Active”). If any items are stuck in a pending state, attempt to open them, save them, and potentially deactivate and reactivate the parent SLA to force a refresh or retry of the item’s activation/migration steps.
2. Review SLA Item Criteria: Carefully examine the “Applicable When” and “Success Conditions” defined for the problematic SLA items. Access the underlying Power Automate flow for each item (as described in previous scenarios). Review the conditions translated into the flow logic.
   • Ensure that the conditions accurately reflect the intended logic from the legacy SLA.
   • Check for complex or custom FetchXML queries used in legacy conditions; these might need manual adjustment in the Power Automate flow using query builders or filter array actions.
   • Verify that dynamic field references within conditions are correct and reference the appropriate fields (e.g., using FormattedValue where needed for option sets, though conditions typically use raw values).
   • Identify any actions (like custom workflow activities or deprecated processes) that might not be fully supported in the new engine. Replace these with supported Power Automate actions or Dynamics 365 actions where necessary.
3. Validate Timer Control Configuration: For issues related to the SLA timer not displaying, ensure the SLA timer control is correctly added and configured on the forms of the target entity (e.g., Case form). In the form designer, verify the timer control is present and mapped to the SLA KPI instance field. Also, ensure that the SLA is applied to the record and that the SLA KPI instance records are being created in the background when a record meets the “Applicable When” criteria.
4. Simplify and Test: If complex SLA items are failing, create a new, simple SLA item directly in the Unified Interface (not migrated) with very basic “Applicable When” criteria (e.g., Priority = High). Activate this simple SLA (or set it as default) and test it on a new record.
   • If the simple SLA item and its timer work correctly, it indicates that the issue is likely within the complexity or specific configuration of the migrated SLA items, pointing back to step 2.
   • If even a simple, newly created SLA item doesn’t work, the issue might be broader, potentially related to your environment’s general SLA configuration, background async processes, or client-side caching. Clear your browser cache, try a different browser, or consult Dynamics 365 system health.
5. Incremental Complexity: If the simple test SLA works, gradually increase the complexity of your test SLA items or compare the working simple item’s Power Automate flow side-by-side with the problematic migrated item’s flow to identify discrepancies in how conditions or actions are implemented. Replicate the correct implementation pattern from the working flow into the migrated flow.
6. Test in Sandbox: Always perform these troubleshooting steps and configuration adjustments in a non-production (sandbox) environment first. Thoroughly test the modified SLAs on various test cases covering different scenarios before applying changes to your production environment. Confirm that SLA timers display, statuses update, and actions (like sending emails) trigger as expected.

Resolving post-migration functionality issues often requires a deep dive into the translated logic within the Power Automate flows and careful comparison against the original legacy configuration, ensuring compatibility with the Unified Interface’s expected behavior.

Consider reviewing official Microsoft documentation and community forums for known issues related to specific complex conditions or actions during SLA migration, as some configurations may require specific workarounds or are not fully supported out-of-the-box. Maintaining clean and well-defined legacy SLAs prior to migration can significantly reduce the likelihood of encountering these complex post-migration issues.

A common source of post-migration issues stems from the difference in how legacy workflows and the new Power Automate platform handle complex logic. While the migration tool attempts to translate this, manual adjustments to the resulting flows are often necessary for reliable operation in the Unified Interface. Understanding basic Power Automate concepts, especially regarding dynamic content, conditions, and actions, is invaluable for troubleshooting migrated SLAs.

For visual guidance on navigating Power Automate flows generated by SLAs, you might find community-created videos helpful. Searching for “Dynamics 365 SLA Power Automate flow” on platforms like YouTube can provide visual walkthroughs.

Let’s summarize the scenarios and their quick fixes in a table format for easy reference:

Scenario	Symptom	Cause	Quick Resolution
404 Error During Migration	Migration tool returns 404 with “Resource not found for segment mdyn_MigrateSla”	MigrateSla custom action workflow is not activated.	Activate the MigrateSla workflow process.
Warning Email Shows Dynamic Expression	Email template shows ${case.ticketnumber;} instead of “Case 123”	Dynamic expression in email template maps to raw value, not FormattedValue.	Manually update dynamic expression in Power Automate flow to use FormattedValue.
Status Value (e.g., “5”) in Email Instead of Text (“Resolved”)	Email shows numerical status code instead of its text label.	Flow uses raw Status field value instead of Formatted value.	Update dynamic content in Power Automate flow email step to use FormattedValue.
Email Subject Field Empty	Sent email arrives with no text in the subject line.	Incorrect syntax (e.g., extra braces) in subject dynamic expression.	Correct the dynamic content syntax in Power Automate flow Subject field.
Migration Fails: “VisitSetStateStep: … invalid state code for 100000000”	Migration fails validation citing an invalid status code.	Status code used in a legacy SLA item’s “Change status” action is deleted.	Modify or remove the action using the invalid status code in the legacy SLA.
Migration Fails: “Process operation … not activated”	Migration fails indicating a required process is not active.	msdyn_ConditionXmlConversion custom action is not activated.	Activate the msdyn_ConditionXmlConversion workflow process.
SLA Items Don’t Function Post-Migration	Timers not displaying, items not triggering, items stuck in migration.	Incomplete migration, unsupported config, mapping issues, cache problems.	Verify migration status, review/correct criteria/actions in Power Automate flow, test simple SLAs, check form configs.

Successfully migrating and troubleshooting your Dynamics 365 SLAs is vital for maintaining effective customer service operations and meeting your service level objectives. By systematically addressing these common issues and understanding the underlying causes, you can ensure your SLAs function seamlessly in the Unified Interface, providing accurate tracking and timely notifications.

Have you encountered other specific issues during your Dynamics 365 SLA migration that aren’t covered here? Or do you have additional tips and tricks that helped you resolve these problems? Share your experiences and insights in the comments below to help the community.