A Business Event can point at a transaction screen directly, but a purpose-built Generic Inquiry as the source is almost always the better foundation — it's the one place in this whole feature where a little extra setup up front avoids most of the maintenance pain later.
Why a screen alone is usually not enough
A transaction screen's underlying data view exposes the fields that screen's UI needs, not the fields a trigger condition or a notification template might want. Getting at a joined field — the customer's account manager, a related contact's email, a field from a linked document — often means the screen simply doesn't expose it, and there's no way to reach further from inside the Business Events condition builder. A Generic Inquiry has no such restriction: it's built specifically to join whatever tables the integration needs.
Building the GI with the business event in mind
Two things matter more here than in a GI built purely for reporting. First, keep the result set narrow — a condition or trigger evaluated against every row of a wide, unfiltered GI on every relevant save is unnecessary load; scope the GI's own filter to the entities the business event actually cares about. Second, name every result column something a notification template's placeholder list will make sense of six months later — a GI built for reporting often has columns named for convenience, not clarity, and those same names are what show up in the template editor's field picker.
If more than one trigger condition needs the same joined fields (order confirmed, order shipped, order cancelled, all needing customer contact and account manager details), build one GI and attach multiple business events to it with different conditions, rather than duplicating a near-identical GI per condition.
Trigger conditions against a GI vs. a screen
Against a screen, "row updated" and "field changed" are evaluated directly against the DAC backing that screen. Against a GI, the same condition types apply, but they're evaluated against the GI's result set — which means a field that only exists because of a join (not on the base entity itself) is available to the condition in exactly the same way a native field would be. This is the main reason a GI-based business event can react to something a screen-based one structurally cannot.
Performance considerations worth knowing up front
A GI-based business event re-evaluates the GI's query context around the triggering record on every relevant save, which is fine for most conditions but can get expensive if the GI itself is heavy — several joins deep, or filtering across a large table without a supporting index. If the GI is also used elsewhere for reporting and is already known to be slow, don't reuse it as a business event source without first checking whether that same slowness will now run on every matching save instead of only when someone opens the report.
Scheduling a GI-based event instead of triggering it
Business Events can also run a GI on a schedule rather than react to a specific save — useful for conditions that are cheaper to check periodically than to evaluate on every write, like "flag orders that have sat in a status for more than 48 hours." This trades real-time reaction for a much simpler condition and a predictable, controllable load on the instance.
Wrapping up
A Generic Inquiry built specifically for a business event — narrow, clearly named, appropriately indexed — is what keeps the condition builder and the notification template both able to reach the fields the integration actually needs, without inheriting the constraints of whichever transaction screen happens to be nearby.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.