There are thousands of free n8n workflows online, and they genuinely save time. Someone has already solved the problem you are looking at, and you can have their version running in about four minutes.
That speed is the risk. A workflow is not a document you read. It is a program you are about to give your client's API keys to, and it was written by someone who does not have your client, your data, or your liability.
What a template actually is
An n8n workflow exports as a JSON file: a list of nodes, the connections between them, and the settings on each node. Credentials are not included, which is the one thing template authors reliably get right.
Everything else travels with the file. The author's assumptions about field names, their timezone, their idea of what counts as an error, and quite often a URL or a spreadsheet ID they forgot to strip out.
The six checks
Run these before the workflow touches anything real. It takes ten minutes and it is the difference between a template that saves you an afternoon and one that costs you a client.
- 01Credentials. Open each node and list what it wants to connect to. If a lead-capture workflow asks for something unrelated to lead capture, find out why before you go further.
- 02Hardcoded values. Search the JSON for http, for spreadsheet and document IDs, and for email addresses. Authors leave their own in constantly. Yours will quietly write to a stranger's sheet.
- 03The error path. Look for whether anything happens when a step fails. Most templates have nothing. A workflow with no error path does not tell you it broke, it just stops, and you find out when the client asks why nobody was contacted last week.
- 04Node age. n8n deprecates and replaces nodes. A workflow written two years ago may reference a version that no longer behaves the same way. If a node shows as unrecognised on import, that is the tell.
- 05Trigger scope. Check what fires it and how often. A trigger that writes to the same table it watches is a loop, and a loop on a metered API is a bill.
- 06Data handling. Follow what it does with what it receives. Anything that posts customer data to a third-party endpoint you do not recognise is a decision you need to make deliberately, not inherit.
Import into nothing first
Never import straight into a client's live environment. Create a blank workflow in your own account, import there, and leave it inactive.
Then run it on test data and watch what happens. Not just the success path: break it on purpose. Give it a malformed record, disconnect a credential, feed it an empty result. What a workflow does when things go wrong is most of what you need to know about it, and it is the part no template author documents.
Then make it yours
Templates are a starting shape, not a finished product. The parts worth rewriting are almost always the same three:
- Naming. Rename every node to say what it does in your client's language. Six months later this is the difference between fixing it in five minutes and rebuilding it.
- Error handling. Add the path the author left out. Even a notification into a channel you actually read beats silence.
- The bit that is specific to this client. There is always one. That is the part you are actually being paid for.
The real mistake
It is not importing a bad workflow. It is importing forty good ones.
People find a large collection, import everything that looks useful, and end up with a workspace full of automations they did not write, cannot explain, and are not sure are running. When one breaks, and one will, they have no idea which, or what depended on it.
One workflow you understand end to end is worth more than every template you could download. Take the one that solves a problem you already have. Read it, break it, fix it, rename it. Then go back for the next one.
