Acumatica Business Events Patterns — A Field Guide

After enough of these, the same handful of shapes keep coming back regardless of what the actual trigger is. This is a field guide to the patterns, not a tutorial on any one of them — the deep dive, webhooks, retry, and monitoring articles cover the mechanics in more depth.

Internal notification: the default case

Someone needs to know a status changed. Trigger condition on the field, email subscriber with a Notification Template, done in an afternoon with no code. This is the case Business Events were built for first, and it's still the majority of legitimate uses — resist the urge to write a custom subscriber when a Notification Template genuinely covers it.

Internal handoff: import scenario

One record's data needs to create or update a different entity inside the same Acumatica instance — a confirmed Sales Order that should generate a related Case, say. The Import Scenario subscriber handles this without custom code, mapping fields from the source to the target entity's import definition. It's worth knowing this exists before reaching for a custom subscriber to do what an import scenario already does natively.

External push: the queue-and-processor pair

Anything leaving the instance — a webhook, a cloud function call, an SMS — follows the same shape covered across the webhooks, Azure, and Lambda articles: subscriber writes to a queue table, a separate processor delivers with retry. Every external-push business event that skips the queue and calls out directly from the subscriber eventually causes a slow save somewhere, once the target has a bad day.

Polling instead of triggering

Not everything needs an event. If a downstream system only needs an hourly summary, or the source data changes too unpredictably for a clean trigger condition, a scheduled Generic Inquiry read by an external poller is simpler and more robust than forcing a real-time event onto something that doesn't need to be real-time. Business Events add complexity that pays off when timeliness matters; when it doesn't, a scheduled pull is fewer moving parts.

GI as source, not just as report

Building a Generic Inquiry purely to serve as a Business Event's trigger source (rather than pointing directly at a transaction screen) is worth the extra setup almost every time — it's covered on its own in the GI and Business Events article, but the short version is: a GI gives you exactly the joined fields the condition and the notification template need, instead of whatever happens to be on the underlying screen's primary data view.

The anti-pattern: doing everything in the subscriber

The recurring mistake across all of the above is collapsing "detect," "decide," "transform," and "deliver" into one subscriber method. Split them: the trigger condition decides what matters, the subscriber decides what to record, and everything about transforming and delivering the data lives downstream, in code that isn't running inline with someone's save.

Wrapping up

Almost every Business Events integration is one of: a notification, an internal handoff, or an external push behind a queue. Recognizing which one you're building before writing the subscriber saves the rework of discovering, mid-implementation, that you built a slow subscriber where a fast one belonged.