Include the final workflow, its business rules, credential ownership, sample executions, activation evidence and recovery instructions. A colleague should be able to operate it without reconstructing the conversation that built it. Accept the handover when that colleague can explain the workflow, inspect an outcome, handle an exception and stop further processing safely.
For workflow automation, this means handing over a working process with named responsibilities. The checklist below is a proposed handover method, not a package that n8n Assistant automatically produces.
Use the September announcement as a starting point
The 9 September 2026 announcement describes Assistant building editable n8n workflows, running them, inspecting execution data and iterating on failures. It also says credential access and activation require explicit confirmation, and that the first workflow is not guaranteed to be production-ready. Source: Introducing n8n Assistant
Those statements explain why a successful build still needs a handover. Preserve the final reviewed workflow and the evidence behind its acceptance. A prompt describes intent; it does not reliably describe every setting after debugging and manual changes.
The announcement also described preview status and deployment restrictions. Before deployment, check current account, plan, region and hosting eligibility, recording the check date. Do not treat September availability statements as permanent entitlements.
Explain what the generated workflow actually does
Start with a short process map: trigger, required inputs, decisions, external changes and final destination. Match each step to its node name so the operator can move between the explanation and the canvas.
For a proposed enquiry-routing workflow, describe which form starts processing, how customer matching works, where unrecognised enquiries go and whether any message leaves the business. Name the exact destination account or workspace. “Send to sales” is incomplete if several sales channels exist.
Record required fields, matching rules, schedule and time zone, and the treatment of empty values. Explain where a person makes a decision. Mark any AI classification separately from fixed routing rules so an operator knows which behaviour may need closer inspection.
Using Assistant to build a workflow does not by itself establish that the finished workflow contains a custom AI agent. The distinction in AI agents versus automation helps teams document the actual runtime behaviour.
Transfer credential responsibility without transferring secrets
For each connected service, record the credential reference, account owner, connected organisation, purpose and person responsible for restoring access. Keep passwords, tokens and recovery codes out of the handover document.
Ask the receiving operator to demonstrate the access their role needs. Being able to see the workflow does not establish that they can inspect failed executions or arrange reconnection when a builder leaves.
Identify dependencies on personal accounts explicitly. The business owner must decide whether those arrangements are acceptable or need replacement before activation. Document the agreed change and retest affected connections afterwards.
Separate business ownership from technical support: the process owner decides the routing rule, while the credential owner resolves account access. A failure involving both needs both contacts, not a generic instruction to “ask IT”.
Retain sample executions that explain the rules
Use a small evidence register linking each sample input to the workflow revision, execution reference, expected branch, observed result and reviewer. Include the destination record where the workflow changes another system. Sanitise examples while preserving the fields needed to understand the decision.
The following cases are entirely hypothetical. They describe a proposed enquiry workflow and proposed operating rules, not default n8n behaviour.
| Case | Proposed expected behaviour | Human handling and evidence |
|---|---|---|
| Ordinary enquiry | A recognised customer reference routes the enquiry to its assigned owner. | Check the execution and destination record; confirm the correct owner received it. |
| Missing reference | Processing holds the enquiry for review without guessing a customer. | The operator requests clarification and records how the corrected input will resume. |
| Ambiguous match | Similar customer names prevent automatic assignment. | The operator checks the authoritative customer record and records the selected reference. |
| Duplicate submission | A previously handled submission reference prevents a second assignment. | Compare the earlier outcome; confirm whether this is a repeat or a genuinely new enquiry. |
Duplicate handling needs an explicit rule. A repeated submission reference and a second legitimate enquiry from the same email address are different cases. Document which field identifies a repeat and what happens when that field is missing.
If a custom integration uses OpenAI function calling, the model requests a tool action and application code executes it. Preserve evidence of the resulting action alongside the request. This is conditional integration guidance, not a claim about how every Assistant-built workflow operates. Source: OpenAI function calling
Separate activation evidence from action approval
Keep an activation record containing the approved revision, reviewer, activation time, intended trigger and observed first live outcome. If the workflow remains inactive, say so clearly and name the outstanding condition. A successful manual sample does not demonstrate that the intended live trigger has fired.
For workflows containing AI Agent tools, n8n documents configurable human review: approval permits the specified tool action, while denial cancels it. Record which tools have that review configured, who receives requests and what operators do after a denial. Source: n8n human review for AI tool calls
Assistant’s activation confirmation and runtime tool approval serve different purposes. Do not assume one supplies the other. Where review is required, retain a denied-action example as well as an approved one, and document how pending requests are noticed.
Copy this maintainable handover checklist
Complete each line with a name, reference or evidence location. Mark an item not applicable only with a reason. Keep unresolved items visible so acceptance reflects the workflow’s actual state.
- Identity: Workflow name, location, reviewed revision, handover date and current active/inactive state: ____.
- Purpose: Business outcome, process owner, operator and backup operator: ____.
- Process map: Trigger, node-to-step mapping, required inputs, decision rules, destinations and external changes: ____.
- Timing: Schedule or event source, time zone and expected operating window: ____.
- Credentials: Credential references, connected accounts, owners, access recovery contacts and operator access check: ____. No secrets included.
- Environment: Instance, hosting arrangement, relevant versions and dated current eligibility check for account, plan, region and deployment: ____.
- Samples: Sanitised ordinary, missing, ambiguous and duplicate inputs, with expected outcomes, execution references and observed destination results: ____.
- Approvals: Activation approver; any runtime review steps, reviewers, denial behaviour and pending-request handling: ____.
- Activation evidence: Approved revision, activation time, trigger evidence and first live outcome, or reason activation remains blocked: ____.
- Failures: Where errors appear, who checks them, when checks occur and escalation contact: ____.
- Recovery: Stop procedure, treatment of in-flight work, checks before retry and recovery procedure for the previous reviewed revision: ____.
- Limitations: Untested cases, unresolved dependencies and named owners for outstanding work: ____.
- Acceptance: Receiving operator’s demonstration, accepted scope, remaining conditions and next review trigger: ____.
Rehearse the operator’s first failure
Ask the receiving operator to work through a hypothetical case where the destination record was created but the following notification failed. Before retrying, they should inspect the destination and identify which step remains incomplete. Restarting everything could repeat an action already completed.
The recovery notes should explain how to stop new intake, inspect in-flight executions and decide what can safely resume. Use procedures verified for the actual workflow; do not promise that restoring an earlier revision reverses external changes.
Assign someone to check errors and unresolved review items. The September announcement explicitly said Assistant was not proactive and did not monitor the instance. Monitoring therefore needs an identified arrangement of its own, rather than an expectation that the builder will notice later failures.
FAQ: accepting an Assistant-built workflow
Do we need the original prompt in the handover?
Keep a sanitised copy when it explains intent or a disputed requirement. Prioritise the final rules and reviewed revision: later edits may have changed the workflow substantially. The operator should not need the chat history to understand a branch.
Can we accept the handover before activation?
Yes, as an explicitly inactive handover with a named activation owner and remaining checks. Record that live-trigger evidence is outstanding. This supports a planned transfer without presenting sample execution evidence as proof of live operation.
What changes should trigger another handover review?
Review changes to credentials, matching rules, destinations, approval steps or retry behaviour. Repeat the affected sample cases and update the reviewed revision. If runtime agents are involved, the custom AI agents guide provides related context for defining their responsibilities.
If your business needs help making an Assistant-built workflow maintainable, get in touch through our AI automation services. Bring the workflow, sample executions and unresolved ownership questions so the handover can be assessed against the work operators actually need to do.