Dynamics 365 Customer Service Troubleshooting Guide
Why This Is Happening
I've seen this play out dozens of times: you open Dynamics 365 Customer Service on a Monday morning and something just feels off. Cases are auto-creating from emails when they shouldn't be. Accounts you never touched are appearing out of nowhere. Your SLA timers are behaving strangely. Records are showing some cryptic account called "# SSSAdminProd" as the owner instead of a real person. And the error messages , when you even get one , tell you absolutely nothing useful.
Here's the honest truth about Dynamics 365 Customer Service troubleshooting: the platform is enormously powerful, but that power comes with a lot of moving parts. Automatic Record Creation (ARC) rules, Power Automate flows, plugins, Dataverse API connections, third-party integrations, any one of these can silently misbehave in ways that look completely unrelated to the actual cause. Microsoft's own error messages tend to surface symptoms, not root causes. That's what makes diagnosing these issues so frustrating.
The most common problems I see fall into a handful of buckets. First, unintended automation: background processes, ARC rules, orphaned child flows in Power Automate, or legacy plugins, running without any human actively watching them. Second, misconfigured rules: an ARC rule set up months ago by someone who has since left the company, now silently creating accounts or cases based on every incoming email. Third, permission and ownership issues: system accounts like "# SSSAdminProd" taking ownership of records, causing visibility gaps for your agents. Fourth, SLA and case routing failures that stem from holiday calendars not being set correctly or queue configurations getting out of sync.
What makes Dynamics 365 Customer Service troubleshooting particularly tricky is that deactivating a rule doesn't always stop the behavior. A deactivated ARC rule can leave behind a child flow in Power Automate that keeps running independently, and that flow will keep creating cases long after you think you've turned everything off.
This guide covers the most common failure patterns I've encountered across enterprise deployments and walks you through each fix methodically. Whether you're dealing with ghost accounts, stubborn auto-case creation, or the "#SSSAdminProd" mystery, you'll find actionable steps here. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you go deep into audit logs and plugin registrations, start here. The single fastest fix for the majority of Dynamics 365 Customer Service issues, especially unexpected record creation, is checking your ARC rules and their associated Power Automate flows together, not separately.
Most admins deactivate the ARC rule and call it done. That's the trap. The rule and its child flow are two separate objects. You have to kill both.
Here's what to do right now:
- Navigate to Customer Service Admin Center → Case settings → Automatic record creation and update rules.
- Find any active rules that look suspicious, especially ones tied to email triggers. Click the rule name to open it.
- Note the rule name exactly, then deactivate it using the status toggle at the top.
- Now open a new browser tab and go to Power Automate (make.powerautomate.com). Navigate to Solutions if your environment uses solutions, or check My Flows and Team Flows.
- Search for flows with names that match or reference your ARC rule. Look specifically for child flows with triggers like "When a record is created" or "When an email arrives."
- Turn those flows off individually using the toggle in the flow list.
After doing both steps, send a test email into your system (or trigger whatever condition was causing the problem) and wait two to three minutes. If records stop being created, you've found the culprit. If the behavior continues, keep reading, one of the deeper steps below covers your scenario.
This is always Step 1 in any Dynamics 365 Customer Service troubleshooting session. ARC rules are the most common silent offender, and they're often set up correctly at first, then drift out of alignment as business processes change.
Go to Customer Service Admin Center. In the left navigation pane, find Case settings, then click Automatic record creation and update rules. You'll see a list of all rules in your environment.
For each active rule, ask yourself three questions: What entity is this rule creating records for? What trigger condition fires it? And, critically, is the target entity correct? A surprisingly common mistake is a rule that was originally meant to create leads or contacts being misconfigured to target the account entity instead. Once that rule fires on every incoming email, you'll see a flood of phantom accounts with no obvious cause.
Click into each rule and review its conditions carefully. Check the Source type (Email, Social activity, etc.) and the Conditions section. If you see broad, catch-all conditions like "Subject contains [anything]" with no narrowing filters, that rule is almost certainly over-triggering.
To safely test whether a specific rule is your culprit: deactivate it using the status dropdown at the top of the rule detail page, then monitor your environment for 15–30 minutes. If the unintended creation stops, you've confirmed the source. Re-enable rules one at a time to isolate exactly which condition is problematic before making permanent changes.
When it works, you'll see the automatic account or case creation stop completely during your monitoring window. No new phantom records will appear after the rule is deactivated.
I know this frustrates people, and honestly it should, it's one of those Dynamics 365 Customer Service troubleshooting pain points that feels like a bug even though it's technically by design. When you create an ARC rule in Dynamics 365, the platform generates a corresponding child flow in Power Automate behind the scenes. When you later deactivate or delete that ARC rule, the child flow is not automatically turned off. It keeps running. Cases keep getting created. You think you've fixed it, but you haven't.
Here's exactly how to find these orphaned flows. Open Power Automate at make.powerautomate.com. First, check Solutions in the left nav, if your organization uses Dynamics solutions (most do in enterprise setups), this is where solution-linked flows live. Expand the relevant solution and look for any flows with "ARC" or "record creation" in the name.
If you're not sure which solution to look in, go to My Flows → All flows and sort by the Modified column. Flows that were modified around the time your ARC rule was last edited are the ones to check first.
When you find a suspicious flow, click it to open the detail view. Look at the trigger, if it says something like "When an email is received" or "When a Dynamics record is created" and the flow has steps that create account or case records, that's your match. Toggle the flow Off from the flow list view or use the Turn off option in the flow editor.
After disabling, send a test email or re-trigger the original condition. Confirm that no new cases or accounts appear in Dynamics within the next few minutes.
If you've disabled all the ARC rules and turned off the Power Automate flows and records are still being created, welcome to plugin territory. This is less common but absolutely happens, particularly in organizations that have done heavy customization or migrated from an older Dynamics version.
Plugins are compiled .NET assemblies registered against Dynamics events. A plugin registered on the "Create" message for the Account entity will fire every single time something triggers an account creation, whether that's a user action, an API call, or another automation. They run silently in the background, and most users don't even know they exist.
To check your plugins, navigate to:
Advanced Settings → Customization → Customize the System → PluginsIn the Plugin Registration Tool (if you have it installed), you can also connect to your environment and browse all registered plugins and their step configurations. Look specifically for plugins targeting the Account or Case entity on the Create message.
When you find a suspicious plugin, check its Step registration. Look at the "Filtering Attributes", if this is blank or set to fire on any attribute change, it's extremely broad. Check also whether the plugin is set to run in Pre-Operation or Post-Operation mode, and whether it's synchronous or asynchronous.
To test: disable the plugin step from the Plugin Registration Tool or by setting its status to "Disabled" in the customization area. Monitor the environment again. If the phantom creation stops, you've found it. Work with your developer team to review the plugin's code before re-enabling, there may be a logic error creating records under conditions the original developer didn't anticipate.
If you're seeing "# SSSAdminProd" listed as the owner or "Modified By" user on cases, contacts, or accounts, don't panic, but do act on it. I've seen this catch organizations completely off guard, especially when agents start reporting they "can't see" records that were just created. The reason is exactly what it sounds like: the records are owned by a system account, not a real user or team, so your normal security role assignments don't give your agents visibility into them.
The "# SSSAdminProd" account is a system-level application user. It appears when an ARC rule or its associated Power Automate flow is configured to execute in the context of that system account rather than in the context of the submitting user or a dedicated service account your team controls.
To address ownership of already-affected records, you have two options. For a small number of records: open each record in Dynamics, click the Owner field, and manually reassign it to the correct user or queue. For bulk reassignment, use an Advanced Find query:
Advanced Find → Look for: Cases (or Accounts)
→ Filter: Owner = # SSSAdminProd
→ Select All → Assign → [Target user or team]For the underlying fix, preventing this from happening in future records, go back to your ARC rule configuration. In the rule's detail view, look for the Run As or execution context setting. Change this from the system account to a real named service account that has appropriate security roles and is assigned to the right business unit. This ensures new records created by the rule get a sensible owner from the start.
After the fix, create a test case via the trigger condition and verify the Owner field shows your expected service account, not "# SSSAdminProd."
Once you've worked through the ARC rules, flows, and plugins, if something is still creating records unexpectedly, the audit log is your last line of investigation before calling in Microsoft Support. This step is also worth running in parallel with the others if you suspect unauthorized access or a third-party integration gone rogue.
To access audit logs in Dynamics 365, go to Advanced Settings → Settings → Auditing → Audit Summary View. Filter by the entity you're investigating (Account or Case) and set the Action filter to Create. Sort by the Date column descending to see the most recent creations first.
Look at the Changed By column. You're looking for any of the following red flags: a system account name you don't recognize, a user account that shouldn't have access to create records of that type, or an application user name that corresponds to a third-party integration.
If you see an application user name you don't recognize, navigate to Settings → Security → Users, switch the view to Application Users, and identify that account. Check what security roles it has and what external application it belongs to. Then go to:
Settings → Customization → Developer ResourcesReview any registered external applications with Dataverse API access. Temporarily disable third-party connectors one at a time, starting with the most recently added, and monitor whether record creation stops.
Also check Power Platform Admin Center → Environments → your environment → Settings → Product → Privacy + Security to review API access policies and connection audit trails.
When you've isolated the right source, the audit log will show clean, no unexpected "Create" events firing from unknown accounts.
Advanced Troubleshooting
Using Solution Health Hub for Deeper Diagnosis
Microsoft provides a built-in diagnostic tool specifically for these kinds of Dynamics 365 Customer Service troubleshooting scenarios: Solution Health Hub. If you're dealing with SLA issues, rule misfires, or persistent unexplained behaviors, this is where you should look before going into manual investigation mode.
To access it: open the app list in Dynamics 365 and search for Solution Health Hub. From there, run a Health Check against the Customer Service solution. The hub will flag known configuration problems, things like SLA KPI instances stuck in a "Canceled" state, SLA timer issues when a case is put on hold, and misconfigured queue routing rules.
SLA Timer Pausing on Hold, What's Actually Going On
One of the more common SLA complaints I see is agents putting a case into "On Hold" status but the SLA timer refusing to pause, especially when that on-hold period falls on a holiday. This is a specific known issue in Dynamics 365 Customer Service where the holiday schedule and the SLA pause logic don't interact cleanly.
Check your SLA configuration: go to Customer Service Admin Center → Service terms → Service-level agreements. Open the affected SLA and verify that your Business Hours calendar is correctly assigned. Then separately go to Customer Service Admin Center → Service terms → Holiday Schedule and confirm the holiday you're testing against is properly defined and linked to the same calendar the SLA uses.
A mismatch between the calendar attached to the SLA and the calendar in the holiday schedule is the #1 cause of this behavior.
SLA KPI Instance Shows "Canceled" Unexpectedly
If your SLA KPI instances are showing a "Canceled" status when they shouldn't be, check whether the case is being routed between queues. Each queue transfer can, under certain configurations, trigger a KPI instance cancellation and recreation. Review the SLA KPI re-evaluation settings in your SLA item definition and make sure the "Applicable When" conditions correctly cover post-transfer states.
Cases Not Being Created From Email, Incoming Email Configuration
The flip side of phantom case creation is no case creation at all. If legitimate customer emails are arriving but not converting to cases, check two things: first, verify the ARC rule is actually active and its conditions match your email's properties. Second, go to Settings → Email Configuration → Mailboxes and confirm the server-side sync for your support mailbox shows Success in both incoming and outgoing email columns. A mailbox showing "Failure" or "Not Run" means emails are never reaching the ARC rule to evaluate.
If you've worked through all five steps, checked your plugins, reviewed audit logs, and records are still being created by an unknown process, or if your SLA timers are misfiring after verifying all calendar configurations, it's time to open a support ticket. Specifically escalate if: your audit logs show record creation events with no identifiable "Changed By" user, you're seeing the "Warning message on SLA KPI instances" error in the Solution Health Hub with no clear fix, or your agent dashboard is showing authentication errors that persist after a cache clear and re-login. Go to Microsoft Support and open a ticket under Dynamics 365 Customer Service, request a senior engineer familiar with Dataverse and ARC rule architecture specifically.
Prevention & Best Practices
The best Dynamics 365 Customer Service troubleshooting session is the one you never have to have. I've watched the same organizations hit the same issues over and over simply because they didn't put basic governance in place after the initial deployment. Here's what actually works.
Document every ARC rule at creation time. Sounds obvious. Nobody does it. When you create an ARC rule, immediately add a description field entry that includes the rule's business purpose, the date it was created, and who owns it. Three months from now when someone has to troubleshoot unexpected case creation, that description is the difference between a 10-minute fix and a 3-hour investigation.
Treat child flows as first-class objects. Every time you create an ARC rule, open Power Automate immediately afterward and locate the child flow it generated. Rename it to match the ARC rule name and add a description. Put it in a dedicated solution alongside the rule. When you later deactivate or delete the rule, you'll know exactly which flow to also turn off.
Assign a dedicated service account for ARC rule execution. Never let ARC rules run as system accounts or as the account of whoever set up the rule. Create a named service account (e.g., "crm-automation-svc@yourcompany.com"), assign it the minimum necessary security roles, and configure all ARC rules to execute in its context. This prevents the "# SSSAdminProd" ownership problem and gives you a clear audit trail.
Run Solution Health Hub checks monthly. Schedule a recurring reminder to open Solution Health Hub and run a full health check. Most SLA timer and KPI issues are detectable before they become agent-facing problems. Early detection saves your team from scrambling during a support peak.
Audit third-party integrations quarterly. External apps connected via Dataverse API are a common source of unintended record creation. Every quarter, pull the Application Users list and verify each integration is still needed, still maintained, and still operating within expected parameters.
- Enable Dynamics 365 audit logging on Account and Case entities from day one, you can't go back and get historical audit data after the fact.
- Set up a Power Automate monitoring flow that alerts your admin team whenever a new flow is created in the environment, this catches unauthorized automation before it causes problems.
- Review and tighten ARC rule conditions every time a new email domain or channel is added to your support stack.
- Keep your SLA business hours calendars and holiday schedules in sync, assign one person ownership of maintaining the holiday schedule before every public holiday season.
Frequently Asked Questions
Why are accounts being created in Dynamics 365 with no one doing anything?
This almost always comes down to one of four sources: a misconfigured ARC rule that's creating account records when it should be creating something else (like leads or contacts), an active Power Automate flow with a broad trigger condition, a background plugin registered on the Account entity's Create event, or an external application connected via the Dataverse API. The fastest way to diagnose it is to check your audit logs under Advanced Settings → Auditing → Audit Summary View, filter for Account → Create events, and look at the "Changed By" column. That will tell you exactly which process or user is responsible.
I deleted my ARC rule but cases are still being auto-created from emails, what's going on?
This is a well-known gotcha in Dynamics 365 Customer Service. When you create an ARC rule, it generates a child flow in Power Automate that runs independently of the rule itself. Deleting or deactivating the ARC rule does not automatically stop that child flow. You need to go to Power Automate, find the child flow (check under Solutions if your org uses them), and turn it off separately. Once both the rule and the flow are disabled, send a test email and confirm no new case is created.
What is "# SSSAdminProd" and why is it listed as the owner of my cases?
"# SSSAdminProd" is a Microsoft system application user account. It shows up as the owner or "Modified By" user on records when an ARC rule or Power Automate flow is running in the context of that system account rather than a user-controlled account. The practical consequence is that agents assigned to normal security roles often can't see those records because ownership is tied to a system account outside their business unit or team. The fix is to update your ARC rule's execution context to run as a named service account your team controls, and to bulk-reassign existing affected records via Advanced Find.
My SLA timer isn't pausing when I set a case to On Hold, especially on holidays. How do I fix it?
This is typically a calendar configuration mismatch. The SLA item has a Business Hours calendar assigned to it, and separately your organization has a Holiday Schedule defined. If those two aren't linked to the same calendar, the SLA engine doesn't know to pause during holidays when a case goes On Hold. Go to Customer Service Admin Center → Service terms → Service-level agreements, open your SLA, verify the Business Hours calendar. Then go to Service terms → Holiday Schedule and confirm your holidays are defined within that exact same calendar. Once aligned, test by putting a case On Hold on a configured holiday date and verify the timer pauses.
How do I find out which Power Automate flow is causing unexpected record creation?
Start in Power Automate at make.powerautomate.com. Go to Solutions first and look for flows whose names reference your ARC rules or the affected entity. If nothing obvious appears there, go to My Flows → All Flows and sort by the Modified date, flows that were modified around the same time as your ARC rule was created are the prime suspects. Open each candidate flow and check the trigger and action steps. If you see a trigger tied to email arrival or record creation and an action that creates Account or Case records, that's your flow. Turn it off and monitor for 15 minutes to confirm.
Dynamics 365 Customer Service agent dashboard keeps showing authentication errors or won't load. What should I check?
Authentication errors on the agent dashboard (particularly in Dynamics 365 Contact Center, formerly Omnichannel) are often caused by expired or misconfigured OAuth tokens between the Omnichannel service and your Azure Active Directory app registration. Start by clearing the browser cache completely and trying in a private/incognito window, this rules out stale token issues on the client side. If the problem persists, check the app registration in Azure AD for the Omnichannel application and verify the redirect URIs and API permissions are current. Also review the Omnichannel Admin Center for any alerts about channel connectivity. If the issue affects multiple agents simultaneously, it's almost certainly a server-side token or configuration problem that warrants a Microsoft Support ticket.