Make Skip, Resume or Retry: choose an error policy by outcome

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

Choose what happens to the business record

Make documents different outcomes for its handlers: Skip removes a failed bundle and continues other bundles; Resume supplies replacement output and continues that bundle; Retry stores an incomplete execution for later automatic or manual completion. Retry requires incomplete-execution storage. Skip can mark a run successful despite skipped errors, so run status alone is insufficient evidence of completeness.

Our recommended starting point is a written policy per action: may this result be missing, may a substitute be used, or must the operation eventually complete? Those are business choices. The easiest handler to add is not necessarily the one that preserves the intended outcome.

A fictional lead-processing policy

Assume a workflow receives a lead, enriches its company sector, writes the required CRM record and prepares an internal notification. The team decides that sector enrichment is optional, the CRM write is mandatory and invalid submissions must go to a review ledger. These assumptions define this example; they are not a universal recommendation for sales operations.

Use substitute data honestly

In the optional lookup case, a proposed replacement is sector_status unavailable with no invented sector value. Ensure every downstream filter understands the marker. A substitute that looks like verified data can silently route the lead incorrectly even while the scenario completes.

Never replace a missing real recipient with an arbitrary customer address simply to satisfy a required field. Prefer a controlled review path when the action cannot be performed truthfully. This is our data-quality recommendation, not a claim that Make validates the business meaning of substituted fields.

Keep skipped work visible

If you choose to skip a bundle, count and explain the missing business outcome separately. For a sample of 20 synthetic submissions with two deliberately invalid entries, a proposed acceptance result is 18 accepted records and two explicitly logged rejections. A green run with 18 destination records but no explanation for the other two does not satisfy that contract.

That arithmetic is a test expectation only. It is not measured delivery performance. Retain business IDs in the acceptance log and avoid storing full customer payloads in routine alerts.

Configure and validate the policy

1. Document mandatory and optional outcomes for each module.
2. Add the chosen handler to the relevant failing module and inspect its replacement or retry settings.
3. Enable incomplete-execution storage where required by the retry policy.
4. Use an isolated destination to introduce one controlled failure of each class.
5. Compare accepted, substituted, rejected and pending items against the original sample IDs.
6. Rehearse recovery of a mandatory write without duplicating external actions.

Escalate policy conflicts

If a manager wants both zero missing records and unconditional continuation with no backlog, make the tradeoff explicit. Someone must own pending work, rejection review or a genuine fallback business process. Choose the handler only after that ownership is clear. Consult the separate incomplete-execution guide for the recovery mechanics; this page focuses on deciding the policy rather than repeating those steps.