Mastering the Performance Profiler in Microsoft Dynamics 365 Business Central 

A page that takes several seconds to open, a report that stalls, a posting routine that overruns its window: these get reported as “Business Central is slow.” That isn’t a diagnosis. The Performance Profiler turns it into one by showing which app, object and method used at the time. 

This guide covers how the profiler works, how to record and read a profile, how to catch intermittent problems, and when to move to the AL Profiler in Visual Studio Code. No developer background needed for the first half. The second half goes deeper for those who want it. 

QUICK ANSWER 

The Performance Profiler in Dynamics 365 Business Central records a slow process and shows which apps, objects and methods used the time. Choose Start, repeat the slow action, then choose Stop. For problems you can’t reproduce on demand, Profiler Schedules capture profiles automatically. The profiler uses sampling, so timings are approximate. Use it to find where to look, then confirm the fix with a re-test. 

What Is the Performance Profiler in Business Central? 

Think of it as a flight recorder for one slow action. The Performance Profiler is a page in Business Central that records a snapshot of a process while it runs. Microsoft Learn says it watches every app involved: Microsoft’s own apps, such as the Base Application and System Application, plus third-party apps, such as Marketplace apps and per-tenant extensions (PTEs). 

It runs in the web client, so consultants and administrators can capture a scenario without a developer environment. The results go down to individual objects and methods, which makes it much easier to decide who should fix the problem. 

At a glance:

• How it measures: Sampling: periodic snapshots of the AL code that is running 
• What you get: Active Apps chart, Time Spent by Application Object, Call Tree, and a downloadable .alcpuprofile file 
• Best for: Slow pages, reports, postings and jobs you can reproduce, or capture with a schedule
• Main Limit: Timings are approximate, and very short calls can be missed   

Which features you have depended on your Business Central version, so here is the short history: 

Which Performance Tool Should You Use? 

The profiler is one tool among several. Microsoft’s performance guidance lays them out like this: 

The easy rule: if you can reproduce the problem, use the in-client profiler. If you can’t, schedule a capture. If you suspect a pattern over time, check out telemetry. 

How Do You Record a Profile? 

1. Choose the Tell me what you want to do icon, enter Performance Profiler, and select the page. You can also go to Help & Support and choose Analyze Performance.
2. Choose the Open this page in a new window icon in the upper-right corner. Microsoft notes this makes starting and stopping easier.  
3. In your main window, go to the page or process you want to record, but don’t run it yet. 
4. In the profiler window, choose Start, then do the slow action. 
5. Choose Stop when it finishes. 

How Do You Read the Results? 

Go broad first, then detail. Most cases are solved in the first two steps. 

1. Active Apps 

After you stop, the Active Apps chart lists every app that was active, meaning it was running or called other apps. The duration shows how much recorded activity was tied to that app and where a closer look may pay off. Use App Name and App Publisher to group the time per app or per vendor. It answers the first question: is the time in Microsoft’s base code or in an extension? 

2. Time Spent by Application Object 

Turn on Show technical information to add two FastTabs. The first lists the pages, codeunits, tables and other objects involved. Time Spent is how long the object was active during the recording. Samples is how many times the profiler caught it running. Sort by Time Spent. One object holding most of the time is a strong lead. 

3. Call Tree 

The second FastTab shows the recorded call stack as a hierarchy. Two columns are easy to mix up. Self Time is time inside the method only, excluding the calls it makes. Total Time is Self Time plus those calls. Start at the top and keep expanding the branch with the largest Total Time. Then compare the two columns: 

4. SQL calls 

Microsoft Learn says that starting with 2025 release wave 2, sampling profiling can track SQL calls in the in-client profiler and in Visual Studio Code snapshots. So you can tell whether slowness comes from AL code or SQL, see the actual SQL calls, and copy the queries. 

A Worked Example (Illustrative) 

The numbers below are invented to show the reading order. This is not a Sarakadiya client case. Say posting a sales order takes far longer than users expect. You record just the Post action and open the Call Tree: 

Read it from the top. The base process barely spends any time itself. Almost all of it sits under one extension, and the last method has a Self-Time close to its Total Time, so its own code is the hot spot. Share the profile with the publisher, then disable the extension in a sandbox and record again to confirm. 

Which Patterns Should You Look For? 

Once you have a few profiles behind you, the same shapes keep turning up. Here is how to read them: 

Why Are the Results Approximate? 

The profiler doesn’t time every call. It samples which AL code is running at evenly spaced intervals, for example every 100 milliseconds. Picture a photo every 100 ms: a call shorter than the gap between photos can slip between frames. Microsoft’s documentation says the same in plain terms: very short code might not be captured, and durations are approximate. 

If short calls seem to be missing, choose a smaller interval. Sampling sessions also have server limits of 10 minutes and 2,000 stack frame entries, so keep recordings short. Record twice, and treat one profile as strong evidence, not a verdict. 

What it can’t tell you. It won’t show patterns over time, so use telemetry for that. If little time is spent in AL code, Microsoft notes the delay may sit elsewhere, such as system functionality. And the same action can behave differently for another user, company or data volume.

How Do Profiler Schedules Work? 

Some problems only show up for one user, outside business hours, or when scheduled jobs overlap. A schedule defines time slots and filters for a user. While it runs, the profiler watches for matching activity and creates a separate profile for each one. 

