Recently, I had the opportunity to help a customer investigate performance issues within their Business Central environment. Users had started reporting slower page loads, longer processing times, and declining system responsiveness. The challenge was that there was no obvious root cause. The infrastructure appeared healthy, the database was operating normally, and no critical errors were being reported.
To accelerate the investigation, I analyzed the customer’s extension repository using BC AL Code Reviewer, a solution I developed to assess AL code for performance, maintainability, and architectural concerns.
The objective was not simply to find bugs. The goal was to determine whether the codebase contained patterns that could be contributing to the performance issues experienced in production.
What made the review particularly interesting was that the findings were not unusual. In fact, they were the same types of issues I have encountered in many Business Central projects over the years.
There were no major architectural failures or catastrophic design mistakes. Instead, the repository contained several small development patterns that seemed harmless individually but, when executed repeatedly across large datasets and daily business processes, could significantly impact performance.
This reinforced an important lesson:
Most Business Central performance issues are not caused by a single bad piece of code. They are usually the result of small inefficiencies that accumulate over time.
Here are some of the most common findings uncovered during the review.
Excessive Database Calls Inside Loops
One of the most frequent performance issues involves database operations being executed inside loops. A lookup that appears harmless during development can become extremely expensive when executed thousands of times in a production environment.
In this review, several areas of the code performed repeated database operations while processing records. While the logic was correct, the number of database calls increased dramatically as transaction volumes grew. These types of patterns often remain unnoticed until users begin experiencing slower performance.
Missing SetLoadFields
Another common finding involved loading more data than was actually required. Business Central provides SetLoadFields to optimize data retrieval and reduce unnecessary data transfers from SQL Server.
However, it is common to see records being loaded with dozens of fields when only a handful are actually used. The code functions correctly, but additional data retrieval creates overhead that accumulates over time.
For organizations processing large transaction volumes, these small inefficiencies can have a measurable impact.
Unnecessary FlowField Calculations
Flow Fields are incredibly powerful, but they can become expensive when used without careful consideration. During the review, several opportunities were identified where Flow Fields were being calculated more frequently than necessary.
Each calculation generates additional database activity. When executed inside loops or batch processes, the performance impact can become significant. The functionality remains correct, but the efficiency of the process suffers.
Inefficient Record Retrieval Patterns
Another area that frequently appears in code reviews is record retrieval. Choosing the wrong retrieval method can increase database activity and slow processing.
Developers often focus on ensuring the code works correctly, which is absolutely the right priority. However, understanding how Business Central retrieves data behind the scenes can dramatically improve performance. Small optimizations in record retrieval frequently deliver larger gains than expected.
Event Subscribers Doing Too Much Work
Event-driven development is one of the greatest strengths of Business Central. However, event subscribers can also become hidden performance bottlenecks.
As solutions grow, it becomes common for multiple subscribers to execute during a single business process. Each subscriber may perform validations, calculations, or additional database operations.
Individually, the impact may be small. Collectively, these hidden operations can contribute to slower system performance and make troubleshooting more difficult.
The Most Interesting Discovery
The most interesting outcome of the review was not the individual findings themselves. It was the realization that none of these issues were causing obvious failures.
The system was functioning, Transactions were posting, Business processes were completing successfully.
Yet small inefficiencies scattered throughout the codebase were collectively contributing to the performance concerns being experienced by users. This is often what makes performance investigations challenging.
The problem is rarely a single piece of code. It is usually the cumulative effect of many small decisions made over time.
Why I Built BC AL Code Reviewer
Experiences like this are exactly why I built BC AL Code Reviewer. After reviewing numerous Business Central repositories throughout my consulting work, I noticed that the same patterns appeared repeatedly across different projects.
Performance optimization opportunities.
Maintainability concerns.
Documentation gaps.
Upgrade readiness issues.
Technical debt indicators.
The challenge is that manually reviewing every object, extension, and repository requires significant time and expertise.
BC AL Code Reviewer was designed to help accelerate that process by providing automated analysis and highlighting areas that deserve attention before they become larger problems.
The goal is not to replace developers or architects. The goal is to help development teams identify issues earlier, maintain consistent standards, and improve overall solution quality.
Conclusion
One of the biggest lessons from this review was that performance problems rarely originate from a single catastrophic mistake or a major architectural failure. In most cases, the system is doing exactly what it was designed to do.
The challenge lies in the accumulation of small inefficiencies that gradually become more noticeable as transaction volumes increase and business processes become more demanding.
A database call inside a loop.
An unnecessary FlowField calculation.
An inefficient record retrieval method.
An event subscriber performing additional processing behind the scenes.
Individually, these decisions may seem insignificant and often go unnoticed during development and testing. The functionality works, users can complete their tasks, and there are no immediate signs of trouble. However, when these patterns are repeated throughout a solution and executed thousands of times every day, their collective impact can become substantial. What begins as a minor inefficiency can eventually affect scalability, system performance, and the overall user experience.
This is why code reviews remain one of the most valuable activities in any Business Central development project. They provide an opportunity to identify potential performance concerns before they become operational problems, helping development teams build solutions that are not only functional but also scalable and maintainable because when it comes to performance optimization, the most effective solution is often preventing the problem from reaching production in the first place.
Leave a Reply