Email is the subscriber type Business Events were clearly designed around first — it needs no code, just a Notification Template and a subscriber pointed at it. It's also the one where "it looks like it worked" and "it actually worked" diverge most often.
Notification templates and placeholders
A Notification Template is built against a specific screen or Generic Inquiry and exposes that source's fields as placeholders you can drop into the subject and body. The template doesn't know anything about the Business Event that will eventually use it — the link is made on the Business Events screen, where you attach the template as a subscriber and Acumatica resolves the placeholders against the record that triggered the event. This means one template can be reused across multiple business events as long as they share a source screen, which is worth designing for if you expect several trigger conditions on the same entity (order confirmed, order shipped, order cancelled) to send visually similar emails.
The recipient is often the hard part
Templates support fixed recipients, recipients pulled from a field on the source record (a Contact or BAccount email field), and recipients pulled from a related entity. The failure mode here isn't technical — it's that the field you picked as "the customer's email" is sometimes blank, sometimes stale, and the Business Event doesn't fail loudly when it can't find a recipient; it just doesn't send. If email delivery for a given trigger condition matters, add a check earlier in the process (a required field, a workflow validation) that prevents the record from reaching the trigger condition without a usable recipient in the first place.
A community thread on this exact confusion is worth knowing about: a business event's execution log can show the notification as having run, with no corresponding entry in the email activity log — usually because the template resolved to no recipient, or the SMTP relay silently rejected the message. Treat the Business Events execution log as "the subscriber ran," and the Email/Notification Activity log as the only real signal for "a message actually queued to SMTP."
Conditions that only look narrow
A trigger condition scoped to "Status = Confirmed" on a Sales Order fires the first time the order reaches that status — and again if the order is un-confirmed and re-confirmed, which happens more often in real operations than most conditions account for. If a template should only ever fire once per record, pair the field-changed condition with a custom flag field (a checkbox like "Confirmation Email Sent") set by a small event handler, and add that flag to the trigger condition so re-triggering the same state doesn't re-send.
HTML templates and what renders where
Notification templates support HTML formatting, but what actually renders depends entirely on the recipient's mail client — the same caveats that apply to any transactional email apply here. Keep templates to simple, table-based layouts rather than modern CSS, test in at least Outlook and Gmail, and don't rely on the template for anything that needs to look pixel-perfect; if branding matters that much, generate the HTML externally (in the custom subscriber covered in the deep dive) and send through a transactional email API instead of the built-in template engine.
Wrapping up
Email subscribers are the fastest way to get a notification working in Acumatica, and the fastest way to end up debugging "why didn't this send" without realizing the business event executed exactly as configured — it just had nowhere to send the message.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.