In certain scenarios when code must be triggered once after a set of table records is updated, but it does not have to run on each record. Account Schedule KPI in Financial Reports is a good example of this kind of set update.

https://github.com/microsoft/BusinessCentralApps/blob/main/App/Layers/W1/BaseApp/Finance/FinancialReports/AccSchedKPIEventHandler.Codeunit.al

Here, the web service setup is updated when a G/L Budget is changed. To track budget changes, the event handler codeunit subscribes to database insert / update / delete events, which forces ModifyAll and DeleteAll to trigger separate Update / Delete statements on each record, and Insert operation will not collect the bulk insert buffer. This can greatly undermine performance of massive updates - especially ModifyAll and DeleteAll operations.

These updates could be triggered once after DeleteAll or ModifyAll is executed and avoid binding subscribers to OnAfterDeleteEvent and OnAfterModifyEvent - if Business Central platform published such events.

I suggest to introduce two database events: OnAfterDeleteSet and OnAfterModifySet.

OnAfterDeleteSet event should be called after Delete or DeleteAll statement is executed.

Respectively, OnAfterModifySet should be invoked after Modify or ModifyAll.

Events can have the following signature:

OnAfterDeleteSet(RecRef: RecordRef)

OnAfterModifySet(RecRef: RecordRef)

The primary key of the RecRef is initialized only if the event is triggered by an operation on a single record (Delete or Modify). When the event is invoked from bulk operations, the primary key remains uninitialized, but filters from the source record are transferred to the RecRef, so the client subscribing to the even can retrieve the range of affected records.