Handover
What client-owned automation includes
Owning a workflow means being able to run it, change access and recover it when something fails. A copy of the workflow file is only part of that.
I settle the account question before deployment. The client should control the server or hosting account and the connected services. If the workflow uses a domain, its DNS belongs in that picture too. Otherwise a later change of developer can turn into a search for somebody else’s login.
Access is where handovers usually get fragile
A workflow may be able to read email, customer records, calendars and payment data. Give it credentials owned by the client, record where those credentials are managed and grant only the access each connection needs. A secret copied into an undocumented node is easy to forget and hard to rotate.
The same applies to the people operating the workflow. Someone on the team needs admin access; other users may need less. Those roles should be clear before the original builder steps away.
Write down the recovery path
The handover should say what starts a run, what data comes in, which services are called and where the result goes. More useful than a long tour of every node is a short answer to the first failure question: where do I look, and can I safely retry?