From a Client's Map to a Running Workflow Without Touching Their Passwords

The safest way to build an automation for a client is to design it somewhere that cannot hold their credentials, export it as a file, and wire the connections inside the client's own account. Everything else about the build is detail. That one decision is what keeps an MSP out of the incident report when a token leaks, and it is the decision most automation tooling gets wrong by default.

Most platforms want the keys up front. Connect your CRM, connect your mailbox, connect your accounts package, and then we will show you what we can do. For your own business that is a convenience. For a client's business it is a liability you are carrying for a workflow that does not exist yet.

Four steps, and you can stop after any of them

Take a process from a client's map. Say it is the quote approval chain: account manager to engineer for a check, back to the account manager, to a director for sign-off, back again, then to finance when the client accepts. Six hops, four people, and a day of waiting at each one.

The first step is a review. abi. Agent Studio reads every step of the process, the systems it touches and how often it runs, and proposes the specific changes worth making: automate this hop, remove that one, batch the other. The proposals come together, because three of them are usually the same realisation, and each one carries the time it saves and how risky it is. A review costs 25 credits.

The second step is to keep the ones you agree with. Studio restates the process as it would run with those changes, side by side with how it runs today. The client's map still records the real version. Nothing on it changes until you say the change has been made.

The third step is the design. The new process becomes a workflow on a canvas, where you can move steps and edit what each one does. Editing is free and makes no AI call, so this is where you spend the time: this is the drawing your engineer will build from.

The fourth is the build. Pick n8n or a written runbook, and you get the file, a step-by-step guide, a list of everything you have to wire by hand, and what it will cost to run each month at the cadence the process actually runs. Make.com export is in build.

What arrives in the file, and what does not

The exported workflow is a working draft, about fifteen minutes from running. Every connection in it is a named placeholder: the CRM node is labelled as the client's CRM, the mailbox as their mailbox, and the guide says which credential goes where. Nothing in abi. ever asked for a key, a token or a sign-in on the client's behalf, so there is nothing in the file that could leak, and nothing on our side that could either.

That is the handover. Your engineer opens the client's n8n, imports the file, pastes the credentials the client already holds into the placeholders, and runs it. Once it is running it is the client's, under their account. abi. does not run it or watch it, and the guide includes how to back it out.

The part that is easy to skip

There is a step between "built" and "running" that most automation projects lose track of, and it is where the margin goes.

A workflow you have designed and exported is not a saving. Until somebody marks it deployed, the process on the client's map still counts as manual, and the workflow shows as a ghost: visible, drawn, not live. That sounds like pedantry until you have three clients each with four automations in various states and someone asks which ones are actually running. The honest answer is on the map, and the map does not let you claim a saving you have not switched on.

The ghost is also the reason the quarterly review has content. Here is what we designed, here is what is live, here is what is still manual and why. That is a conversation about progress, which is the one that renews.

Already running automations? Read those first

Half the clients you take this to already have automations. Some they built, some a previous supplier built, some an enthusiastic employee built in a lunch break two years ago. Nobody has a list.

Point Studio at a workflow the client already runs in n8n or Make and it reads it back onto the map: the steps, the systems it touches, and which of them nobody owns any more. That last one is the finding people do not expect, and it is often the first thing worth fixing. Ten credits, and it turns "we already have some automation" from an objection into a starting point.

Every workflow arrives already on the register

One more thing the file does on the way out. When Studio builds a workflow, it scores it from what its own steps do: how much it decides on its own, what data it touches, how hard it is to undo. It adds the agent to the client's AI register with a risk tier and the controls that tier calls for. If the workflow reaches a customer without a person in the way, Studio puts an approval step in and says why.

For an MSP that means the question "who owns this and what happens if it is wrong" is answered at build time, in the client's register, against a named owner, rather than six months later by whoever is on call. It costs nothing extra, and it is the difference between an automation you built and an automation you can defend.

When not to do it this way

If the client's process lives entirely inside one platform with its own automation layer, build it there. A native flow beats an imported one when there is nothing to integrate. If the process has never been mapped, map it first: Studio reads from the map, and a workflow built from a guess is a guess with more steps. And if the client wants you to hold the keys because they do not want the admin burden, that is a managed service with its own price, not something to absorb into the build.

Everywhere else, design where the credentials cannot be, export the file, and wire it where they already are.