Skip to main content
Every Transactional asks one question besides the event and the messages: how many notifications per customer? There are two answers.

​
One per event (the default)

Every time the event arrives, the customer gets the notification. Use it for notifications where each event is its own thing, like a password reset or a shipping update.
  • Each event sends once.
  • A customer gets one at a time: if two events for the same customer arrive at the same moment, only the first one sends.
  • A retry of the same event sends again, even with the same externalId. If your system retries, or must never send the same thing twice, use one per field value.

​
One per field value

Each different value of a field you pick gets its own notification, and a value that comes again is skipped. Use it when a customer can have several of something at once, like orders or appointments, and must never get the same one twice. Pick the field that is different on every event, usually an id: orderId, appointmentId, invoiceId.
  • Each distinct value sends once, ever, per customer.
  • The same value arriving again for that customer sends nothing, so a retry never sends twice.
  • Two different values for the same customer send two notifications, even at the same moment.

​
An example

Your system records an order_shipped event each time an order ships, and the Transactional sends one per orderId. With one per event, the second order would be skipped (it arrived at the same moment as the first), and the retry would send again.

​
Choosing the field

  • Use an id that your system creates once per thing, the same one you would use to look it up later.
  • Do not use a field shared by many events, like the customer id, a status or an amount. A customer id would send only the first notification the customer ever gets, and never again.
  • Do not use a field that changes on a retry, like a timestamp or a request id. Every retry would send again.
When the event has exactly one field ending in Id, choosing One per field value starts from it. If your event has not arrived yet, type the field’s name; it only has to match what your system will send.

​
Sending the field

Put the field in the event’s properties:
An event that arrives without the field, or with an empty one, sends nothing, because Boom cannot tell which order it belongs to. So does a value longer than 255 characters. See Send transactional messages for the full set-up, and events for the event API.