Who Owns the Workflows, the Accounts and the API Keys When the Project Ends?

Detailed Explanation

Most conversations about hiring an automation provider focus on what gets built — the workflow logic, the integrations, the testing. Almost none of them focus on the question that actually determines what happens if the relationship ends: who holds the accounts everything runs through?

This is a deliberately unglamorous question, which is exactly why it gets skipped during a sales conversation and becomes urgent during a dispute. The workflow logic itself — the sequence of steps, the conditions, the mapped fields — is rarely the thing that traps a business with a provider it wants to leave. What traps a business is not having its own name on the automation platform login, the API keys the workflows call, or a third-party account the whole system quietly depends on.

Why Code Ownership Isn't the Same as Control

A contract can say clearly that the business owns everything the provider builds, and that clause can still mean very little in practice if the automations themselves live inside accounts the provider controls. Ownership of the design is a legal position; control of the running system is an operational one, and they don't automatically travel together.

Consider what actually has to happen for a business to switch providers or bring automation in-house: someone needs to be able to log into the automation platform, see every workflow, and keep them running or move them. If that login belongs to the provider, the business is dependent on the provider's cooperation to get access — and a provider who is unhappy about being replaced has very little incentive to make that handover smooth.

The Three Things That Actually Matter

The automation platform account itself. Whether it's a no-code platform, a self-hosted tool, or a custom-built system, someone's credentials are the master login. If that's the provider's business account rather than one registered to the client, every workflow inside it is, practically speaking, the provider's to control.

API keys for every connected service. Automations rarely run in isolation — they call an accounting platform's API, a CRM's API, an email or messaging service's API. Each of those calls needs a credential, and each credential is typically issued to whichever account requested it. If those keys were generated under the provider's developer account rather than the business's own, the business doesn't actually hold the connections its automations depend on, even if it owns the workflow logic that uses them.

Third-party accounts the whole system depends on. This is the one businesses most often miss. A WhatsApp Business number, a dedicated Google Cloud project, a payment gateway sub-account, a dedicated email-sending domain — these are sometimes set up under the provider's name as a matter of convenience, and untangling them later can mean losing the number, the sending reputation, or the account history entirely, not just re-pointing a login.

What to Settle Before the Project Starts, Not at Handover

The practical fix is straightforward, but it has to happen at the start of the engagement, not the end of it:

1. The business's own account is the top-level account for the automation platform, with the provider added as an authorised user or collaborator for the build and maintenance period — not the other way around.
2. API keys and app registrations are created under the business's own developer accounts wherever the connected service allows it, even if the provider configures and manages them day to day.
3. Any dependent third-party account — messaging numbers, cloud projects, payment sub-accounts — is registered in the business's name from day one. Moving these later is often disproportionately difficult compared to setting them up correctly at the outset.
4. The contract states explicitly what happens to access at the end of the engagement, not just who owns the intellectual property — who removes the provider's access, on what date, and what the business is left holding.

This is worth raising explicitly in a requirements brief or during the vetting conversation when deciding whether to hire a consultant — a provider who resists the business holding its own top-level accounts is telling you something worth hearing before signing, not after.

A Genuine Technical Constraint Worth Knowing

This isn't only a contractual or trust question — some platforms have real technical limits on transferring ownership after the fact. On Microsoft Power Automate, for example, a non-solution-aware cloud flow cannot have its owner changed in place, because the owner's identity is part of the flow itself; the only workaround is recreating the flow under the new owner's account, which loses its run history. If a provider tells you "we'll transfer ownership at handover," it's worth confirming that the specific platform and flow type actually supports that — because for some configurations, that promise isn't technically possible to keep, no matter how well-intentioned it is.

Things to Consider

• Ask directly during vetting, not after signing. "Whose account will these run under, and can I see admin access from day one?" is a fair, direct question to ask any provider before committing — see the broader vetting checklist in what should you ask an automation consultant before hiring them.
• A provider's reluctance to answer is itself useful information. A provider confident in their work has no reason to resist the business holding its own top-level accounts; hesitation on this specific point is worth treating as a signal, not an oversight.
• This applies to internal builds too, not just external agencies. If an employee sets up automations under a personal account rather than a business one, the same custody problem exists the day that employee leaves — see our IT person built all our automations and then left — what do we do now for the remedial version of this same failure.
• Revisit this at renewal, not just at the start. Accounts and integrations added months into an engagement can drift back into the provider's name if nobody is actively checking — a periodic access review catches this before it becomes a problem.

Common Mistakes

• Assuming an IP ownership clause settles the question. Legal ownership of the workflow design and practical control of the running system are different things — a contract needs to address both, not just the first.
• Letting a provider set up accounts "for convenience" without redirecting them to the business's name. What's fastest during a build is often the provider's own account; what protects the business long-term is the reverse, and it's far easier to set up correctly at the start than to migrate later.
• Not asking about a specific platform's ownership-transfer limitations before relying on a verbal promise to transfer later. Some transfers are simple; others are technically constrained or impossible for certain configurations — verify rather than assume.
• Overlooking dependent third-party accounts because attention is focused on the automation platform itself. A messaging number or payment sub-account registered in the wrong name can be harder to recover than the workflow logic ever was.