1. Search for Profiler Schedules, or find it under Help & Support, then choose New and add a description. 
2. Select the user to profile, such as the person who reported the problem, and the activity type. 
3. Set a start and end time. For intermittent problems, Microsoft says a longer schedule, even several days, can help. 
4. Close the card. Recording starts automatically. 

1. Permissions: administrators can create schedules for themselves and others. Other users can create schedules for themselves. 
2. Duration: a schedule runs for at most one week, and profiles are kept for one week after it finishes. Switch off Enabled to stop early. 
3. Overhead: only the selected user and activity type are affected. Microsoft says AL code overhead is typically around 10%. 
4. Debugging: you can’t attach the debugger to a session while scheduled profiling is on for it. 

Two settings keep the data useful. Sampling Frequency controls how often samples are taken. Activity Duration Threshold filters out short activities you don’t care about. To review results, select the schedule and choose Open Profiles. Each row on the Performance Profiles page is one activity, with columns such as Activity Duration, AL Execution Duration, and the duration and number of SQL calls, HTTP calls and Platform Calls. 

The Correlation ID matches the Operation ID in Application Insights, so you can link a profile to telemetry or give it to support. Profiles are processed in the background, so use Refresh if they’re slow to appear.

How Do You Share and Reuse Profiles? 

Four actions on the profiler page cover it. Share sends a link to the company behind the app you suspect. Download saves an .alcpuprofile file you can archive, attach to a ticket or copy to OneDrive. Upload reopens a downloaded file, one at a time, so you can analyze a client’s profile without access to their environment. Clear removes the current data. The same file opens in Visual Studio Code, so a consultant can capture and a developer can dig deeper. 

In-Client Profiler vs. AL Profiler 

Microsoft calls the in-client profiler a simplified version of the AL Profiler for AL in Visual Studio Code. 

Move to the AL Profiler when you need exact timings and call counts, want to jump from a hot path straight to the AL source, or need to compare two versions of an implementation. 

Profiling With an AI Agent (Preview) 

Microsoft Learn describes a Performance Profiling MCP server that lets an AI agent set up a schedule for a slow session, collect the profiles and explain what’s slow. MCP stands for Model Context Protocol. It applies to Business Central 2026 release wave 2 and later, and Microsoft labels it a preview, available with a prerelease of runtime 18 and Business Central Server version 29. The window defaults to 5 minutes and can go up to 1 hour. You need the numeric session ID, the Business Central MCP server must be enabled, and profiling another user’s session requires the D365 ATTACH DEBUG permission set. Captured profiles can contain sensitive business data, so handle local files securely. 

A Repeatable Troubleshooting Workflow 

1. Define “slow.” Agree with users on the acceptable time for the action. Microsoft advises quantifying it. 
2. Reproduce it with the same user, company, record and filters. 
3. Profile it. Use the in-client profiler if you can repeat it, or a Profiler Schedule if you can’t. 
4. Read in order: Active Apps, Time Spent by Application Object, Call Tree, then SQL. Use App Publisher grouping when one vendor has several apps. 
5. Change one thing at a time: setting, data, extension updates, or code. Compared with and without an extension in a sandbox is a quick way to separate base from added. 
6. Profile again and compare with your saved baseline. Download and archive profiles so you can prove the fix. 

If you escalate to an ISV, partner or Microsoft support, send the steps to reproduce, the user, company and data used, your Business Central version and extensions, the profile file or shared link, the Correlation ID for scheduled profiles, the sandbox result with the suspect extension disabled, and expected versus actual duration. 

Mistakes that waste time 

• Recording a long stretch of unrelated clicks 
• Profiling a different user, company or record than the complaint 
• Treating one recording as proof 
• Blaming an extension before checking Base Application and SQL
• Leaving a schedule on longer than needed
• Skipping the baseline, so nobody can prove the fix worked   

How This Guide Was Verified 

We reviewed this guide against Microsoft Learn’s Performance Profiler overview, Scheduled performance profiler overview and AL Profiler overview on September 29, 2026. Three things can change after that: features marked preview, behavior that depends on your Business Central version, and menu or page names. Where a detail depends on the version, the guide says so. Anything labeled illustrative is not a client case study. 

How Sarakadiya Can Help

Sarakadiya is a Microsoft Dynamics 365 and Business Central-focused technology partner. For performance problems, we can help review slow processes, interpret profiles, and work out whether the fix belongs in setup, data, an extension or an integration. That could include Business Central support and optimization, custom development and extension tuning, or Business Central consulting for wider reviews. 

Key Takeaways

• The profiler turns “the system is slow” into evidence: which app, object and method. 
• Read results in order: Active Apps, Time Spent by Application Object, Call Tree, then SQL. 
• Self-Time versus Total Time shows whether a method is slow itself or waiting on its calls. 
• Sampling is approximate, so record twice and confirm every fix with a re-test. 
• Use short Profiler Schedules for intermittent problems and share profiles so every escalation comes with evidence. 

Slow Pages in Business Central? Start With Evidence. 

When Business Central gets slow, the first step shouldn’t be guessing. Profile the scenario, see where the time goes, and then decide whether the fix belongs in configuration, data, an extension, SQL or an integration. If you want help interpreting profiler results or building a practical optimization plan, talk to Sarakadiya. We’ll review the slow scenarios and help you build a fix list. 

Frequently Asked Questions