Event-driven architecture is one of the most powerful features of Microsoft Dynamics 365 Business Central. Event subscribers allow us to extend standard functionality without modifying base code, making solutions upgrade-safe and suitable for AppSource certification.
However, events come with hidden costs. When used carelessly, they can significantly impact performance, readability, and long-term maintainability.
This article explores the subtler challenges of event subscribers in AL, including their performance implications, identification of high-risk “hot” events, execution order uncertainties, upgrade considerations, and scenarios where events may not be the best approach.
The Hidden Cost of Extensibility
Event subscribers appear seamless: no modifications to standard objects, no merge conflicts during upgrades, and clear separation of concerns. Yet, under the hood, each subscription introduces overhead—additional method calls, context switches, and often implicit database interactions.
These costs remain negligible in isolation but become pronounced at scale, particularly in high-volume processes like document posting, releases, or batch operations.
Hot Events: Silent Performance Killers
Certain events fire with high frequency, often inside loops or during core business processes. These “hot” events include examples such as OnAfterValidateEvent on document lines, OnAfterModifyEvent on busy tables, or posting-related events (e.g., in Sales-Post or Gen. Jnl.-Post Line).
When multiple extensions subscribe—say, three extensions with two subscribers each—an event firing 10,000 times generates 60,000 extra method calls. Even lightweight logic amplifies quickly into significant overhead.
A key guideline: Treat any event triggered within a loop in standard code as performance-critical. Additionally, subscribers on table events like OnInsert, OnModify, or OnDelete can disrupt SQL bulk optimizations (e.g., turning ModifyAll or DeleteAll into row-by-row operations).
Example of a performance pitfall (avoid subscribers on OnAfterDeleteEvent):
Subscribing to OnAfterDeleteEvent forces DeleteAll operations to execute row-by-row instead of in bulk, severely impacting performance on large datasets.
Unintended Database Access
Subscribers often inadvertently trigger database work, such as GET/FIND operations, MODIFY calls that invoke validations, or implicit FlowField evaluations. Detached from the original context, these issues are difficult to trace, manifesting as unexplained SQL load.
Bad example (unintentional DB access in a hot event):
codeunit 50100 "Bad Subscriber Example"
{
[EventSubscriber(ObjectType::Table, Database::"Sales Line", 'OnAfterValidateEvent', 'Quantity', false, false)]
local procedure OnAfterQuantityValidate(var Rec: Record "Sales Line"; var xRec: Record "Sales Line")
var
Item: Record Item;
begin
if Item.Get(Rec."No.") then
Rec.Description := Item.Description; // GET call – expensive if called thousands of times
Rec.Modify(true); // Triggers additional validations and potential writes
end;
}This subscriber performs a database lookup and modify on every quantity validation, which can happen frequently in document lines.
Better approach: Avoid DB access; if needed, ensure it’s conditional and minimal. Cache data where possible or move logic elsewhere.
Best practice: Design subscribers assuming they may execute thousands of times—minimize or avoid database interactions where possible.
Execution Order: No Guarantees
A common assumption is that subscribers form a predictable pipeline. In reality, when multiple extensions subscribe to the same event, their execution order is undetermined (though internally influenced by factors like app IDs). Microsoft may also add its own subscribers in future updates.
Relying on another subscriber to preprocess data leads to fragile, undefined behavior.
Example of fragile code (assuming order):
[EventSubscriber(ObjectType::Codeunit, Codeunit::"Sales-Post", 'OnAfterPostSalesLine', '', false, false)]
local procedure AssumeOtherExtensionRanFirst(var SalesLine: Record "Sales Line")
begin
// Assumes another extension already set a custom field – undefined behavior!
if SalesLine."Custom Field" = '' then
Error('Field should have been populated!');
end;Effective subscribers must be idempotent, independent, and defensive in their data handling.
If sequential logic is required, events are likely the wrong tool.
Upgrade Safety: Not Always Absolute
Events promote technical upgrade compatibility—your code compiles across versions. However, functional safety is another matter: event signatures can change, events may be removed or cease firing, logic may shift elsewhere, or new standard subscribers can alter outcomes.
These changes can cause silent failures or subtle behavioral shifts, which are among the most challenging bugs to diagnose.
Logic Scattering and Maintainability Issues
Over-reliance on events fragments business logic across numerous subscribers, complicating execution flow and debugging. What could be a straightforward process becomes a web of potential interceptions from various extensions.
When Events Are the Wrong Choice
Events fall short in scenarios requiring strict execution order, high performance, transactional predictability, or explicit testability.
Stronger alternatives include:
- Interfaces for controlled extensibility
- Dedicated integration codeunits
- Custom reports or processes rather than intercepting standard ones
- Configuration-driven behavior over runtime hooks
Events excel at optional, additive extensions—not as architectural replacements.
Practical Guidelines
Reserve events for lightweight, optional additions where order is irrelevant.
Avoid them for core process logic, performance-sensitive areas, or deterministic behavior.
Always prioritize small subscribers, minimize database writes, and document the rationale for each subscription. Consider single-instance codeunits for subscribers to reduce instantiation overhead.
Good practice example (single-instance subscriber codeunit):
codeunit 50101 "Performance-Friendly Subscribers"
{
Subtype = Normal;
SingleInstance = true; // Reduces memory overhead on frequent calls
[EventSubscriber(ObjectType::Codeunit, Codeunit::"Release Sales Document", 'OnAfterReleaseSalesDoc', '', false, false)]
local procedure LightweightLogic(var SalesHeader: Record "Sales Header")
begin
// Pure computation, no DB access
SalesHeader."Custom Timestamp" := CurrentDateTime;
end;
}Conclusion
Event subscribers remain a cornerstone of AL development, enabling clean and extensible solutions. Yet mastery lies in restraint: recognizing when not to use them distinguishes advanced developers.
Used judiciously, events enhance upgrade-safe extensions. Used indiscriminately, they invite performance degradation, unpredictability, and maintenance challenges.
In Business Central development, the ability to subscribe does not imply the obligation to do so.
As always – we have geat tool in our heands and it’s our responsibility to use it wise.