Notifications — Business Rules & Policy Logic

Summary: How recipients, timing, and send conditions are decided for each kind of notification — written for reviewing or auditing the policy logic itself.

Main content

The kinds of notifications, and how each one is triggered

There are two fundamentally different triggering styles:

• Event-driven — fires the moment something happens: an order is created or changes, an e-invoice is issued, a customer registers or changes tier, a promotion changes approval status. These have no schedule; they fire in the moment.
• Scheduled/recurring — runs on a repeating cadence (daily, weekly, or monthly, at a set time) and, each time it runs, checks which accounts/documents currently match its conditions. Payment reminders, ageing reminders, live and monthly statements, and the promotion-approval reminder digest all work this way.

A third pattern exists alongside these: some notification kinds are one-off by design — a person picks the audience and content and sends it (or schedules a single future send) rather than it recurring or reacting to an event. Marketing-style messages and product/category announcements work this way.

Deciding who receives a notification

Every notification type — order updates, e-invoices, payment reminders, ageing, statements, and one-off messages alike — resolves recipients the same way, through one shared set of rules, so the policy is consistent across all of them:

1. Role — an optional include-only filter. If one or more roles are selected, only contacts holding one of those roles qualify; if none are selected, role doesn't narrow anything.
2. Contact scope — whether the primary contact should receive it, whether other (non-primary) contacts should, or both.
3. Email address scope (email channel only) — whether to send to a contact's first email address, second email address, or both. This is separate from contact scope: contact scope decides which people, address scope decides which of their addresses.

A contact must pass role, then contact scope, to be included at all; email address scope only then decides which address(es) of a qualifying contact actually get written to.

A policy pitfall worth knowing about: role filtering used to be tangled up with a separate "only these / except these" customer-exclusion setting. That coupling was deliberately removed so role filtering now always means "only contacts with this role," regardless of how the customer-exclusion setting is set. Any notification template that was configured before that change, with the exclusion setting on "except these" and specific roles selected, changed meaning as a result — those roles now mean "only these roles" instead of "every role except these." No historical templates were automatically corrected, on the basis that none existed in production at the time — but this is worth a one-time audit if older templates are ever found.

Conditions — only four notification kinds have them

Only payment reminders, ageing reminders, and the two statement types (live and monthly) carry configurable send conditions:

• Due-date type and number of days — how "due" is measured (e.g. relative to the due date) and the day-offset threshold that has to be crossed before it's eligible.
• Minimum outstanding amount — a floor below which the account/document won't trigger a reminder at all.

No other notification kind has this condition layer — an order-update or e-invoice notification fires purely on its triggering event, with no threshold logic layered on top.

WhatsApp needs a separate approval step

Several notification kinds (payment reminder, ageing, both statement types, and one-off messages) can be sent over WhatsApp, but WhatsApp requires the exact message template to be pre-approved by Meta before it can be used. Saving a new or edited WhatsApp template puts it into a pending state; it only becomes usable once approval comes back. Editing an already-approved template's content resets it back to pending — Meta re-approval is required again, every time the content changes.

One-off "Message" notifications work differently from everything else

The "Message" type (WhatsApp or LINE only) is not on any recurring schedule and is never picked up automatically — it only sends when someone explicitly triggers it, either immediately or via a one-time scheduled send set up in advance. This is a deliberate policy difference from every other scheduled/recurring type, so that a marketing-style message never goes out silently on autopilot.

Promotion approval notifications work on a group basis, not the usual recipient rules

Promotion-related notifications don't use the role/contact-scope/email-scope rules above at all — they instead target one of two fixed audiences: approvers or submitters (or both, depending on the event). There are five distinct trigger events: approval required, an approver approved it, an approver rejected it, the promotion's status changed, and someone added a note to it. A separate recurring digest notification also exists, summarizing everything still pending a given approver's sign-off.

Known limitations

• Coupon-earned, points-related, and phone-number-change notifications are defined as policy but currently switched off — don't treat them as active policy in any audit.
• There's no cross-channel dedication rule beyond "one message per matching recipient per run" — if a contact qualifies through more than one recipient path in the same send, business logic dedupes by identity, not by channel, so review this carefully if a future rule set ever allows the same contact to qualify twice through different paths.