How to Troubleshoot Power Platform Dataverse Errors
Why This Is Happening
I've seen this exact situation play out on dozens of tenant environments: a maker opens Power Apps on a Monday morning, tries to load a model-driven app or run a cloud flow, and gets hit with a vague "Something went wrong" banner , or worse, a silent failure with no error message at all. Power Platform Dataverse troubleshooting is genuinely one of the messier corners of the Microsoft ecosystem, because the failure can originate in four or five completely different layers before it ever surfaces as a visible error.
Dataverse isn't a single service. It's a managed relational data platform that sits inside a Power Platform environment, backed by Azure SQL and Azure Cosmos DB under the hood, and it serves as the data backbone for Power Apps, Power Automate, Dynamics 365, Copilot Studio, and increasingly, Copilot extensions. When something breaks, the error message you see in the canvas app or flow run history rarely tells you where the fault actually is.
The most common root causes I run into in the field break down like this. First, connection credential failures , the service principal or user account that owns the Dataverse connector has expired credentials or lost its security role. Second, API request throttling, your tenant hits the entitlement limits (HTTP 429 responses) and flows start queuing or failing silently. Third, plugin execution errors, a custom plugin or third-party ISV solution throws an unhandled exception that rolls back the entire transaction without telling the end user anything useful. Fourth, solution import failures, a managed solution brings in components that conflict with existing customizations or missing dependencies. And fifth, Dataverse storage capacity reaching its provisioned limit, which causes writes to fail at the database level.
Microsoft's error messages are notoriously opaque here. You might see Error code: 0x80040203, or a generic Principal user is missing prvRead privilege on entity, or just The resource you are looking for has been removed. None of those help much if you don't know where to look next.
I know this is frustrating, especially when it's blocking a business-critical flow or a customer-facing app. The good news is that once you know which diagnostic tools to reach for, Power Platform Dataverse troubleshooting becomes much more systematic. Let's work through it. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you spend an hour digging into plugin trace logs, try this. The majority of Dataverse connection errors, probably 60% of the tickets I've seen, are caused by a stale or broken connection reference. Somebody's credentials expired, a service account password rotated, or an OAuth token didn't refresh properly. This takes two minutes to check.
Open the Power Platform Admin Center at admin.powerplatform.microsoft.com. In the left rail, go to Environments, click on the affected environment, then select Resources > Connections. Look for any connection showing a red warning icon or the status "Error". Click it, hit Edit, and re-authenticate with valid credentials. If it's a service principal connection, verify the app registration in Entra ID (formerly Azure AD) still has an active client secret and the correct Dataverse API permission (user_impersonation on the Common Data Service scope).
If that's not it, your second fastest check is storage. In the Admin Center, go to Resources > Capacity. If your Dataverse database storage is at or above the provisioned limit, new records simply cannot be written, and the errors you get back won't always say "storage full." You'd be surprised how often that's the culprit on tenants that have been running for a few years without cleanup.
Still stuck? Check the Service Health Dashboard at admin.microsoft.com under Health > Service Health, and filter for Power Platform. If Microsoft is actively working an incident on the Dataverse layer, everything you're doing locally is wasted time. Confirm the platform is healthy first, then troubleshoot.
error.code and error.innererror fields buried in there almost always give you a much more specific diagnosis than the surface-level message.
The first thing to establish in any Power Platform Dataverse troubleshooting session is whether the environment itself is healthy and fully provisioned. An environment stuck in a "Preparing" or "Failed" state will cause every downstream operation, app loads, flow runs, solution imports, to fail, often with misleading errors.
Go to admin.powerplatform.microsoft.com and navigate to Environments. Click the environment name. At the top of the environment detail page, check the State field. It should read "Ready." If it says anything else, your troubleshooting starts here, not in the app.
Scroll down to the Dataverse section and confirm:
- The database URL is populated (format:
https://yourorg.crm.dynamics.com) - The version number shows a recent Dataverse build (typically a four-part version like
9.2.24094.xxxx) - The Background operations field shows no blocked jobs
For a PowerShell check, install the admin module and run:
Install-Module Microsoft.PowerApps.Administration.PowerShell -Force
Connect-AzureAD
Get-AdminPowerAppEnvironment -EnvironmentName "your-environment-id" | Select-Object DisplayName, EnvironmentType, CommonDataServiceDatabaseProvisioningStateYou should see CommonDataServiceDatabaseProvisioningState : Succeeded. Anything else, Failed, Provisioning, or null, means the environment needs to be repaired or re-provisioned through a support ticket. Once you confirm the environment state is healthy, move to the next step.
Connection failures are the most common Dataverse errors in the field. The error usually surfaces in Power Automate as "Could not connect to the service. Please check your credentials", or in Power Apps as a red banner when the app loads. The underlying cause is almost always one of three things: expired OAuth tokens, a revoked service principal secret, or a missing Dataverse security role.
Navigate to make.powerapps.com, select the correct environment from the top-right environment picker, then go to Connections in the left navigation. Find your Microsoft Dataverse connection. If it shows a warning triangle, click the three-dot menu and choose Fix connection. Sign in fresh with the account that should own this connection.
If you're using a service principal (app user) instead of a delegated user connection, which you should be in production, validate the app registration in Entra ID. Go to portal.azure.com, open App registrations, find your app, and check:
- Certificates & secrets, confirm the client secret hasn't expired
- API permissions, confirm
Dynamics CRM > user_impersonationis granted with admin consent
Then, in the Power Platform Admin Center, go to Environments > [Your Env] > Settings > Users + permissions > Application users. Confirm the app user exists and has an appropriate security role assigned, at minimum Basic User plus whatever custom role your solution requires. A Dataverse connection from a service principal with no security role will fail every time with error code 0x80040220 (Principal user missing privilege). Once the role is assigned, re-test the connection, it should show "Connected" with a green check.
If your flows are intermittently failing with a message like "429, Too Many Requests" or "The request was rejected because of Dataverse service protection API limits", you've hit the per-user API entitlement ceiling. This is one of the most misunderstood Dataverse errors, and it causes real business disruption, especially in bulk data migration flows or high-frequency automation scenarios.
Dataverse enforces three concurrent limits per user connection: a maximum of 6,000 API requests per 5-minute sliding window, no more than 52 concurrent requests at once, and an execution time limit of 20 minutes of total combined API execution time per user per 5-minute window. When you exceed any of these, the service returns HTTP 429 with a Retry-After header telling you how many seconds to wait.
In Power Automate, fix this by adding a Concurrency Control setting to your loop or parallel branch. Open the trigger, go to Settings, and set Concurrency Control to a degree of parallelism of 10 or lower. Also add a Delay action inside your loop with a value of 1 second between iterations, this alone eliminates most throttling on moderate-volume flows.
For flows that need high-volume Dataverse writes, switch your connector action from "Create a new row" to the Dataverse Connector's "Perform a changeset request" action, which batches up to 1,000 operations in a single API call, consuming only one request from your entitlement instead of 1,000. That's the single biggest throughput multiplier available to you without buying more capacity. After making these changes, re-run the flow and confirm the 429 errors stop appearing in the run history.
This is where most makers get stuck. A Dataverse operation, creating a record, updating a field, triggering a workflow, silently fails or returns a generic error, and there's no obvious indication of what went wrong. Nine times out of ten, a custom plugin or a third-party ISV-packaged plugin fired on that operation and threw an unhandled exception. The error message that bubbles up to the user is deliberately vague for security reasons. The real story is in the Plugin Trace Log.
First, confirm Plugin Trace Logging is enabled. Go to admin.powerplatform.microsoft.com, open your environment, go to Settings > Product > Features, and ensure Enable plugin and workflow tracing is set to All (not just "Exception"). Warning: this generates significant log volume, so only leave it on "All" while actively debugging, switch back to "Exception" afterward.
Now navigate to make.powerapps.com, open Solutions, click into the Default Solution or your custom solution, and look for the table called Plug-in Trace Log. Alternatively, reach it directly via:
https://yourorg.crm.dynamics.com/main.aspx?etn=plugintracelog&pagetype=entitylistSort by Created On descending. Find the trace log entry that matches the timestamp of your failed operation. Open it and read the Exception Details field. You'll see the full stack trace, including the exact line in the plugin where the exception was thrown. Common findings: a null reference on a field the plugin expected to be populated, an HTTP call to an external service timing out, or a LINQ query hitting a Dataverse row limit. Armed with that stack trace, you can either fix the plugin code or contact the ISV with a specific error to diagnose.
Solution import failures are a category of their own in Power Platform Dataverse troubleshooting, and the error log Microsoft shows you during a failed import is both the most and least helpful thing in the platform. Most helpful because it's detailed. Least helpful because it's XML, it's verbose, and it buries the actual error three layers deep.
When an import fails, you'll see a red Failed status on the Solutions page in make.powerapps.com. Click the solution name, then click See solution import details in the notification bar. This opens the import detail page. Look for any row with a red X, those are the blocking errors. Common error codes here include:
0x80048d19, A dependency is missing. The solution requires a component (another solution, a specific table, a field) that doesn't exist in this environment.0x80040216, A component is already managed by a different solution and can't be overwritten.0x8004F036, The solution version is older than what's already installed; you need to import a higher version number.
For missing dependency errors, download the error log XML, open it, and search for <missing> elements, these list exactly which component IDs are absent. Cross-reference those GUIDs against your source environment. You'll typically need to import a prerequisite solution first.
For managed layer conflicts (0x80040216), run the Solution Checker against your unmanaged customizations and look for which components are overlapping. Sometimes you need to delete the conflicting unmanaged layer before importing. Use the Solution Layers view: open the component in the solution explorer, click See solution layers, and identify which solution "owns" the component in the managed layer. Import order matters, get the base solution in first, then your customization layer on top.
Advanced Troubleshooting
Once you've exhausted the standard fixes, it's time to go deeper. These are the scenarios I see most often in enterprise and domain-joined environments where the standard UI-based approach doesn't surface the real issue.
Power Platform Dataverse Troubleshooting with PowerShell Diagnostics
The Power Apps Administration PowerShell module gives you visibility that the UI simply doesn't. Install it and run a full environment health dump:
Install-Module Microsoft.PowerApps.Administration.PowerShell -Force
Install-Module Microsoft.PowerApps.PowerShell -AllowClobber -Force
Connect-AzureAD
Add-PowerAppsAccount
# Get all environments with Dataverse and their capacity
Get-AdminPowerAppEnvironment | Where-Object { $_.CommonDataServiceDatabaseType -ne "None" } |
Select-Object DisplayName, EnvironmentName, CommonDataServiceDatabaseProvisioningState |
Format-Table -AutoSize
# Check for flows with recent failures in a specific environment
Get-AdminFlow -EnvironmentName "your-env-id" | Where-Object { $_.Statuses -contains "Failed" } |
Select-Object DisplayName, CreatedTime, LastModifiedTime | Sort-Object LastModifiedTime -DescendingOn-Premises Data Gateway Failures with Dataverse
If your Power Platform solution connects to on-premises data sources through an on-premises data gateway, and that gateway is unhealthy, Dataverse connection references that depend on it will fail with misleading cloud-side errors. In the Power Platform Admin Center, go to Data > Gateways. Check the gateway status. A degraded gateway shows as yellow. On the gateway machine itself, open Event Viewer and check Applications and Services Logs > On-premises data gateway service. Event IDs 10000 (gateway offline) and 10016 (authentication failure to the cloud relay) are the most common.
Restart the gateway service: open Services.msc, find On-premises data gateway service, right-click, and choose Restart. If that doesn't help, re-register the gateway in the Power Platform Admin Center under Data > Gateways > [Gateway name] > Settings > Re-register.
Dataverse Audit Log Errors and Compliance Failures
In environments with auditing enabled, certain Dataverse operations can fail if the audit log table itself is near capacity or if audit settings conflict with the operation. Go to Admin Center > Environments > Settings > Audit and logs > Audit settings and confirm the retention policy isn't set to an impossibly short window that's causing cascading deletes during write operations. If audit log storage is contributing to your capacity issues, you can purge old audit data from Settings > Audit and logs > Audit log management, this alone can recover significant Dataverse storage in tenants that have been running for years.
Diagnosing Dataverse Search Indexing Issues
If your model-driven app users report that search returns no results or stale results, the Dataverse relevance search index may be out of sync. In the Power Platform Admin Center, navigate to Environments > [Your Env] > Settings > Features and toggle Dataverse Search off and back on. This triggers a full re-index, which typically completes within 15–30 minutes for environments with under a million records.
0x8004E00C (database provisioning failure) during environment creation; your tenant-level storage shows as exceeded even after verified cleanup; or a managed solution from Microsoft (Dynamics 365, Copilot Studio) imports with dependency errors that shouldn't exist on a properly licensed tenant. These are platform-layer issues that no amount of maker-side troubleshooting will resolve. When you open the ticket, attach the environment ID (found in Admin Center under the environment URL), the exact error codes, and the solution import XML log if applicable, this cuts resolution time significantly.
Prevention & Best Practices
The honest truth about Power Platform Dataverse troubleshooting is that most of the issues are avoidable with a few consistent habits. I've seen the same organisations repeatedly fight the same fires, throttling, storage overflows, plugin failures, because nobody set up the guardrails that prevent them in the first place.
Monitor before it breaks. Set up Dataverse capacity alerts in the Power Platform Admin Center under Resources > Capacity > Alerts. Configure an alert at 80% of your database storage allocation. That gives you time to clean up or buy more capacity before writes start failing. Do the same for API limit consumption, use the Power Platform Admin Analytics under Analytics > Dataverse to watch weekly API usage trends.
Use service principals, not user accounts, for production connections. User-owned connections break when someone leaves the organisation, changes their password, or has their MFA policy updated. A service principal with a managed identity or a certificate-based credential is far more stable. Create an app user in each Dataverse environment, assign it the minimum required security role, and configure all production flows and apps to use it.
Version your solutions properly before every import. Managed solutions that don't increment their version number will fail to import if the same version is already installed. Build your CI/CD pipeline, or even your manual release process, to always increment the patch version before packaging. Use the Solution Checker in make.powerapps.com as a pre-flight check before every import; it catches missing dependencies and compatibility issues before they cause a production failure.
Keep plugin registrations lean and tested. Every synchronous plugin step adds latency to every operation on that table. Audit your plugin registrations periodically using the Plugin Registration Tool from the Power Platform Tools GitHub repo. Remove plugins registered against events they no longer need to fire on, and convert synchronous post-operation plugins to asynchronous wherever the business logic allows it, this alone reduces the blast radius of plugin exceptions dramatically.
- Schedule a monthly Dataverse storage review, delete or archive stale records from audit logs, email attachment tables, and background job history
- Enable the Environment-level backup in Admin Center (daily automatic backup is free) so you have a restore point before any major solution import
- Rotate service principal client secrets on a calendar reminder, 90 days before expiry is a safe window; set the next rotation reminder the day you rotate
- Add a Scope to every Power Automate flow that touches Dataverse, this prevents a single failing loop iteration from failing the entire flow run and makes error messages far more specific
Frequently Asked Questions
Why does my Power Automate flow keep failing with "Principal user is missing prvRead privilege" even after I assigned a security role?
Security role assignments in Dataverse can take a few minutes to propagate, but that's usually not the issue. The more likely cause is that the security role you assigned doesn't include read access on the specific table your flow is trying to query, or it does, but the flow's connection is still using old cached credentials. Open the connection in make.powerapps.com > Connections, delete it, and recreate it fresh after confirming the security role is fully applied. Also double-check that the role is assigned at the Business Unit level that matches where the records live, cross-BU access needs explicit table-level privileges, not just BU-level ones.
My Dataverse environment shows "Ready" in Admin Center but Power Apps still won't load data, what gives?
Environment state and Dataverse service health are two different things. The environment can show "Ready" while the Dataverse web API endpoint itself is experiencing latency or a partial outage. Go to admin.microsoft.com > Health > Service Health and look specifically for incidents tagged under Power Apps and Power Platform, these are separate entries. Also clear your browser cache and try a private/incognito window; there are known issues where stale MSAL token caches in the browser cause Dataverse API calls to return 401 errors even with valid credentials.
How do I fix "The import of solution failed" with error code 0x80048d19, missing dependency?
Error 0x80048d19 means the solution you're importing references a component, a table, column, flow, or another solution, that doesn't exist in the target environment. Download the detailed XML log from the import failure screen and open it in a text editor. Search for <MissingDependency> elements, each one will list a component display name and GUID. Go back to your source environment and find which solution contains that component, then import that prerequisite solution into the target environment first. Re-run your original import after all dependencies are satisfied.
Is there a way to check Dataverse API usage before we hit the throttling limit?
Yes, the Power Platform Admin Center has a built-in analytics dashboard for exactly this. Go to admin.powerplatform.microsoft.com > Analytics > Dataverse and select your environment. The API calls chart shows daily and weekly consumption broken down by user, connector, and operation type. You can also retrieve the current user's remaining API call entitlement programmatically: make a GET request to https://yourorg.api.crm.dynamics.com/api/data/v9.2/ and inspect the response headers, x-ms-ratelimit-remaining-burstlimit and x-ms-ratelimit-remaining-timetothrottle tell you exactly how much headroom you have in real time.
Dataverse storage is at capacity but I can't find what's taking up space, how do I audit it?
The best tool for this is the Power Platform Admin Center Capacity report at admin.powerplatform.microsoft.com > Resources > Capacity > [Your Env]. It breaks storage into three buckets: Database, File, and Log. If "Log" is the culprit, it's almost always audit log data, purge it from Settings > Audit and logs > Audit log management. If "File" is high, look at email attachments stored in the Email Activity table and at SharePoint integration settings, Dataverse can be configured to offload attachments to SharePoint, which removes them from File storage. If Database is high, query the msdyn_dataanalyticsreport table or use the Table statistics view in the solution explorer to find which tables have the most rows.
My Dataverse plugin trace log shows "ISV code threw an exception" but no stack trace, how do I get more details?
An empty or minimal exception detail in the plugin trace log usually means the plugin caught the exception internally and re-threw a generic InvalidPluginExecutionException without passing the original exception as the inner exception. Ask your ISV or plugin developer to update the catch block to use throw new InvalidPluginExecutionException(e.Message, e) instead of just throw new InvalidPluginExecutionException(e.Message), the second parameter preserves the full stack trace. While waiting for that fix, enable trace logging at All level (not just Exception) and look for the trace messages written by the plugin before the crash point, most well-written plugins log their progress, and those messages will show you exactly how far execution got before failure.