Who Owns Client Automations: Your Account or Theirs?

Who owns client automations? Most freelancers never decide, so the answer defaults to whoever holds the login and the credit card. My position: the client should always own the credentials and the run data, the platform account should sit on their side unless the vendor explicitly allows you to host, and your contract has to say who walks away with what before you build the first workflow.

It’s the part of automation work nobody puts in the proposal. You scope the triggers and the error handling, but not the day the client leaves, or the day you do. That day always comes, and the vendors’ own docs show how little moves over cleanly when it does.

Who owns client automations? Split it into five things

Client automations break down into five assets: the platform account, the app credentials, the platform bill, the workflow logic, and the run history. Each one can have a different owner, and most handoff fights start because nobody assigned them. My default split gives the client the first, second, third and fifth, and gives you your reusable know-how.

• The platform account. Owned by the client, with you invited as a member or admin. The owner seat and the owner email belong to someone on their payroll.
• The credentials. Always the client’s, authorized against client-owned logins, even when the account is yours. A shared ops inbox beats an employee’s personal Gmail, because employees leave.
• The platform bill. On the client’s card, or passed through at a price you state openly. Never silently on yours.
• The workflow logic. Split. The client owns the specific workflows you built for them once they’ve paid. You keep your templates, snippets and patterns, and license whatever is embedded in their build.
• The run history. Client data. They decide how long it’s kept and they get an export before anything is deleted.

It’s the same split a web developer uses for a client’s domain and hosting. Automation work skipped the lesson because a Zap feels too small to need a contract.

What Zapier, Make and n8n say about transferring ownership

None of the three big platforms moves a finished automation between two separate owners without friction. Zapier copies workflows but leaves history and connections behind. Make transfers whole organizations cleanly, individual scenarios less so. n8n won’t change who created a workflow. The cheapest handoff is the one you never have to do.

Zapier: copy, reconnect, turn back on

Zapier’s Copy to another account feature is honest about what doesn’t survive the trip[1]:

• Copied Zaps arrive with placeholder connections that have to be re-authenticated in the destination account.
• Run history and usage data stay in the source account. The copy shows up as a brand-new asset.
• Every copied Zap lands turned off, whatever its status was before.
• Webhooks by Zapier URLs change, so every form, app or script posting to the old URL needs updating.

Inside one account you can change a Zap’s owner to another user[2], which helps with a teammate and does nothing for a client who has their own account. Then there’s the part freelancers skip. Zapier’s Terms of Service, effective April 9, 2026, say you won’t “grant non-users access to the Service or use the Service to provide a hosted or managed service to others.”[3] Back in 2021, when a Zapier Solution Partner asked about hosting clients’ Zaps on his account for $5 a month, Zapier’s community manager answered that it would be reselling Zapier, which isn’t permitted.[4] On Zapier, the question mostly answers itself: build in the client’s account.

Make: organizations are the unit that moves

Make is easier on agencies because its container is the organization, and each organization has its own plan and billing. An organization has exactly one owner, and that owner can transfer ownership to any existing member.[5] So the clean pattern is simple: the organization is created in the client’s name, you’re invited in, and when the engagement ends the client already holds the owner seat. Moving single scenarios is rougher. A blueprint carries modules, settings and mapped values, but whoever imports it still has to create their own connections.[6]

Hosting clients on Make has a history too. In a June 2025 community thread, a Make staff member wrote that there had previously been no way compliant with Make’s Master Service Agreement to offer Make as a managed service, and pointed to the new Make Managed Services subscription.[7] MMS lets a distributor organization create child organizations for clients and allocate credits to them in blocks of 10,000.[8] That’s the sanctioned route for hosting on Make. A team per client inside your own plan is something I’d confirm with Make before selling it.

n8n: the license decides more than the UI

n8n has the most explicit guidance, and it’s newer than a lot of forum answers. Its license FAQ says you can build automations for clients on your own instance as long as the clients can’t create or edit them, charge for building and maintaining them, and serve any number of clients from one instance. You can also install and manage n8n on a client’s own server, as long as you aren’t hosting it for them as well. Hosting n8n so clients build their own workflows, or white-labeling it, needs a commercial agreement. That FAQ covers self-hosted n8n only; n8n Cloud runs on its own subscription terms.[9]

