4.3 Error Handling, Discards, and Operational Governance

4.3 Errors, Discards, and Operational Governance

A missing message is a symptom, not a diagnosis. Journey Optimizer separates technical execution errors from discards and channel eligibility outcomes. Investigate the reason at the activity where processing diverged.

Errors versus discards

An error indicates that an activity or dependency failed, such as an invalid response from a custom endpoint or a channel-processing problem. A discard means Journey Optimizer intentionally did not process an entry or action under a rule, such as a duplicate journey entrance, incompatible identity, or another documented eligibility condition.

A profile may also reach an action but not be deliverable because the address is absent, the person opted out, the address is suppressed, or a frequency rule blocks contact. Use reason-level metrics and logs rather than placing every outcome in a single “failed” bucket.

Custom-action retries

Journey Optimizer applies a fixed retry policy to custom actions: it retries HTTP errors three times, except for 401, 403, and 404, which are not retried. Authors cannot adjust the number of retries.

The exception makes operational sense:

• 401 usually means authentication is missing or invalid.
• 403 means the caller is forbidden.
• 404 means the requested resource is not found.

Repeating the same request is unlikely to correct those conditions. Other HTTP errors can be transient, so the platform performs its fixed retry sequence.

A broad rule such as “all 4xx responses are never retried” is therefore wrong. Design against the documented exceptions.

Idempotency

Retries can cause the destination to receive the same logical operation more than once. External actions should be idempotent where possible. Include a stable request or correlation key and have the destination return the prior result rather than create a duplicate order, case, or credit.

A random new key on every retry defeats idempotency. Choose a key based on the journey execution and business operation, and avoid exposing sensitive information in it.

Triage order

When a profile appears not to have completed an action:

1. Verify it entered the expected journey version.
2. Follow its path through conditions and waits.
3. Check whether it was still in progress or reached an intended terminal path.
4. Inspect journey errors and discard reasons.
5. For a channel, check address/token availability, consent, suppression, and caps.
6. For a custom action, inspect HTTP status, response timing, authentication, and endpoint logs.
7. Correlate timestamps and identifiers across systems.
8. Determine whether a retry occurred and whether the endpoint handled it safely.

Do not resend manually until duplicate risk is understood.

Entry and identity discards

Typical design causes include a profile already active when reentrance rules prevent another instance, a Jump target in which the profile is already active, an event identity that does not match the configured namespace, or a target journey that is unavailable. Correct the relevant entry or target design; increasing channel capacity will not fix these.

Channel non-delivery

An email address can be syntactically present and still be suppressed. A push token can be stale. An SMS number can be invalid for provider configuration. Consent can forbid a marketing action even when the profile belongs to the audience.

Separate:

• journey entrance;
• arrival at the action;
• action processing;
• provider acceptance;
• delivery;
• engagement.

Each stage has different metrics and remedies.

Governance

A production journey needs owners and thresholds. Define expected volume, error rate, discard rate, and endpoint latency. Monitor early runs and major versions. Document who can stop a journey, when stop is justified, and how to communicate a compliance incident.

Use least-privilege access for event configuration, journeys, content, and publication. Apply labels and policies before activation. Redact personal data from logs and exported diagnostic files. Keep test destinations separate from customers.

Safe response to an incident

If content is cosmetically imperfect but compliant, a new version may be enough. If the journey is sending prohibited or harmful communication, stopping the live version may be necessary even though it removes people in progress. Preserve evidence, correct the draft copy or duplicate, repeat validation and testing, and obtain approval before republishing.

Evidence bundle

For a production incident, capture the journey and version, activity name, profile or test identity, timestamps with time zone, journey execution/correlation identifiers, HTTP status where relevant, and the reason shown in reporting. Redact unnecessary personal data. That bundle lets journey, channel, and endpoint owners investigate the same execution without speculative resends.