How to set up AI workflows
Learning how to set up AI workflows changed the way I handle repetitive tasks, moving from manual chat prompts to a system that runs on its own.
You’ll see how to pick a trigger, connect a model, and store the result where you need it.
By the end, you’ll have a working example you can copy and a clear path to debug when things go sideways.
What most guides get wrong about AI workflows
Most tutorials treat the AI model as a magic black box that you just plug into a Zapier step and forget.
They ignore the fact that models need clear input formatting, token limits, and error handling.
When you skip those details you end up with workflows that look fine in a demo but choke on real data.
I’ve seen guides suggest sending raw HTML straight to GPT‑4 and wondering why the output is gibberish.
The truth is you need to sanitize, truncate, and sometimes summarise before the model sees it.
Another common mistake is treating the workflow as linear when in reality you often need branching logic based on the model’s confidence score.
Guides that skip branching leave you stuck manually rerunning cases that fall below a threshold.
Finally, many posts pretend that pricing is flat and ignore how usage spikes can blow your budget overnight.
If you don’t monitor token usage per run you’ll get a surprise bill the next month.
Why does my workflow break when I add a second model?
Adding a second model introduces two new failure points: mismatched output formats and competing rate limits.
The first model might return JSON while the second expects plain text, causing a parse error that stops the whole scenario.
I ran into this when I tried to chain a summarisation model (Claude‑2) after a data‑extraction model (GPT‑4).
The extractor gave me a JSON array, but the summariser choked on the brackets and returned an empty string.
Fixing it required a simple transformation step that strips the outer array and joins the items with new lines.
The second issue is rate limits: each provider has its own quota, and when you hit one the other keeps trying and fills up your operation log.
I once burned through my monthly GPT‑4 tokens in two hours because the summariser kept retrying after each failure.
The solution is to add a conditional break that stops the scenario if the first model returns an error code.
That way you don’t waste tokens on a dead end.
A real example: scraping leads with GPT‑4 and Make
Let’s walk through a concrete workflow I use every week to turn a list of LinkedIn URLs into qualified leads.
First, I grab the URLs from a Google Sheet using Make’s HTTP module.
Next, I send each URL to a scraping API that returns the raw HTML of the profile page.
I then feed that HTML into GPT‑4 with a prompt that asks for the person’s name, title, company, and a short pain point based on the post.
The prompt looks like this:
Extract the following from the LinkedIn profile HTML:
- Full name
- Current title
- Company
- One sentence describing a recent challenge they posted about
Return as JSON with keys name, title, company, pain_point.If any field is missing, return null for that key.
I wrap the prompt in a text aggregator so the HTML doesn’t exceed the model’s token limit.
If the HTML is longer than 3 000 characters I truncate it to the first 3 000 chars and add a note that the rest was omitted.
After GPT‑4 returns JSON I use Make’s JSON parser to map the fields into a new row in a second Google Sheet.
If the parser fails because the model returned plain text instead of JSON I route the output to an error log sheet for manual review.
This little safeguard has saved me from dozens of bad runs where the model decided to be chatty.
I run the scenario every night at 02:00 AM via a time trigger.
In the morning I have a fresh sheet of leads ready to import into my CRM.
The whole thing costs me about $0.012 per lead in API calls, which is cheap enough to scale to thousands.