You’re offline. This is a read only version of the page.
2,100
We're facing an issue with SLA (Service Level Agreement) items in Dynamics 365, specifically within the context of case management. We’ve set up an SLA with three items: Initial Response, Resolution Update, and Workaround Provided. However, we're noticing unexpected behavior with these SLA items in various scenarios.
Here’s a breakdown of what’s happening:
Issue Description:
Questions:
We’d appreciate any guidance or suggestions to resolve this behavior. Thank you!
The issues you're describing with SLA (Service Level Agreement) items in Dynamics 365 Case Management are unusual and may indeed be related to configuration or platform behaviors. Let’s address each issue individually and explore possible causes and solutions.
In Dynamics 365, SLAs are defined as agreements with certain conditions and success/failure criteria that are applied to cases. SLA items should ideally function independently unless specific dependencies are configured. However, if there is misconfiguration or if there are unexpected platform behaviors, SLA items can exhibit the symptoms you’re experiencing.
Possible Cause:
Suggested Solution:
Share
Report
All responses (
Answers (
Initial Response KPI and Resolution Update KPI).Possible Cause:
Suggested Solution:
Possible Cause:
Suggested Solution:
To ensure SLA items function independently and do not interfere with each other, follow these guidelines:
Use Unique KPI Fields: Ensure that each SLA item has its own distinct KPI field. This prevents one SLA item’s status from affecting another.
Define Separate Success Criteria: Each SLA item should have success criteria that are specific to its purpose. Avoid overlapping conditions, as this can cause multiple SLAs to trigger simultaneously.
Avoid Dependencies Between SLA Items: Avoid setting up dependencies between SLA items unless absolutely necessary. For example, if "Resolution Update" relies on "Initial Response" to be marked as successful first, Dynamics 365 may inadvertently trigger both together or re-trigger them after deletion.
Deactivate Instead of Delete: If you want to remove an SLA item from a case temporarily, consider deactivating it rather than deleting it. Deleting an SLA item can cause Dynamics 365 to re-evaluate the SLA criteria, which may lead to automatic re-creation if conditions still match.
Check Workflows and Plugins: If you have custom workflows, business rules, or plugins that interact with SLAs, review them carefully. They may be causing the SLA items to trigger unexpectedly. Make sure they are set up to handle each SLA item independently without causing cascading effects.
Evaluate SLA Evaluation Order and Hierarchies: Review the evaluation order of SLA items, especially if you have multiple SLAs applying to the same case type. Ensure that each SLA item is processed independently to avoid unintended triggers.
If, after implementing the recommended configurations, you still experience issues, this may be due to a platform bug or an unintended behavior in Dynamics 365. In this case, you can:
Check for Updates or Known Issues: Microsoft regularly updates Dynamics 365, and there might be a bug fix available. Check the Microsoft Dynamics 365 Release Notes and Support Documentation for known issues related to SLA behavior.
Contact Microsoft Support: If you suspect this is a bug, report it to Microsoft Support. Provide detailed examples of the scenarios and any configuration screenshots or logs. They may be able to confirm if this is a known issue and provide a workaround.
The unexpected SLA behaviors you're encountering are likely due to overlapping criteria, shared KPI fields, or possible platform quirks. By separating KPI fields, ensuring distinct success criteria, avoiding dependencies, and deactivating instead of deleting, you can minimize these issues. If the problem persists, it may be beneficial to escalate it to Microsoft Support to rule out any potential bugs.
