“Adding one sales-order line takes 20 seconds.”
That description tells us there is a problem, but it does not tell us where the problem is.
That's the consequence, but not the cause.
Those 20 seconds could be consumed by:
- Form JavaScript
- A browser or network delay
- A Dataverse request
- A synchronous plug-in
- Repeated SDK operations
- An external service called by a plug-in
- Several individually small operations adding up
Without evidence, different teams can spend days investigating their own components without identifying the real bottleneck.
I am not a technical person, but I read through webpages of articles from Microsoft and understood how to go step-by-step into identifying the cause. Here's a simplified process you can start from and go as deep as you wish.
Dynamics 365 and Power Platform provide two tools that help turn a general performance complaint into a traceable investigation:
- Live Monitor for reproducing and examining an individual session
- Application Insights for analysing correlated telemetry across users, operations and time
They serve different purposes, but they are most useful when used together.
Live Monitor and Application Insights are not interchangeable
| Tool | Best used for |
|---|---|
| Live Monitor | Reproducing a problem and watching events from one session in real time |
| Application Insights | Analysing performance trends, failures and server-side processing across many sessions |
| Both together | Following a user action from the model-driven app into Dataverse, plug-ins and external dependencies |
Live Monitor helps answer:
What happened when this user performed this action?
Application Insights helps answer:
Does this happen repeatedly, who is affected, and which server-side operation is consuming the time?
That distinction provides a useful investigation sequence.
Start with a reproducible scenario
“Dynamics is slow” is too broad to investigate effectively.
Before opening either tool, define a specific action:
- Opening an opportunity form
- Saving a work order
- Adding a sales-order line
- Loading a dashboard
- Running a command
- Changing a field that triggers JavaScript
- Completing an action that invokes a plug-in or external integration
Record the following information:
- Environment and application
- User experiencing the issue
- Table and form
- Record used for testing
- Exact action performed
- Approximate start time
- Expected response time
- Actual response time
- Whether the issue happens constantly or intermittently
- Whether other users experience the same behaviour
This information allows the same test to be repeated and makes telemetry much easier to find.
Where possible, compare:
- Affected and unaffected users
- Different forms for the same table
- Different records
- Different browsers or devices
- Different geographical locations
- Customised and minimally customised forms
The comparison often reveals whether the problem is user-specific, data-specific, network-related or linked to a particular customisation.
Step 1: Reproduce the problem with Live Monitor
From Power Apps, select the model-driven app and choose Live Monitor from the command bar. You can then launch the app from the monitoring session and reproduce the problem.
Another option is to add &monitor=true to the model-driven app URL and start the monitoring session from the command bar.
Live Monitor records important application activity, including:
- Page navigation
- Form loads and saves
- Command execution
- Network requests
- Script errors
- Form events
- Performance warnings
Avoid clicking through several unrelated processes during the recording. Start the session, reproduce the specific problem and stop. A focused trace is considerably easier to interpret.
Investigating a slow form load
For page navigation, the FullLoad event represents the complete load of the page. It waits for relevant network requests and rendering to finish before the page is considered ready.
The event includes useful properties such as:
- Total load duration
- Form ID
- Load type
- Time spent running custom JavaScript
- Attribution details for custom scripts
The attribution details can identify the publisher, solution, web resource and method associated with JavaScript execution.
This is particularly valuable when a form contains scripts from several solutions. Instead of concluding that “JavaScript is slow,” you can identify which web resource or method is contributing to the delay.
The loadType value also provides context:
0– First visit to a page type1– First visit to a particular configuration2– First visit to a particular record3– The exact record URL has already been visited
This matters because the first load can behave differently from a previously visited form. Performance comparisons should use similar load conditions.
Investigating network requests
Live Monitor also displays the network requests made while the app is running.
Review the requests around the slow action and look for:
- One request with an unusually long duration
- Several sequential requests
- Repeated calls retrieving the same information
- Failed requests followed by retries
- Large responses
- Requests to external services
- Synchronous requests that block the interface
A 20-second user experience does not necessarily mean that one server request took 20 seconds.
For example:
| Observation | Likely investigation area |
|---|---|
| Long custom script time | Client-side JavaScript |
| Fast server response but slow overall request | Network, browser queue or download |
| One slow Dataverse request | Server-side processing |
| Several repeated SDK calls | Plug-in or integration design |
| Slow external dependency | External API or network route |
| High duration only for certain users | Location, device or connectivity |
| Slow duration for every user | Shared customisation or server-side process |
The objective is to identify where the delay begins—not to assign ownership prematurely.
Step 2: Capture the correlation identifier
A Live Monitor event can provide an activity or correlation identifier for the operation.
This identifier is the bridge between the user’s monitored session and the telemetry in Application Insights.
Once you identify the slow request, record:
- Activity ID
- Timestamp
- User
- Table
- Operation
- Duration
- Any related request or error details
In Application Insights, the following query can be used to find telemetry associated with the activity:
union *
| where operation_Id contains "[ActivityIdHere]"
| order by timestamp ascThis can reconstruct the path through the application and server rather than treating each event as an unrelated log entry.
Step 3: Analyse broader telemetry in Application Insights
Power Platform can export model-driven app and Dataverse telemetry to Application Insights without requiring custom instrumentation code.
The built-in integration can provide telemetry for:
- Model-driven app page loads
- Unified Interface outbound requests
- Dataverse API requests
- Plug-in executions
- Dataverse SDK operations
- Exceptions
- External dependencies called by plug-ins
An environment or tenant administrator configures the connection through the Power Platform admin centre. Microsoft currently limits this capability to tenants with paid or premium Dataverse licences.
Find slow model-driven app pages
Model-driven app page-load information is stored in the pageViews table.
A useful starting query is:
pageViews
| project
timestamp,
name,
duration,
user_Id,
session_Id,
appModule = tostring(customDimensions.appModule),
entityName = tostring(customDimensions.entityName),
formId = tostring(customDimensions.formId),
hostType = tostring(customDimensions.hostType),
warmLatency = toint(customDimensions.warmLatency),
warmThroughput = toint(customDimensions.warmThroughput)
| order by duration descThis helps identify:
- The slowest pages
- Forms with recurring performance problems
- Users experiencing longer load times
- Differences between browser, mobile and embedded clients
- Possible network latency or throughput problems
Microsoft notes that only page loads whose duration can be measured reliably are included.
Separate network time from server time
A request can feel slow even when Dataverse processes it quickly.
Application Insights exposes network-related information such as:
- Network latency
- User location
- VPN routing
- Proxy or security inspection
- Browser processing
- Response size
- Client connectivity
This can prevent unnecessary changes to plug-ins or forms when the server is not responsible for most of the delay.
Find slow plug-ins
Dataverse plug-in executions are recorded in the dependencies table with the type Plugin.
A simple query can identify the plug-ins with the highest average duration:
dependencies
| where type == "Plugin"
| summarize
executions = count(),
averageDuration = avg(duration),
maximumDuration = max(duration)
by name
| order by averageDuration descPlug-in telemetry can include:
- Plug-in name and type
- Version
- Execution stage
- Table
- Step name
- Depth
- Duration
- Isolation type
Look beyond the plug-in itself
A plug-in may appear slow because it is waiting for something else.
Consider a plug-in that takes eight seconds to complete. The plug-in code might perform very little processing itself but wait seven seconds for an external pricing service.
Optimising the internal code would have little effect. The architecture might instead need:
- A shorter external timeout
- Better error handling
- Caching
- Reduced payloads
- An asynchronous pattern
- Removal of the external call from the user’s synchronous transaction
The end-to-end transaction view is therefore more useful than looking only at the top-level plug-in duration.
Turn the evidence into an action plan
Once the bottleneck has been identified, assign it to the team that can act on it.
That is far more actionable than saying that Dynamics 365 is slow.
A practical investigation sequence
When a user reports that Dynamics 365 is slow:
- Define one precise, repeatable action.
- Record the environment, user, record and time.
- Reproduce the action using Live Monitor.
- Identify whether the delay is in client processing, network activity or a Dataverse request.
- Capture the activity or correlation identifier.
- Find the correlated operation in Application Insights.
- Review plug-ins, SDK calls and external dependencies.
- Compare the result across users and time.
- Assign the finding to the appropriate owner.
- Repeat the same test after remediation.
Final thoughts
Performance troubleshooting becomes inefficient when every team starts with an assumption.
Live Monitor and Application Insights provide a more disciplined approach.
Live Monitor shows what happened during the user’s session.
Application Insights shows how that operation behaved across the application, Dataverse and its dependencies.
Official documentation:
- Debug a model-driven app with Live Monitor
- Analyse model-driven apps and Dataverse telemetry with Application Insights
- Telemetry events for model-driven apps
- Telemetry events for Microsoft Dataverse
- Troubleshoot form issues in model-driven apps
