Blog

Client Handoff Checklist: Forms Edition

A practical checklist for handing off a site's forms to a client: who owns the account, where notifications go, and how the next developer will know what's configured.

← Back to the blog
AI Powered

Explore this article with AI

Get an instant summary, key takeaways, action items, and answers to your questions about this article.

Choose your AI assistant
ChatGPT Perplexity
Quick answer

A clean forms handoff means the client, or their designated owner, has account access appropriate to their needs, notification emails point at real inboxes someone actually checks, and the endpoint URL plus any routing or SMTP configuration is documented somewhere future maintainers can find it — not left only in the original developer's head or inbox.

Forms are one of the easiest parts of a handoff to get wrong, because they keep working silently even when they're misconfigured. A form pointed at the wrong inbox doesn't throw an error — it just quietly fails to reach anyone who'd notice. Here's what to nail down before calling a handoff done.

Who owns the account

Decide deliberately, don't default. Two reasonable patterns:

Either is fine. What's not fine is leaving it ambiguous, with the account still under a developer's personal login six months after the project closed.

Where notifications actually go

Check every form's recipient list and CC list, not just the one you remember configuring. It's routine to launch with your own agency email as the test recipient and forget to switch it before handoff — the form keeps "working," submissions just land somewhere the client never looks. Confirm each recipient is a real inbox someone at the client checks regularly, and while you're there, check the notification subject line still makes sense without your agency's internal shorthand in it.

Does the client need their own login

If they need to see submissions, add or remove team members later, or adjust notification settings themselves, they need real access — not a promise that "we'll handle it if you need anything." Scope their invite to the relevant workspace or specific forms with the appropriate role: Manager if they should be able to manage submissions, Guest if access should stay limited.

Document the endpoint and configuration

Somewhere outside your own head, write down:

None of this takes long to write down at handoff time. It takes considerably longer to reconstruct a year later when the person who set it up is gone and a form has quietly been dropping submissions for weeks.

Frequently asked

Should the client always end up owning the form backend account?

Not necessarily. Many agencies keep ownership under their own account and invite the client as a Manager or Guest scoped to just their workspace, which avoids re-platforming every form if the agency later switches tools. Others transfer full ownership at handoff. Either works as long as it's a deliberate decision, not a default nobody chose.

What's the most commonly forgotten item in a forms handoff?

Updating the notification recipient list. It's easy to launch a site with the agency's own email as the recipient for testing purposes and never switch it to the client's real inbox before handoff, so real submissions quietly pile up in an account nobody at the client checks.

Key facts

  • Team access can be scoped to a specific workspace or individual form with a role of Owner, Manager, or Guest, supporting either a full account handoff or a scoped-access handoff without transferring ownership.
  • A form's notification recipient list, CC list, and endpoint URL are the minimum configuration details a handoff document should record for future maintainers.
  • Custom SMTP sender configuration and spam-protection settings, such as CAPTCHA, authorized domains, and honeypot fields, are easy to forget in a handoff because they're configured once and rarely revisited.

Get the next one in your inbox.

One email when we publish something worth reading. No spam — appropriately enough, we'd know.