Business Central Slow Queries: Causes, Fixes, Monitoring

If Dynamics 365 Business Central feels sluggish, the culprit is often the database work happening underneath: a SQL query that takes too long or a query that’s fast but spends most of its time waiting (locks, resource contention, etc.). The trick is not guessing — it’s identifying which of those you’ve got, then fixing the right thing.

Below is the practical, no-mysticism breakdown we use to diagnose and resolve “queries taking too long” in Business Central.

What “slow queries” looks like in the real world

You’ll typically hear complaints like:

• List pages take ages to open, filter, sort, or move between pages

• Posting hangs or intermittently times out (especially at busy times)

• Reports degrade from seconds to minutes over time

• OData/API calls get slow as volumes grow

• Month-end turns BC into treacle

Why Business Central queries take too long

1) Missing or poorly aligned indexes (keys)

Business Central filtering and sorting relies heavily on keys. If users filter/sort on fields that aren’t supported by an appropriate key, SQL often ends up scanning far more data than necessary.

How to spot it

• Use the Database Missing Indexes page (built into BC) to see where the platform thinks indexes would help.

How to fix it

• Add targeted keys (often via table extensions in SaaS) that match the real filters/sorts users actually use.

• Be selective: every additional index has a cost (writes, maintenance). Don’t turn your database into an index museum.

2) FlowFields and expensive calculations at scale

FlowFields are great until they’re calculated across large lists or inside loops. Then you get the classic “one screen = a pile of database work” problem.

Common triggers

• List pages displaying multiple FlowFields over large datasets

• Custom code that calls CalcFields() repeatedly in loops

• Totals/availability calculations that should be aggregated, not row-by-row

How to fix it

• Reduce the number of FlowFields shown on high-traffic lists.

• Move heavy totals off the list (drilldown, factbox, separate page).

• Redesign logic to calculate in sets (where possible) rather than per-record.

3) Waiting, not running: locks, lock timeouts, and deadlocks

Sometimes the query isn’t slow — it’s blocked. Posting routines, warehouse activity, job queue tasks, and integrations can hold locks long enough to stall other sessions.

How to spot it

• Use telemetry signals for database deadlocks and database lock timeouts to confirm whether users are waiting on locks.

How to fix it

• Stagger heavy job queue tasks away from peak user hours.

• Review customisation patterns that write records in conflicting order (deadlock bait).

• Where relevant, reduce “chatty” integration patterns (lots of small writes).

4) Too much data retrieved (wide rows, too many fields)

Even when record counts are reasonable, you can still be slow if you’re pulling far more fields than you need — especially in environments with lots of table extensions (wider rows, extra joins, more IO).

Developer fix (high impact)

• Use partial records via SetLoadFields() so you only load the fields you actually need. This is specifically intended to improve performance for looping constructs (reports, OData pages, processing code) and is particularly beneficial when tables are extended.

5) “Short but constant” queries that quietly crush performance

A single query taking 200ms isn’t scary… until it runs 10,000 times per hour because of a loop, page trigger, or integration pattern.

How to spot it

• Enable Additional logging from the Help & Support page to capture all SQL queries for a short period for a given session — useful for finding frequently executed queries, not just the long ones. Microsoft documents this approach and notes minimum versions for Online/On-prem.

How to fix it

• Reduce round-trips (set-based logic, better filtering, fewer repeated lookups).

• Fix the underlying pattern rather than “making SQL faster”.

A simple diagnosis path that avoids guesswork

Step 1: Reproduce with specifics

Capture:

• Page/report/process name

• Filters used

• Company

• Time of day (peak vs quiet)

• “Always slow” vs “intermittent”

Step 2: Use telemetry first (because it’s objective)

Microsoft’s telemetry ecosystem covers key signals like long running SQL operations, waits, lock timeouts, deadlocks, and more.
For deep dives into query behaviour for a session, use Additional logging briefly and deliberately.

Step 3: Classify the problem and apply the right fix

What you can do right now

Quick wins (often immediate)

• Remove non-essential FlowFields from busy lists

• Tighten default filters (especially date ranges and “open only” views)

• Move heavy calculations off page open

• Reschedule job queue entries so they don’t fight users for the same resources

Medium-term fixes (the ones that “stick”)

• Add targeted keys based on evidence (Missing Indexes + telemetry), not hunches

• Fix “chatty” patterns: lots of tiny queries/writes

• Use partial records (SetLoadFields) in loop-heavy code paths

• Reduce lock contention in posting and batch processes

FAQs: Business Central slow queries

Why a performance dashboard is worth it

Most companies only look at performance when users are already shouting. That’s like servicing a car when the engine’s on fire.

A lightweight dashboard built from Business Central telemetry (Application Insights-based) helps you spot:

• Top slow pages/reports/processes

• Whether issues are execution time or wait/locking

• Regressions after extensions/updates

• Patterns by time-of-day and workload

Business Central’s telemetry capability is explicitly designed for this kind of monitoring (including long-running SQL operations, waits, lock timeouts, and deadlocks).

If you want to start monitoring Business Central with a dashboard get in touch.