Lifecycle message rules and exclusions

Use a programme-level decision framework for lifecycle message rules and exclusions: test entry and permission, apply exclusions and current-state checks, then rank the remaining eligible messages. A message should send only when its trigger is valid, the recipient is eligible, the content still helps with a current task and no exclusion makes it inappropriate; recheck changing conditions near each delayed send.

Give each rule one job

A person can meet an entry trigger but fail a permission or send check. A frequency cap limits volume but cannot establish that the message which gets through is the right one. Record why a step was skipped, held or ended so the team can distinguish a deliberate exclusion from a data fault.

Define the unit and evidence

Decide whether each rule applies to a person, an account or a particular task. One member finishing personal setup may end their reminders without ending another member’s. An account-level purchase may make a first-purchase offer obsolete for linked contacts. Use a verified account relationship rather than a matching name or email domain.

For each trigger or exclusion, name its source, identifier, occurrence time, required status and owner. Keep the time an event happened distinct from the time the messaging system processed it. A late completion can make a queued reminder stale; a duplicate can cause another entry if repeat entry is allowed. Where evidence is incomplete, mark the state unknown rather than asserting success or failure.

A reviewable decision record can identify the journey, task, recipient, proposed message, evidence, decision time, outcome and reason. The fields can come from existing systems; they need not be a new platform feature.

Apply exclusions in a clear order

Set a declared precedence order: check permission, then current-state accuracy, then fault or human-conversation exclusions, and finally priority among remaining eligible messages. Use ranked business categories rather than send order to resolve competition; frequency caps alone send what is due first. Detailed arbitration between overlapping triggers belongs in the supporting journey design.

For Australian commercial electronic messages, the Spam Act 2003 (Cth) regulates the send, and the Australian Communications and Media Authority (ACMA) monitors compliance. The Act recognises express and inferred consent, so check the basis for consent and current opt-out status before sending.

Assess the whole message: promotional content in a practical account notice can make it commercial. Keep necessary service communication on an appropriate route when marketing is withheld.

State what an exclusion does. Skip discards one step; hold waits for a record or owner; replace uses a different response after its own checks; exit closes the current journey. A held message needs an expiry and a fresh check before release.

Australian Compliance Requirements for Commercial Electronic Messages

Separate entry from send eligibility

In Customer.io, a person who has unsubscribed from a topic or from all messages can still trigger an automation, but will not receive its messages. Treat automation entry and permission to send as separate states in programme reporting; an entry count alone does not show that a message was eligible or sent.

The Spam Act 2003 (Cth) recognises express and inferred consent. Express consent may be given by signing up for a newsletter, ticking a website box or agreeing verbally. Inferred consent may arise from conduct and an existing relationship; for example, a customer purchase, no opt-out and related product updates. Check current opt-out status before relying on that relationship.

Set launch and condition criteria

For Customer.io automations triggered by a segment, profile attribute, object or relationship, choose whether launch applies to “Current + Future additions” or “Future only”. Include that audience choice in the programme rule: otherwise, the same trigger criteria may apply to a different population than intended.

A Customer.io condition can use a person’s attributes, event data, message data, segment membership or journey attributes. Specify which evidence is relevant to each message decision, rather than assuming that a trigger’s conditions also govern every later action. A failed action condition skips that action and the person continues through the automation.

Some condition wording carries a broader time meaning than a journey step. In Customer.io, “Event has been performed” checks whether the person has ever performed the event, including before entering the automation. Make that lifetime scope explicit when deciding whether the event is suitable evidence for the message rule.

A Customer.io automation must be live to accept entrants; its title shows “Running” when live, while a “Starting” state may prevent triggering. Include operational readiness in the release criteria, so an otherwise valid audience and trigger are not mistaken for a functioning programme rule.

Check the sending paths

Inspect configured triggers, filters, action conditions, exits and repeat-entry settings, including other queues that can reach the same recipient. For attribute- or segment-triggered Customer.io automations, frequency settings include one-time entry, every re-match and fixed intervals. Those controls do not settle messages scheduled in another system.

Braze’s Message Prioritization can evaluate scheduled campaigns, action-based campaigns, Canvases and API-triggered campaigns. It ranks messages that opt in, have a category and count towards the same applicable frequency cap. A priority label therefore cannot replace a review of all sending paths.

Before release, compare the written rules with histories covering immediate completion, simultaneous triggers, a late event, a duplicate, an opt-out during a delay and an unresolved service issue. Inspect actual configuration and, later, wrong sends and useful messages withheld.

Recheck the relevant evidence close to each send, especially after a delay. A completion or account change can make queued content inaccurate, while a current opt-out or unresolved service issue can change eligibility.

Pre-Release Validation Checklist for Lifecycle Automations