You open a customer list and wait. You post a sales order and wait. You run a report and go get coffee. If that sounds familiar, you are not imagining things, and you are definitely not alone. Business Central performance complaints are one of the most common reasons companies reach out to us, usually after months of frustration and finger pointing between users, IT, and their original implementation partner.
Here is the good news: in most cases, a slow Business Central environment is fixable without ripping anything out. The bad news is that the cause is rarely one single thing. It is usually a stack of small problems, such as inefficient custom code, bloated data, poorly designed reports, and unmonitored integrations, that compound over time. Our team sees the same 10 culprits again and again, and this guide walks through each one with practical fixes you can start applying today.
Quick answer: Business Central usually slows down because of inefficient custom AL code, heavy FlowFields on list pages, unoptimized reports, unmanaged integrations and API calls, data and dimension bloat, misconfigured job queues, too many unused extensions, missing database indexes, outdated versions, or client-side and network issues. Fixing performance starts with telemetry to identify the real bottleneck, then targeted fixes rather than guesswork.
First, Figure Out Where the Slowness Actually Lives
Before touching anything, ask one question: is the whole system slow, or are specific actions slow?
Whole-system slowness (every page, every user, all day) usually points to environment-level issues like version lag, extension conflicts, or capacity problems. Action-specific slowness (one report, one posting routine, one list page) almost always points to code, data, or design problems in that specific object.
Users rarely describe this accurately. "The system is slow" often means "the two screens I use most are slow." Get specific before you spend money on fixes. The 10 fixes below are ordered roughly from most common to least common based on what we find in real environments.
Fix 1: Enable Telemetry and Stop Guessing
Business Central has built-in telemetry that streams performance data to Azure Application Insights: long-running SQL queries, slow AL methods, page load times, report execution times, deadlocks, and more. Most companies never turn it on.
This should be your first move because everything else depends on it. Without telemetry, performance tuning is guesswork. With it, you can see that a specific custom event subscriber fires 400 times during sales posting, or that one report scans 2 million records to return 50 rows.
Setting up an Application Insights resource takes under an hour. If your team has not worked with Azure monitoring before, our team can configure telemetry dashboards and alert rules so slow queries surface automatically instead of waiting for user complaints.
Fix 2: Audit Custom AL Code for the Usual Offenders
Custom extensions are the number one performance killer we find in the field. Business Central out of the box is fast. Business Central plus five years of accumulated customizations written under deadline pressure is a different story.
The most common AL performance mistakes:
- Missing SetLoadFields. Loading every field on a record when the code only needs two or three. On wide tables like Item or Customer, this multiplies data transfer for no reason.
- FindSet loops that should be queries or aggregations. Looping through 100,000 ledger entries in AL to sum a value that a CalcSums call or query object could return in milliseconds.
- Event subscribers on high-traffic events. A subscriber on OnAfterModify of the Sales Line table runs every single time any sales line changes anywhere in the system. Heavy logic in these subscribers slows down everyone.
- Nested loops with database calls inside. A classic N+1 pattern where each record in an outer loop triggers additional reads.
If your customizations were built quickly to patch gaps, this audit tends to uncover deeper design issues too. We covered this pattern in detail in our piece on without proper planning, and the same shortcuts that cause functional problems usually cause performance problems.
Fix 3: Tame FlowFields and Heavy List Pages
FlowFields are calculated on the fly. That is fine on a card page showing one record. On a list page showing 50 rows, each FlowField triggers a calculation per row, and some FlowFields aggregate thousands of underlying ledger entries each.
Practical fixes:
- Remove FlowFields from list page factboxes and columns where users do not actually need them.
- Move expensive calculations to on-demand actions instead of automatic display.
- Check personalizations. Users often add FlowField columns themselves, then complain the page got slow. Review and reset personalizations on the slowest pages.
- For lists that must show aggregated values, consider query-based pages or precalculated fields updated by background jobs.
Fix 4: Rebuild the Reports Everyone Complains About
Every Business Central environment has that one report. It takes 20 minutes, everyone runs it anyway, and it was probably migrated from NAV a decade ago.
Slow reports usually suffer from row-by-row processing in AL, missing filters that force full table scans, or trying to do analytical work inside an operational database. The fix depends on the report:
- Operational reports (pick lists, invoices, statements) should be optimized in AL with proper keys and filters.
- Analytical reports (sales trends, margin analysis, aging across years) do not belong in Business Central at all. Push that data to Power BI, where it can be modeled once and queried instantly. Our team regularly cuts reporting time from minutes to seconds by moving analytical workloads out of the ERP.
Fix 5: Put Integrations on a Leash
Integrations are silent performance killers because they run in the background and nobody watches them. An ecommerce connector polling every 30 seconds, a warehouse system pushing updates row by row, or a poorly built middleware layer hammering OData endpoints can consume server capacity that interactive users need.
What to check:
- Polling frequency. Does the integration really need to sync every minute, or would every 15 minutes do?
- Batch versus row-by-row. APIs should send batches. One API call with 500 records beats 500 API calls with one record.
- Web service throttling limits. Business Central enforces operational limits on API calls. Integrations that ignore them cause retries and cascading slowness.
- Sync timing. Move heavy syncs to off-peak hours where the business allows it.
If your connectors were built ad hoc over the years, a structured review pays for itself quickly. Our practice focuses on exactly this: consolidating fragile point-to-point connections into monitored, batch-oriented flows.
Fix 6: Clean Up Data and Dimension Bloat
Business Central slows down as tables grow, but not evenly. The pain concentrates in a few places:
- Ledger entry tables with millions of rows and reports that scan them without date filters.
- Change log configured to track everything on every table. This is extremely common and extremely expensive. Track only what audit actually requires.
- Dimension combinations. Excessive dimension values multiply the dimension set entries generated on every transaction.
- Stale records. Thousands of blocked items, dead customers, and abandoned documents that still get scanned by lookups and reports.
Use retention policies to archive change logs, posted documents, and other high-churn tables. And if your original data migration dumped years of messy legacy records into the system, that is often the root cause. We documented our cleanup approach in the , and the same principles apply retroactively.
Fix 7: Fix Job Queue and Posting Bottlenecks
Posting routines are transactional. When a user posts a large sales order, Business Central locks the relevant records until the transaction completes. If multiple users post simultaneously, or a background job holds locks during business hours, everyone waits on everyone.
Fixes that consistently help:
- Enable background posting so users get their screen back immediately while posting happens in the job queue.
- Schedule heavy batch jobs (adjust cost, batch posting, MRP runs) outside working hours.
- Stagger job queue entries instead of letting them all fire at 8:00 AM.
- Review any custom code that runs inside posting events, because it extends lock duration for every user.
Fix 8: Uninstall Extensions You Do Not Use
Every installed extension adds table extensions, event subscribers, and upgrade overhead, whether anyone uses it or not. Environments that have been live for a few years typically carry trial apps that were never purchased, tools from vendors no longer used, and duplicate functionality across multiple apps.
Run through your installed extensions list quarterly. If nobody can explain what an app does and who uses it, test its removal in a sandbox. Fewer extensions mean fewer subscribers firing on every transaction, faster upgrades, and fewer conflicts.
Fix 9: Get Current on Versions
Microsoft ships performance improvements in nearly every Business Central release: smarter database access patterns, improved caching, faster page rendering, and platform-level fixes you cannot replicate yourself. Environments stuck several versions behind are leaving free performance on the table.
This matters even more for companies still running on-premises NAV or older Business Central versions, where hardware sizing and SQL maintenance add another layer of variables. If you are in that camp, our guide on moving from explains what the jump to the cloud version actually involves and why performance is one of the biggest wins.
Fix 10: Rule Out Client-Side and Network Issues
Sometimes Business Central is fine and the problem is everything around it. Before blaming the ERP, verify:
- Browser health. Excessive extensions, ancient hardware, or hundreds of open tabs make any web app feel slow.
- Network latency. Business Central is a cloud service. VPNs that route traffic through distant data centers add latency to every click. Test with and without VPN.
- Environment region. If your Business Central environment is hosted in a region far from your users, every request pays a distance penalty. Region selection matters at setup time.
- Role Center design. A Role Center stuffed with cues, charts, and stacked queries recalculates all of it at every login. Trim it.
When Fixes Are Not Enough
Occasionally we open the hood and find that performance is a symptom, not the disease. If the original implementation forced bad processes into the system, buried core logic in unmaintainable customizations, or skipped design entirely, tuning individual objects becomes an endless game of whack-a-mole.
In those cases, the honest conversation is about a structured rather than another round of patches. It sounds drastic, but a clean rebuild on current best practices is often cheaper over three years than perpetually firefighting a broken foundation. We have walked several companies through this decision, including one case where we that had been limping along for two years.
A Practical 30-Day Performance Plan
If you want a simple sequence to follow:
- Week 1: Enable telemetry, interview users to identify the five slowest actions, and inventory installed extensions.
- Week 2: Use telemetry data to rank the actual bottlenecks. Remove unused extensions and reset heavy page personalizations.
- Week 3: Fix the top three code and report offenders. Enable background posting and reschedule batch jobs.
- Week 4: Set up retention policies, review integration polling and batching, and document a quarterly performance review process.
Most environments see noticeable improvement within the first two weeks, because the first fixes target the problems users feel most.
Frequently Asked Questions
Why is Business Central so slow all of a sudden? Sudden slowness usually traces to a recent change: a new extension or update, a new integration, a change log configuration change, a large data import, or a batch job now running during business hours. Check telemetry and recent admin center activity for anything that changed in the days before the slowdown started.
Is Business Central slower than on-premises NAV? Not inherently. Cloud Business Central adds network latency to each interaction, but the platform itself is heavily optimized and improves with every release. Perceived slowness after migration usually comes from customizations that were ported without optimization, not from the cloud itself.
How do I check what is making Business Central slow? Enable telemetry with Azure Application Insights, then review long-running SQL queries, slow AL execution, and page load events. Inside the client, the Performance Profiler tool lets you record a specific slow action and see exactly which extensions and methods consumed the time.
Can too many users slow down Business Central? User count alone rarely causes slowness in the cloud version. Concurrent heavy operations do. Twenty users browsing is fine; five users simultaneously posting large orders while a batch job holds locks is not. Scheduling and background posting solve most concurrency pain.
Will upgrading to the latest version fix performance issues? It helps, because Microsoft ships performance improvements continuously, but it will not fix inefficient custom code, data bloat, or badly designed reports. Treat upgrades as one fix among ten, not a silver bullet.
Get a Performance Review From People Who Do This Weekly
Every fix in this article is something your team can start investigating today with telemetry and the Performance Profiler. But if you would rather have experienced eyes on it, we run structured performance assessments that combine telemetry analysis, code review, and data profiling to pinpoint exactly where your environment is bleeding time.
As a , we have tuned environments ranging from 10-user distributors to multi-company manufacturers, and the pattern is always the same: a handful of specific, fixable problems hiding behind the vague complaint that "the system is slow." Reach out, and we will help you find yours.