// article
When a Business Central posting routine becomes slow, adding capacity or rewriting the largest procedure is rarely the best first move. Posting touches validation, number series, dimensions, inventory, tax, ledger entries, events, extensions, and database locks. A delay that appears in one button can originate in configuration, data volume, an event subscriber, a report, an integration, or another session.
The correct sequence is evidence, isolation, correction, and regression testing.
Replace "posting is slow" with a reproducible case: document type, line count, dimensions, item tracking, warehouse configuration, extension versions, company, environment, time, user path, and observed duration. Compare a fast and slow example. If the issue is intermittent, record the time window and correlation details needed to find the session in telemetry.
Do not benchmark in production by repeatedly posting business documents. Reproduce with representative, anonymized data in a sandbox or container where the team can run diagnostics safely.
Business Central can emit environment and extension telemetry to Azure Application Insights. Relevant signals include long-running AL methods, long-running SQL queries, database lock timeouts, deadlocks, report execution, web-service requests, and extension lifecycle events. Start with the operation's time range and identify whether the elapsed time is concentrated in AL, SQL, an external call, or lock waiting.
Telemetry is especially valuable when the problem cannot be reproduced by a developer. It shows what happened in the actual environment without requiring speculative logging changes for every incident.
Use the AL Profiler or Microsoft's performance tooling in a nonproduction environment. Capture a baseline before changing code. The goal is to identify expensive call paths and counts, not simply the procedure with the largest total time. A small method called thousands of times can matter more than one visible posting procedure.
Inspect subscribers introduced by every installed extension. Event-driven customization is upgrade-safe, but a subscriber still runs inside the publisher's flow. Repeated reads, unnecessary validations, synchronous HTTP calls, or broad calculations in a subscriber can add latency to every posting.
Microsoft's AL performance guidance emphasizes doing less work and loading only what is needed. In a hot path, review:
SetLoadFields can reduce loaded fields;CalcFields or FlowField evaluation;Index changes should follow measured query evidence. An extra key increases write and maintenance cost, so "add an index" is not a default cure for posting.
A synchronous HTTP request inside posting makes the user's transaction depend on another service's availability and response time. Where business rules allow, persist an outbound work item and process it asynchronously with a job queue. Give that process durable retry, idempotency, failure visibility, and reconciliation.
Do not move a required authorization or compliance decision out of the transaction merely for speed. The architecture must preserve the business invariant.
Change one verified bottleneck at a time. Repeat the same workload, compare median and slow-case durations, and watch lock behavior as well as total time. A faster average that creates rare deadlocks is not an improvement.
Add automated tests around the business result and, where practical, a performance scenario that detects meaningful regression. Microsoft's Business Central Performance Toolkit is designed for repeatable workload testing; use a controlled environment rather than production.
Bitta Apps can perform a focused Business Central performance investigation, remediate measured issues through AL development, and redesign fragile synchronous dependencies through integration services.