Ownership inside an instance is sticky. You can’t change a workflow’s owner except by deleting the user.[10] On n8n Cloud, the instance owner is an email address, and changing it changes who owns the instance and who receives the invoices.[11] Start the Cloud instance under an email the client controls and there’s nothing to transfer later. One n8n consultant on the community forum put his rule bluntly: client instances never live in his hosting accounts, always in the client’s.[12] If you’re weighing a single agency instance anyway, check what white-labeling n8n really costs first.

Should you build automations in the client’s account?

Yes, by default. Build automations in the client’s account, get invited as a member or admin, and let the client hold the owner seat and the card. You give up a little convenience and get a clean exit for both sides. Host in your own account only when the vendor explicitly allows managed service and your contract covers the exit.

The case for your own account is real: one login, one invoice, usage you can measure per client and mark up. A Make community veteran listed those benefits in a 2024 thread, along with the downsides of client-owned accounts. Clients change things and break scenarios, and they can remove you unless you set the account up as its admin.[13]

I don’t find the kick-out risk persuasive. If a client wants you gone, holding their automations hostage doesn’t save the relationship, it just makes the breakup uglier. Breakage is a change-control problem, and custody doesn’t fix it.

There’s a quieter argument too. A client with separate automation vendors for sales, HR and support ends up with three accounts they can’t see into, as another Make community member pointed out.[7] Whatever you decide about the account, collect credentials as if you’ll hand them back tomorrow. Here’s how to collect client access without passwords.

What goes wrong when nobody decides who owns it

Ownership problems surface at the end of a relationship, when nobody’s in a generous mood. The same four failure modes come up again and again in agency and freelancer forums, and each one is cheap to prevent up front and expensive to fix later.

The client churns and you lose access

In a client-owned account, the client can remove you the day they give notice, and anything you built for reuse inside it leaves with them, like the error handler you meant to use for your next three clients. Keep your library in your own account and treat what lives in theirs as the delivered copy.

The client leaves and the workflows die with your card

It’s the mirror image. Everything runs on your plan, the client leaves, and you either keep paying for a business you no longer serve or cancel and break their operations. On Zapier, migrated copies arrive switched off with fresh webhook URLs and no history,[1] so somebody has to reconnect every app and repoint every form that posted to the old URL. Budget that work in the contract or you’ll do it for free.

The freelancer disappears and the client is locked out

Solo operators get sick, take full-time jobs, or go quiet. If the account, owner email and connections all belong to that person, the client can’t even see what’s running. On Make, only the existing owner can transfer an organization; anyone else has to go through support.[5] On a self-hosted n8n box on the freelancer’s own server, a lapsed hosting bill ends everything at once.

The “why does this say Zapier?” moment

The client clicks a connect link and Google’s consent screen names a company they’ve never paid. Zapier’s own white-label docs say it directly: the third-party consent screen shows Zapier requesting access, and branding there isn’t fully controllable.[14] Nothing is insecure here, but the client now wonders what else they don’t know about your stack and your markup. Name your platform in the proposal, or run on one where the OAuth app is registered under your agency. We covered the white-label options for Zapier agencies separately.

The SOW clauses that settle ownership before you build

Your statement of work should name an owner for each of the five assets, say what happens to each at termination, and price the handoff. Put it in the first contract, not the last email. Clients sign these clauses easily when nobody’s leaving.

One legal wrinkle, with the caveat that I’m not a lawyer. Under US copyright law, work a contractor is commissioned to create only counts as “made for hire” if it fits one of nine listed categories and both parties sign an agreement saying so.[15] Automations rarely fit, so without a written assignment the default can leave copyright with whoever built them. Here’s the checklist I’d want in every automation SOW:

