Using a Google Sheet as your automation's database

The Google Sheets step lets an automation add a row, update a row, or find a row and copy its cells onto the customer's contact record — turning a spreadsheet you already maintain into the memory behind your WhatsApp flows. It branches two ways, success and failure, and needs no code.

For most small stores this is the practical alternative to building an integration. If the answer to a customer's question is already in a spreadsheet somewhere, a flow can read it.

The three actions

Action	What it does	You configure	Typical use
Append	Adds a new row at the bottom	Which column gets which value	Waitlists, return requests, lead capture
Find	Locates the first matching row and saves its cells onto the contact	Match column, match value, which cells to save where	Order status lookup
Update	Edits the first matching row	Match column and value, plus the cells to change	Marking a return as received

Connecting a sheet

1. Add a Google Sheets step to your flow.
2. Sign in with Google inside the step and pick the sheet from the file picker.
3. Choose the worksheet tab.
4. Map columns by their header name, not their letter.

No sheet is ever pre-filled for you, including in ready-made blueprints — we cannot know which of your files is the right one, and guessing would mean a flow silently writing to the wrong place.

A lookup flow, end to end

The most valuable use is answering "where is my order?" from a sheet your fulfilment team already updates.

Always wire the failure branch

The failure port fires whenever there is no matching row or the sheet cannot be reached — a typo in the order number, a row not yet added, a revoked Google connection. In a lookup flow this is not an edge case; it is a routine outcome.

A flow that leaves it unwired stops dead, and the customer is left staring at a conversation that went silent after they answered a question. Wire it to a message and a handover, every time.

Saving values so you can use them later

A find action copies cells onto the customer's contact record, which means they are available as variables in every later step. The one prerequisite catches people: the contact field must already exist under Settings → Contact Attributes, or the save silently does nothing and your message renders a blank. That mechanic is covered in saving customer answers to contact fields.

What a sheet is good and bad at

Good for	Bad for
Data a human already maintains by hand	Anything changing second by second
A few thousand rows	Hundreds of thousands of rows
Capturing requests for your team to work	Being the single source of truth for orders
Getting a flow live this afternoon	A permanent integration you will scale on

The honest framing: a sheet is the right answer when the alternative is not building the flow at all. If you outgrow it, the Call External API step does the same job against your real system.

Capturing rather than reading

The append action is the other half, and it is how you build lists a flow cannot otherwise create. A back-in-stock waitlist is the clearest example: nothing in WhatsApp monitors your stock, so no automation can tell a customer their item has returned. What a flow can do is capture who asked, into a sheet you later send as a broadcast audience.

That is a genuinely different promise from the one competitors make, and it is the accurate one. The mechanics are in back-in-stock alerts on WhatsApp, and sending the sheet is covered in broadcasting from a Google Sheet.

Two-way, not one-way

The same Google connection also works in the other direction — sending WhatsApp messages straight from a spreadsheet, without building a flow at all. If your team lives in Sheets, that is often the faster route: sending WhatsApp from Google Sheets.

Cost and timing

A lookup happens inside a live conversation, so every message around it is free text inside an open window — free, per Meta's pricing rules. The lookup itself adds a moment of delay, which on WhatsApp reads as natural rather than slow.

One thing worth designing for: if your sheet is large or Google is slow, the customer waits. Sending a short "let me check that" before the lookup step makes the pause feel intentional.

A checklist before you publish

1. Column headers in the sheet match the mapping exactly.
2. Every contact field you save into exists under Settings → Contact Attributes.
3. The failure branch goes somewhere useful.
4. The Google account you connected is one that will still exist next year — not a personal account belonging to someone who might leave.
5. Tested in the simulator with both a matching and a non-matching value.

Point four is not paranoia. A flow connected through a departing colleague's Google account fails the day their access is revoked, and the failure looks like a bug rather than an access problem.

How to lay the sheet out

The structure decides whether the flow works, so it is worth getting right before you connect anything.

1. Headers in row 1, and nothing above them. No title row, no merged cells, no blank spacer row. The mapping matches on the text in row 1.
2. One header per column, spelled consistently. "Order Number" and "Order number" are different strings.
3. One record per row. Merged cells and multi-line entries break lookups.
4. Store the match column as text, not a number, so an order number like 001042 does not lose its leading zeros.
5. Keep it on one tab, or note which worksheet the step points at.

What the failure branch is really for

In a lookup flow, failure is routine rather than exceptional. It fires whenever there is no matching row, and that happens constantly:

• The customer mistyped the order number.
• They quoted a different reference — an invoice, a tracking code, a payment ID.
• The row has not been added to the sheet yet.
• The order was placed by someone else in the household.
• The Google connection was revoked.

Only the last of those is a fault. The rest are ordinary customer behaviour, and they are why an unwired failure branch produces the worst experience in the whole flow — the customer answers a question and the conversation goes silent.

Speed, and what to say while it thinks

A lookup adds a noticeable pause. On WhatsApp that mostly reads as natural, but it helps to fill it: sending "let me check that for you" before the Google Sheets step makes the wait feel deliberate rather than broken.

That message costs nothing. The customer wrote to you, so the 24-hour window is open and free text is free under Meta's pricing rules.

When to graduate off the spreadsheet

Signal	What it means
Lookups are slow or time out	The sheet has grown past a comfortable size
Data is often out of date	Manual updating is not keeping up
Several people edit it daily	Structure will get broken eventually
You need more than the latest state	A spreadsheet holds one row per thing, not a history

At that point the same job moves to the Call External API step, pointed at whatever system already holds the data. The flow around it does not change — same question, same success and failure branches — so the migration is smaller than it sounds.

Until then, a sheet is the right answer, and it is worth saying plainly why: the alternative for most small stores is not a better integration, it is not building the flow at all.