Testing an Exported Workflow Before the Client Sees It

An exported workflow is a working draft, and the work between the draft and a live automation is wiring it into the client's accounts and then trying to break it. That is a test run, and it is the cheapest hour in the whole project.

A workflow built in abi. Agent Studio arrives as a file you import into n8n, with every connection written as a named placeholder and a short guide that says what each one needs. You supply the credentials, from the client's own accounts, because abi. never asks for a password, an API key or a token for the systems in your workflows. The wiring takes about fifteen minutes. The testing takes longer, and it is where the value is.

Wire it in the client's account, not yours

It is tempting to wire and test in your own tenant and move it across. Don't. The credentials, the permissions and the quirks that matter are the client's, and a workflow that passes in your account tells you about your account. Do the wiring in theirs, with whoever holds the keys sitting beside you or granting access for the session.

Use the placeholder names as a checklist. Each one is a connection that needs to be made, and a placeholder left unwired is the commonest reason a first run stops halfway.

Five things to try to break

Run it once with clean test data and it will probably pass. That tells you the happy path works. Then try these.

An empty field. Send it a record with the one field people forget. If the workflow assumes it is always there, you will find out now rather than on a Friday afternoon.

A strange value. A name with an apostrophe, an address in a different format, an amount with a currency symbol. Real data is untidier than the data anyone invents for a test, and the workflow was designed from a description of the process rather than from the records.

The approval step. If the design puts a person in the loop, check that the request reaches the right person, that it can be approved and refused, and that refusing does something sensible. A refused request that silently disappears is worse than no approval step at all.

The failure path. Break one connection on purpose and see what happens. Does someone find out? Where does the failed record go? An automation that fails quietly is the one that does the damage.

The undo. Work out how you would reverse one run. If the workflow sends something to a customer or changes a record, you want to know the answer before it has happened a hundred times.

Write the owner down before it goes live

Before you switch it on, put a name against it. The person at the client who asked for it, a one-line note of what it touches, and what to do if it misbehaves. This takes two minutes and it is the thing most often left until later, which usually means never.

On a client's map, an automation designed in abi. shows as a ghost until you mark it deployed. That is the right moment to mark it, and not before. A map that shows something as live that has only been tested is making a claim you have not earned.

Run it alongside, once

For the first week, if the process allows it, let the manual route carry on in parallel and compare. It costs a little duplication and it catches the cases your test data never contained. The first real record that goes through differently is worth more than any amount of synthetic testing.

This is not always possible. Some processes cannot be done twice, such as sending an invoice or a notification to a customer. In those cases, run the workflow with the output going to an internal address first, and read what it would have sent.

What testing will not tell you

A test run shows that the workflow does what you designed. It does not show that the design is right. That depends on whether the interview captured the real process, and whether the people it affects will use it. A workflow can pass every test and still be built around a version of the process that nobody follows.

So treat the test as the first of two checks. The second is a month later, when real use has had time to find the gaps, and you ask the person whose job it was what they still do by hand.

And once it runs

Once it is live, it runs in the client's n8n, under their account. abi. does not run it or watch it. If the client expects somebody to be watching, that needs to be said and priced before go-live and not discovered after the first failure. Tell them at the point of handover what is watched, by whom, and what is not.

Keep a short note of what you tried and what happened. Two lines per test is enough. When the client asks, a month on, why it behaves the way it does, the note is the answer, and it saves you rebuilding the reasoning from memory. It is also the start of a checklist you will reuse on the next client, which makes the second test faster than the first.