Question 1

How would you build a workflow that writes website form leads into a sheet?

Accepted Answer

Give the main flow briefly, then add the quality steps — that is where the difference shows. "The core is three nodes: Webhook → Edit Fields → Google Sheets. On top of that I add four things: 1. Normalisation. Lower-case and trim the email, put the phone number in one format. Otherwise A@X.az and a@x.az look like two different leads. 2. Append or Update Row. I use the upsert instead of a plain Append, with the email as the key column — a double submission leaves one row. 3. Timestamp and source. I add receivedAt and source; you need them later to answer "which campaign produced how many leads?" 4. Webhook authentication. A webhook on the open internet must be protected, or anyone can write junk into the sheet. If the volume grew I would move from a sheet to a database — Google Sheets is good for reporting, not for operational data."

Question 2

In an email-driven workflow, how do you prevent the same message being processed twice?

Accepted Answer

Explain the problem, then the fix. This is the most common problem in email automation. "The problem is that triggers are often at-least-once, and a restart, a retry or a change to the trigger configuration can bring the same message back. The fix has three layers: 1. A state marker. After processing I add a label with the Gmail node, or mark the message read; on the trigger side I pick up only messages without that label. That closes most cases. 2. An idempotency key. I store processed message IDs (in a Data Table or a database) and check before writing. That still works when the labelling step itself fails. 3. Making the write an upsert. The final write is an upsert, so reprocessing updates the same record rather than creating a duplicate. The underlying principle: do not try to prevent repeats, be tolerant of them. Preventing them entirely is not possible, so the system has to be idempotent."

Question 3

When should you move from Google Sheets to a database?

Accepted Answer

Give the criteria, then add a migration strategy. "I look at four signals. 1. Volume. At tens of thousands of rows a sheet both slows down and forces you to pull everything just to read. 2. Concurrent writes. Several workflows writing to the same sheet risks conflicts and lost updates. Databases are built for that; sheets are not. 3. Lookups. "Find the record for this email" means fetching every row and filtering in a sheet; in a database it is an indexed query. 4. Structure. Once you have several related objects — customer, order, payment — the sheet model collapses. n8n also has a middle option: Data Table, which stores structured tabular data inside n8n and solves part of this without standing up an external database. My migration strategy: write to both in parallel first, then move reads to the database, and finally keep the sheet for reporting. Because a sheet's real value is that people can look at it — I do not want to lose that entirely."

Scenario	Node chain	The key nuance
Website form leads into a sheet	Webhook → Edit Fields → Google Sheets (Append or Update Row)	Use the email column as the key so the same person is not written twice
Emailing a daily report	Schedule → Postgres → Convert to File (XLSX) → Gmail (Send)	Do not send when the result is empty — check with an IF
Processing incoming CVs	Gmail Trigger → Extract From File (PDF) → AI → Google Sheets	Add a label after processing so the message is not reprocessed
Emailing based on rows in a sheet	Schedule → Google Sheets (Get Rows) → Filter → Gmail (Send) → Sheets (Update Row)	Mark the row "sent" afterwards — that is what prevents repeats
First-line replies to support email	Gmail Trigger → AI Agent → Gmail (Reply) → Gmail (Add Label)	A human approval before the automatic reply is safer

Automating Google Sheets and Gmail

📚 Sources and documentation