Make Destination Writes Safe

What you will complete

Complete the destination contract, idempotency rule, state model, retry and reconciliation plan, payment boundary, and audit events.

Define the destination object precisely

Name the system, object, allowed state, required fields, attachment behavior, permissions, and success receipt. “Send to accounting” is too vague. The course example permits one draft bill after explicit approval. It does not permit final posting, payment, refund, remittance, supplier creation, or bank-detail change.

Write the allowed state transitions: not attempted, awaiting approval, queued, attempt recorded, confirmed, ambiguous, failed, and reconciled. Do not mark the source item complete until the destination ID or equivalent receipt has been stored against it.

Use least privilege. The integration should possess only the access needed for its allowed object and state. A workflow boundary is stronger when forbidden actions are unavailable at the credential and API level, not merely discouraged in prose.

Design idempotency and recovery together

An idempotency key represents one intended business write. Reusing it after a lost response should return or reconcile the existing record rather than create another. The exact mechanism depends on the destination: request key, unique constraint, application store, or pre-insert lookup. The automation platform does not supply this guarantee automatically.

When a request times out, the outcome is ambiguous. The destination may have committed the write and lost the response. Check the key or business identity before retrying. Reuse the same key. Record every attempt separately from every stored write.

Retry only errors likely to be transient and cap the attempts. Authentication failure, invalid schema, forbidden action, and business rejection need intervention, not repeated writes. Route exhausted retries to an owner with source, key, attempts, errors, and reconciliation instructions.

Worked example: one draft after two attempts

Fictional example: Cedar & Quay approves fictional invoice INV-TP-2405 for CAD 164.98. The fake destination writes draft draft-1, then its response is lost. The workflow retries with the same idempotency key. The destination returns the existing draft. The result is two attempts, one stored write, and one draft ID.

That behavior is proven only in Flowgrammer’s offline labelled-text control harness. It does not prove a live accounting API, n8n execution, cloud deployment, or production retry behavior. A real implementation must demonstrate the destination contract in a sandbox.

If the review decision is empty, expired, stale, or unauthorized, destination attempts remain zero. If input contains a payment action, the example invoice workflow’s payment wall blocks the path.

Complete Workbook Section 5

1. Name the exact non-final destination object and allowed state.
2. List credentials, permissions, forbidden endpoints, and human prerequisites.
3. Define one stable idempotency key and destination lookup.
4. Map timeout, retryable, non-retryable, partial, and exhausted-retry paths.
5. List audit events, success receipt, reconciliation owner, and completion rule.

Use Section 5 of the workbook.

Critical safety gates

• No decision or invalid decision means zero destination attempts.
• A duplicate means zero review and zero destination attempts.
• A retry reuses the intended write key.
• An ambiguous response cannot be treated as a definite failure or success without reconciliation.
• Forbidden final actions do not exist in normal, retry, timeout, or error paths.

Module 6 converts these gates into a representative and adversarial test corpus.

Check your application