AL events and integration patterns

Events are the heart of AL extension architecture. They let your code run when Microsoft's code (or another extension's) reaches a defined point, without you modifying anyone else's source. Used well, they keep extensions upgrade-safe; used badly, they create invisible coupling across the codebase.

Two kinds of events. Business events are domain-level publications — "OnAfterPostSalesDocument", "OnAfterInsertCustomer" — declared by Microsoft on its standard objects. Integration events are custom publications declared by an extension when it wants to be extensible itself: an ISV's app might publish OnBeforeCalculateLineDiscount so customers can layer their own discounting rules.

Subscribers. A subscriber is a procedure in a codeunit decorated with [EventSubscriber(...)], naming the publisher object and the event. The compiler binds it at install time. When the publisher raises the event, every subscriber runs, in undefined order, in the same transaction.

OnBefore vs OnAfter. OnBefore events run before the action and can suppress or modify the operation (typically via a var IsHandled parameter). OnAfter events run after the action completes and are the right place for follow-on processing — sending an email, calling an integration, writing to a log.

Manual vs automatic binding. Subscribers can bind automatically (the default) or manually. Manual binding is for cases where the subscriber should run only when explicitly activated — for tests, or for per-tenant feature toggles. Manual subscribers are bound at runtime with BindSubscription.

Conditional subscription. A subscriber attribute can include a property filter so the subscriber only runs when a property on the publisher record matches a value — useful to scope cross-extension behaviour.

Common patterns.

• Add a field to a posted document: subscribe to OnAfterCopy... between unposted and posted records to carry the value across.
• Validate before posting: subscribe to OnBeforePost... and raise Error if business rules don't pass.
• Trigger an integration: subscribe to OnAfterPost... and queue a job to call an external API.

Anti-patterns. Subscribing to dozens of OnBefore events to inject conditional behaviour. Long-running synchronous subscribers (move them to job queue entries). Subscribers that depend on the order other subscribers run in (they shouldn't). And subscribers that mutate the publisher's record after it's been written — almost always wrong.