How to fix race conditions in no-code workflows
Automation tools run single workflows, but scale breaks them. A simple queue system helps to maintain order and prevent race conditions. Read: "Everything Starts Out Looking Like a Toy" #269
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: try these prompts to get better results from your Chatbot conversations. It seems counterintuitive to make your prompts simple instead of being very specific, but you get interesting results that are wider ranging than a single question when you need a follow-up. Edition 269 of this newsletter is here - it’s September 22, 2025.
Thanks for reading! Let me know if there’s a topic you’d like me to cover.
The Big Idea
A short long-form essay about data things
⚙️ How to fix race conditions in no-code workflows
When you build your first "hello world" automation with Zapier, Pipedream, or n8n, you’re looking for simple things. Connect a trigger, run some steps, make a few decisions, and get a predictable outcome. For many scenarios, this is easy and generally effortless.
The biggest lift in your automation is understanding the schema of the data received in your initial trigger and handing it off to the action of your choice. Your next biggest challenge might be finding a personal access key or an oAuth connection that lets you pull data.
And that ease of use and quick result hides a trap that's not evident until you start working on more complicated automations. These automation platforms do best when they run a single workflow at a time. They assume the arrival rate of records doesn't overwhelm the capacity of the system to respond.
When you scale that same system up to a much higher number of records or create overlapping workflows that need to update records in a certain order, you run into new problems. Some records fail and need to be retried. Some records run in parallel when they need to run in order.
Unexpected things are happening, which is never a good thing in workflow.
This is what race conditions look like in no-code clothing.
Workflow problems that every traveller knows
If you've ever flown on a commercial flight, you've experienced a series of interconnected workflows. You get a boarding pass that proves you have a seat on the plane. Then you need to wait your turn to board.
Finally, when you reach your row, you need to get seated so that other passengers can pass by your row. There are other constraints like the number of carry-ons that limit entry and cause other workflows (check a bag).
Workflows for business have similar rules and also need to proceed in order (at least for some of their steps).
Let's break down a sample automation for a GTM sales team when you handle a lead. You identify the order of operations like the boarding group for an airline flight, making sure each group knows when to board.
Group 1: Create a contact record
Group 2: Enrich the contact record with multiple data sources
Group 3: Assign the record to a seller depending upon the enrichment result
If boarding happens in order, everything flows. But if Group 3 rushes on before Group 2, the wrong person gets the wrong seat. And if two people get assigned to 17A at once, you’ve got chaos in the aisle.
The same thing happens in a CRM workflow. A new lead comes in (Group 1). An enrichment tool like Clearbit updates it (Group 2). Then a rule assigns it to a sales rep (Group 3). If the assignment runs before enrichment, the lead goes to the wrong rep. If two assignment rules fire at once, you end up with duplicates and confusion.
Most platforms don’t stop this from happening. They don’t know about groups. They just open the jet bridge and let everyone run.
How do you manage the boarding process in workflow?
The way out isn’t more triggers, actions, or retries. It’s adding the equivalent of a gate agent at the airport.
You need a simple control system that:
Locks the jet bridge so only one record is touched at a time.
Queues up boarding groups so steps happen in sequence.
Checks seats before assigning so you don’t get duplicates.
Your queue doesn't need to be fancy. It’s a datastore or table that tracks which record is in use, which step is next, and which steps must wait.
If this pattern of locks, queues, and idempotency (doing the same thing twice doesn't change the outcome) sounds familiar, it's because it's the basis of distributed systems design.
We're borrowing this concept for no-code to give you the advantages of these enterprise systems.
How to build a queue in Zapier
Here’s one way to implement this system using Zapier Tables as your queue:
Zap 1: Add new records to the queue
Trigger: Webhook to catch data from your source (like Airtable, Stripe, or a form)
Action: Create a new record in a Zapier Table called Queue with fields like:
unique_key(recordId + action + date)action(e.g., create, enrich, assign)priority(boarding group number)payload(raw JSON data)state(default = pending)created_at
Zap 2: Process records from the queue
Trigger: Schedule by Zapier (e.g., every 5 minutes)
Action: Find the oldest
pendingrecord in QueueAction: Formatter step to parse the payload into usable fields
Action: Run the critical process (e.g., create a CRM record, enrich it, or send an email)
Action: Update the Queue record to mark it as
done
With these two Zaps, you’ve created the simplest possible gate agent. The first Zap adds passengers to the boarding line (the queue table), and the other boards them in order.
You can extend it further:
Add a
lockstable if you need to make sure only one workflow touches a record at a time.Use the
priorityfield to enforce boarding groups (create → enrich → assign).Add a
last_action_hashfield to enforce idempotency (no duplicate seats).
With a lock table, a queue table, and a zap to run the workflow, you've got the basics of a workflow engine that handles concurrency.
Why it matters now
When you have ten automations, you can shrug at the occasional mix-up. When you have a hundred, every mistake compounds. Instead of saving time, you spend it untangling duplicates, fixing assignments, and explaining why two emails went out instead of one.
The point of automation is leverage. But without order, leverage turns into rework. In our example of enriching contacts and assigning them based on the outcome of the enrichment process, there are known issues that almost always happen.
What do you do if you get no result for enrichment? You might want to send a record to a remediation queue instead of assigning it
What if an email for a contact fails? You might want to stop before attempting assignment
What if you need to have a tie-breaker between assignment teams based on your rules of engagement? You might need an additional workflow to run to determine the ultimate result
These exceptions need intervention, so you need to limit them as much as possible.
Workflow tools won't solve this for you with their native functionality. They’re built to fire single workflows, not orchestrate fleets. If you want scale, you need to bring your own gate agent.
Getting Started
When to implement this pattern: Start thinking about queues when you have 5+ automations that touch the same data, or when your team asks "why did this happen?" more than once a week.
How to get started:
Pick your simplest automation that has ordering requirements. Don't start with your most complex workflow - choose something that processes leads, creates contacts, or handles form submissions.
Start with just one queue table using the two-Zap pattern I showed above. Don't over-engineer with locks and priority systems until you've proven the basic concept works.
Test with 10-20 records before scaling up. You'll spend 2-3 hours setting up your first queue, and expect to debug the first few runs. But once it's working, it's smooth sailing.
Look for these warning signs that you need a queue:
Duplicate records being created
Workflows running out of order
Failed steps that need manual retry
Team members asking "why did this happen?"
Your team will thank you when automations stop breaking. You'll spend less time untangling duplicates and more time building new features.
What's the takeaway? Automation is like boarding a plane. Without rules, people rush the jet bridge, board out of order, and fight over seats. With a gate agent, boarding groups, and assigned seats, the system flows smoothly.
Links for Reading and Sharing
These are links that caught my 👀
1/ Write first, then vibe code - Github is expanding the idea of an agent context by creating a template for spec-driven development. With an evolving specification, agents can get oriented even if the underlying code is changing around them.
2/ All the UUIDs - Apparently you can create a list of all of the possible UUIDs. This is a bit of a science project because practically speaking you’re not going to write every “unique” number, but it’s important for considering a design to build dynamic web pages.
3/ Caution flags on AI - Americans are worried about AI impact, and the concern is increasing. The main reason? Uncertainty about what that impact means.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon