Campaign send retries: distinguish rejected, accepted and uncertain outcomes

Define the decision

A network interruption can happen before or after a provider accepts a message. If the application loses the connection before recording the result, 'an error occurred' does not answer whether mail left. The operator's job is to reconcile the event, not to force a retry until a success banner appears.

Work through the procedure

1. Capture the error and identify the stage of the attempt where possible. Preserve the campaign, enrollment, step and provider identifiers.
2. For a confirmed rejection, repair the specific cause and review whether the recipient remains eligible before allowing another attempt.
3. For confirmed acceptance, advance or reconcile the existing history through supported operations rather than sending a replacement copy.
4. For an unknown result, obtain provider evidence and keep the affected work under review. Do not substitute a new contact or campaign to escape the uncertain state.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Retry decision record
Known rejection before acceptance → diagnose, then review retry
Confirmed acceptance → preserve the accepted event
Connection lost; acceptance unknown → reconcile first
A generic timeout message alone cannot choose between the last two cases

Read the result

The distinction protects both the recipient and the accuracy of the campaign history. A successful retry can still be a bad outcome if the first attempt also succeeded. Conversely, never retrying a confirmed pre-acceptance rejection after repair can leave legitimate work unfinished. Evidence determines the next step.

Check before moving on

1. Do not infer acceptance solely from the absence of a bounce.
2. Review replies and suppression again after any extended investigation.
3. Record who resolved the uncertain state and what evidence supported the decision.

Limits and next action

This is not a promise of exactly-once delivery across all networks. Zintara's attempt tracking distinguishes accepted and uncertain work, but an operator may still need provider logs to reconcile ambiguity. Avoid manual database changes or duplicate queue submissions as a general recovery technique.

Source: Zintara sequence product context