• Account of record. Which platform, whose name the account is in, which email holds the owner seat, and what role you get.
• Platform billing. Whether the subscription sits on the client’s card or is passed through by you, at what markup, and how it moves to the client within a set number of days after termination.
• Credential custody. Every connection is authorized with a client-owned login, no passwords change hands, you keep a register of connections, and you remove your own access within a stated window after the engagement ends.
• Deliverable IP. The client owns the workflows built for them on payment in full. You keep pre-existing materials and generic templates and grant a perpetual, non-exclusive license to whatever of yours is embedded in their build.
• Run history and data. Retention period, a client export on request, and deletion of your copies at the end.
• Handoff package. Exports of each workflow in the platform’s native format, the connection register, a list of webhook URLs that external systems call, and a short runbook for each workflow.
• Notice and transition. Thirty days’ notice, automations keep running through it, and transition help after that at a stated hourly rate. No kill switch, ever.
• Key person. If you’re unreachable for a set number of business days, the client may bring in another provider and you’ll hand over access.
• Vendor terms. A line confirming the arrangement fits the platform’s terms, so nobody finds out mid-engagement that the setup was never allowed.

If you pass platform costs through, show them in the retainer. Pricing setup fees, retainers and usage pass-through has its own post.

Where TaskJuice fits

We built TaskJuice for agencies that host client work on purpose, which is the exception above: hosting clients isn’t a gray area here, it’s the product, so the account can sensibly be yours while the credentials and data stay the client’s. Each client gets an isolated workspace. A connection can be marked client-provided, so the client authorizes their own account from a magic link without sharing a password, and can revoke it from their portal. You can register your own OAuth app per integration, so consent screens show your agency’s name instead of ours.

None of that replaces the contract; it just makes the credential clauses easier to keep. If you’re comparing hosted setups, the difference between real tenant isolation and folders is the first thing I’d check.

Frequently asked questions

Can I transfer Zaps from my Zapier account to a client’s account?

Yes, with Copy to another account, which duplicates Zaps rather than moving them. Connections need re-authenticating, history stays behind, copies arrive turned off, and webhook URLs change.[1]

Who owns a Make scenario I built for a client?

On the platform, whoever owns the organization controls it, and only that owner can transfer the organization.[5] Legally, your contract decides. If the SOW assigns deliverables to the client, build in an organization they own so the platform matches the paperwork.

Can I host n8n for my clients?

Under n8n’s license FAQ you can run client workflows on your own self-hosted instance as long as clients can’t create or edit them, and you can manage n8n on a client’s own server if you don’t also host it. Letting clients build workflows in your instance, or white-labeling it, needs a commercial agreement.[9]

References

[1] Copy assets to another account, Zapier Help Center: help.zapier.com/hc/en-us/articles/8496275081357-Move-Zaps-between-accounts

[2] Manage assets in your Zapier account, Zapier Help Center: help.zapier.com/hc/en-us/articles/39703938224781-Manage-assets-in-your-Zapier-account

[3] Zapier Terms of Service (effective April 9, 2026), Zapier: zapier.com/tos

[4] Hosting Zaps on Clients’ Behalf, Zapier Community: community.zapier.com/how-do-i-3/hosting-zaps-on-clients-behalf-13136

[5] Organizations, Make Help Center: help.make.com/organizations

[6] Scenario blueprints, Make Help Center: help.make.com/blueprints

[7] Should automations be built in the client’s Make account or in a provider’s account?, Make Community: community.make.com/t/strategic-question-should-automations-be-built-in-the-clients-make-account-or-in-a-providers-account/85053

[8] Make Managed Services (MMS) user guide, Make Help Center: help.make.com/make-managed-services-mms-user-guide

[9] License FAQ, n8n Docs: docs.n8n.io/n8n-community-license/community-license/license-faq

[10] Share with others, n8n Docs: docs.n8n.io/build/manage-workflows/share-with-others

[11] Change instance ownership or username, n8n Docs: docs.n8n.io/deploy/use-n8n-cloud/configure-cloud/change-instance-ownership-or-username

[12] Running n8n automation for clients, n8n Community: community.n8n.io/t/running-n8n-automation-for-clients/43103

[13] Best practice: single vs. multiple Make.com accounts for client management, Make Community: community.make.com/t/best-practice-single-vs-multiple-make-com-accounts-for-client-management/57400

[14] White Label: getting started, Zapier Developer Docs: docs.zapier.com/white-label/getting-started

[15] Circular 30: Works Made for Hire, U.S. Copyright Office: www.copyright.gov/circs/circ30.pdf