Why your subscriber codeunit might be slowing down Business Central – and how to fix it.

The Problem
You’ve optimized your code, trimmed every loop, and tuned your queries but performance still drags. Why? Hidden event subscribers might be firing behind the scenes on every database operation, quietly stacking up execution time and slowing everything down.
The Fix
🔧Keep subscribers leaned and focused – The leaner the codeunit, the faster the execution. That’s why it’s best to keep subscribers focused and lightweight. Split them by functionality and avoid embedding business logic directly.
🔧Use the single instance pattern – With single instance, one subscriber codeunit is shared across all events
🔧Selective subscribing – based on some implementation conditions, only subscribe when it is necessary, with the help of manual binding.

Avoid using OnInsert, OnModify, and OnDelete subscribers when possible.
* An OnInsert subscriber interrupts bulk inserts by triggering logic for every single record, turning a fast batch into a slow loop.
* An OnModify subscriber slows down ModifyAll by forcing individual operations per record. One SQL call becomes many.
* An OnDelete subscriber does the same to DeleteAll, converting a single delete into a record-by-record process.
In short, these subscribers can quietly sabotage performance by turning efficient SQL batches into expensive loops.
Event subscribers are powerful but they come at a cost. Every time one hooks into a database operation, it adds latency. In production, that cost adds up fast. Design your subscribers like every millisecond matters, because it does. Even the cleanest, most optimized code can crawl if hidden subscribers are firing in the background.