What We Hand Over When a Build Ends

An automation handover should leave your team with the working system, its source, the accounts that run it, and instructions for everyday use and recovery. Ownership is practical: someone on your side can inspect what runs, make an agreed change, and restore a failed workflow without depending on the original builder.

At NexusPoint, the promise is that you keep what we build. The handover needs to make that promise usable. A folder of exports is only one part of it; the next person also needs to know which export is live and how to apply it.

The system runs in accounts you control

The live website, automation platform, hosting, and connected business tools should have a named owner on your side. Confirm that an administrator can sign in, manage billing, invite another teammate, and recover access. A project under a supplier’s personal account is a dependency that an archive alone cannot remove.

Inventory the services the system relies on. Include what each service does, who owns it, where billing is managed, and which workflows use it. Third-party subscriptions do not become free because a custom build is handed over. Your team needs to know which dependencies must remain available.

Access should follow the work. A person who updates page copy may not need permission to change credentials or deployment settings. Set those roles deliberately rather than making every teammate an administrator for convenience.

The source explains what is actually deployed

The source package should include the code, workflow definitions, prompts, field mappings, and configuration instructions needed to reproduce the live system. Identify the current release and how it reaches production. Source that differs from what runs is harder to use for either recovery or change.

Keep a repository your team controls, with useful history and a clear starting guide. GitHub’s repository transfer documentation explains how administrative control and associated repository material move when ownership changes. Account access and deployment connections still deserve their own checks.

The source should describe required environment settings without publishing secret values. Record where credentials are managed and how an authorised person replaces them. Do not scatter passwords through documents, sample files, or recorded walkthroughs. A complete handover does not require an insecure one.

What should the walkthroughs teach?

Walkthroughs should cover normal operation, routine changes, and common recovery tasks. Show the real interface with a representative example, then leave a written checklist beside the recording. A teammate should be able to find the instruction without watching an entire build explanation.

Useful walkthrough topics include:

• Finding a received request and its current state.
• Updating the approved content or business rule.
• Checking a failed execution and understanding its error.
• Replaying a saved item without creating a duplicate.
• Publishing a change and returning to the previous release.
• Replacing access safely when a teammate leaves.

Keep the recordings free of visible credentials and unnecessary customer details. Label their scope and update them when an interface or process changes. A video that teaches an outdated route can be worse than an honest note that the route needs review.

Keep the failure path beside the happy path

A handover is incomplete if it only demonstrates the successful run. List the failures the system can detect, where they appear, who receives the alert, and what that person should do next. Separate a temporary service failure from invalid data or an access problem that needs intervention.

For a form connection, the record should explain the receipt store, delivery states, retry rules, and reconciliation. The lead form to CRM guide shows why a retry needs the original submission reference and a safe destination operation.

Define a manual fallback as well. If an external service is unavailable, can the team find accepted requests and respond without losing the delivery history? Record what must be checked before resuming automation. Recovery should not depend on someone remembering how the system behaved during a previous outage.

A hypothetical handover of an onboarding workflow

Suppose a workflow turns an approved proposal into a project record and folder, then waits for the delivery lead to confirm the owner. The handover includes the live workflow, its source export, account roles, field map, approval rule, and a sample proposal with no real customer data.

A teammate who did not build it runs the sample. They identify the pending approval, assign the owner, and confirm the welcome message is ready. The builder then simulates a folder-creation failure in the test environment. The teammate finds the saved request, checks the alert, and follows the recovery checklist.

If the teammate needs an undocumented explanation, that explanation becomes part of the handover. The test is not a performance claim. It is a hypothetical way to reveal what the package is missing before the business relies on it.

Make ownership an acceptance check

Use visible actions to check ownership instead of treating a list of files as proof. A business administrator should verify access, while the person who will operate the workflow checks the instructions. Both roles matter: an admin can hold the keys without knowing how to use the system.

Handover item	How your team can check it
Account control	Sign in and inspect administrator and billing settings
Live source	Match the documented release to production
Routine operation	Complete a representative task using the instructions
Failure recovery	Diagnose and recover a test failure safely
Deployment	Apply an approved change and identify the rollback path
Ongoing ownership	Name the person responsible for updates and alerts

Record outstanding limitations and dependencies openly. If a service does not support exporting a component, say what remains in that service and what control the team has over it. Ownership should be described accurately, including external licences and platform constraints.

Agree what happens after the handover

Define who maintains the system and what continuing support covers. Your team may run it independently, ask us back for a specific change, or agree a maintenance scope. Those choices should be explicit, including who watches alerts and keeps business rules current.

Supplier access can end after acceptance unless ongoing work calls for it. If temporary access remains, document its purpose, permissions, and removal point. Keeping source and administrator access with the business means future changes do not require rebuilding the relationship from scratch.

The handoff test also belongs at the beginning of a build. If the workflow can only be explained by its current operator, capture that knowledge before implementation. Documentation made during the build has a better chance of matching the actual system.

Frequently asked questions

Does owning the system remove third-party subscriptions?

No. Hosting, automation tools, and connected services can still require paid accounts. The handover should identify those dependencies, their owners, and what stops working if a service becomes unavailable.

Should passwords be included in the source repository?

No. Keep secrets in the appropriate credential store and give authorised administrators access. The repository should explain required settings and replacement steps without exposing live secret values.

How do we know the handover is complete?

Ask a teammate who did not build the system to operate it, make a routine change, and recover a test failure using the supplied instructions. Document any explanation they still need before acceptance.

Can we invite NexusPoint back after handover?

Yes. You can invite us back for agreed changes or support. Keep the accounts, source, and operating instructions under your control so that continuing work is a choice the business can make.

Before commissioning a build, agree what your team will hold and what they must be able to do on the day after handover. Those acceptance checks belong in the scope alongside the features.