The agency or client should remain the authority for source rights, credentials, production connection, acceptance, commercial terms, and client-facing commitments. The delivery partner should receive a bounded technical brief and a safe way to prove the work.
01 / WORKFLOW BOUNDARY
Name one workflow and one acceptance owner.
“Improve our automation” is not a transferable brief. Start with one business event, one expected result, named source and destination systems, and one person who can decide whether the evidence is sufficient.
| Brief element | Useful handoff | Unsafe ambiguity |
|---|---|---|
| Trigger | Named event, source, expected frequency, and identity key. | “Whenever new data arrives.” |
| Result | Observable final state and fields that may change. | “Sync everything.” |
| Exceptions | Known invalid, duplicate, stale, unauthorized, and unavailable paths. | Only a happy-path example. |
| Acceptance | Named fixtures, expected outcomes, and accountable reviewer. | The builder decides when it is done. |
- Describe the workflow purpose in one sentence.
- Mark what is explicitly outside the first slice.
- Name the system of record for every important field.
- Separate technical completion from business acceptance.
- Record who can approve a scope change before it is built.
02 / SAFE EVIDENCE
Share a sanitized export and representative executions.
A workflow export shows structure, not the whole operating contract. Pair it with sanitized fixtures, expected results, selected execution evidence, and notes about environment-specific behavior. Remove secrets and unnecessary client data before transfer.
- Export or version the exact candidate workflow without embedded secrets.
- Replace customer records with synthetic or irreversibly sanitized fixtures.
- Include success, duplicate, invalid-input, dependency-failure, and recovery examples.
- List omitted environment facts instead of inventing placeholders that look real.
- Confirm the agency or client has authority to share every artifact.
A useful starter packet can contain a redacted workflow export, a field map, five synthetic fixtures, expected outcomes, and a short environment inventory. Production access can remain withheld.
03 / WRITES AND CREDENTIALS
Inventory every external write before granting access.
The highest-risk nodes are not always visually prominent. Record every action that creates, updates, sends, deletes, approves, charges, publishes, or changes access. The system owner should decide which actions can run in a sandbox and which stay disabled until release.
| Question | Record before build |
|---|---|
| What can change? | Destination, operation, affected object, and allowed fields. |
| Who owns access? | Credential owner, least-privilege role, environment, rotation, and revocation path. |
| What can be simulated? | Test endpoint, mock service, dry-run route, or write-disabled fixture path. |
| What needs approval? | Production connection, irreversible action, high-impact communication, and exception override. |
- Use managed credentials or an approved secret store.
- Keep credential values out of exports, notes, screenshots, logs, and chat.
- Use separate test and production connections with visibly different names.
- Grant only the systems and operations required for the first slice.
- Test what happens when a credential expires or is revoked.
04 / FAILURE BEHAVIOR
Agree on retry, replay, and duplicate behavior.
A handoff is incomplete if the next operator cannot tell whether a failed run is safe to retry. Define one stable business-event identity, bounded retry rules, explicit terminal states, and reconciliation for remote writes whose outcome is uncertain.
- Use an idempotency key based on the business event, not the execution attempt.
- Classify retryable, terminal, review-required, and ambiguous failures.
- Limit retry count and delay; never hide an exhausted retry loop.
- Reconcile an uncertain remote write before sending it again.
- Give manual replay the same duplicate and authorization controls as automatic retry.
- State who receives an alert and what safe action they can take.
If the recovery instruction is “rerun it and see,” the workflow is not ready to transfer.
05 / RELEASE GATE
Keep production connection behind a human decision.
Build and review in a sandbox or controlled test path first. The accountable owner should approve the frozen candidate, evidence, remaining risks, credential mapping, release window, rollback trigger, and first live verification before production is connected.
- 01Freeze the candidate
Record the exact workflow version and configuration inventory without secrets.
- 02Run the acceptance set
Capture expected and actual outcomes for success, duplicates, failures, and recovery.
- 03Review authority
Confirm source rights, credential ownership, write scope, data handling, and alert ownership.
- 04Make the release decision
The agency or client accepts the evidence and authorizes the production connection.
- 05Verify and retain control
Check the first approved live outcome, then keep disable, rollback, and access-revocation paths available.
Do not connect production when the accountable owner, allowed writes, acceptance evidence, credential ownership, failure states, alert path, or rollback trigger is undefined.
06 / HANDOFF PACKAGE
Leave evidence another operator can use.
The final package should let a different authorized person understand what the workflow does, configure it safely, recognize failure, replay only when safe, and disable it without reconstructing the project from chat history.
- Versioned n8n export or repository reference.
- Configuration and dependency inventory without secret values.
- Field map, synthetic fixtures, expected results, and captured acceptance evidence.
- Known limitations, unsupported cases, and remaining risks.
- Runbook for normal operation, alerts, replay, reconciliation, credential rotation, and recovery.
- Production owner, operator, reviewer, incident contact, and support boundary.
- Rollback or disable steps plus the trigger for using them.
A good handoff transfers operating knowledge while preserving access control and accountability. It does not make a delivery partner the default owner of every future incident.
SELF-DIRECTED REFERENCES
Inspect the boundary before the brief.
The n8n Reliability Lab, sample review, and test harness use synthetic data, zero credentials, and zero external actions. Each is not client work. These references do not prove third-party integration delivery or production readiness.