Google Sheets

Some of what a workflow produces has to leave the product. A finance team that works in spreadsheets, a partner who wants a weekly list, a colleague who will not be given a login for one report a month. A sheet is where that lands.

The obvious use is appending: something happened, add a row. That works and it is what most people build. The more useful half of this node is the four operations that match on a value first — because a sheet you can update is a shared record, and a sheet you can only append to is a log that gets stale the moment anything changes.

Those config objects group what the operation needs. spreadsheet_config says which file and where in it. data_config carries what you are writing. match_config is the one that matters for the third group — which column is the key, what value to look for, and what to do when several rows match.

One row per contact, kept current. The contact changes in the CRM and the sheet follows — updating the existing row if the email is already there, adding one if it is not.

Read match_config first. match_column is Email — the header of the column, not a letter. That is the VLOOKUP key, and it is why the sheet's first row has to hold real headers and header_row has to point at it. Get that wrong and every match fails silently, because a key that matches nothing is indistinguishable from a contact you have not seen before.

match_mode is set to case-insensitive here, which for email addresses is the only correct answer — people type their address in whatever case they like and exact would create a duplicate row for each variant. match_position decides what happens when several rows match; first is the safe choice while you are learning, because all will happily rewrite twenty rows.

The values are a stringified two-dimensional array. This is the node's own warning and it is the thing people get wrong on their first attempt. Not an object, not a list of fields — a JSON string containing an array of rows, each row an array of cells, in column order. One row is still an array inside an array.

Set it to RAW for anything that is an identifier rather than a number: phone numbers, references, postcodes, ids, product codes. The workflow above uses RAW for exactly this reason. Use USER_ENTERED deliberately, when you want a date to be a date or a number to be summable — not by default.

A failed match is not an error. Ask update_matching_rows to update a row that is not there and nothing happens, successfully. append_or_update is usually what you meant — it writes the row either way — but if you genuinely want an update-only operation, read {{alias.row_count}} and branch on zero.

Sheets are not a database and this node cannot make them one. Two runs matching on the same key at the same moment will both find the row and both write to it, and there is nothing here to prevent that. For a sheet updated a few times an hour it does not matter. For a high-frequency sync it does, and the answer is to write to your CRM and export on a schedule instead.

The sheet's shape is a contract nobody enforces. Somebody inserts a column on Monday and every write_range built on positions is now writing into the wrong cells — silently, because a range is just coordinates. The match-based operations survive this, since they work from header names. That is the strongest practical argument for using them.