I would debug this as an append-vs-update collision before changing more mappings.
The smallest useful check:
1. Add a Set node immediately before Google Sheets with a fake `source_row_id`, for example `test_a` and `test_b`, plus a timestamp.
2. In the Google Sheets node, confirm the exact operation is append/add row, not update, upsert, or append-or-update.
3. Check whether any row number, matching column, range, or key field is mapped. If a stable row number or the same matching key is being sent for every item, the node will keep targeting the same row.
4. After the Sheets node, log the returned row number / row id if n8n provides it.
5. Run only two fake items. Expected result: two new rows with different `source_row_id` values.
If the second fake item overwrites the first one, the likely cause is not the sheet itself; it is that the workflow is giving both items the same target row or same lookup key.
For a safer workflow, I would keep three fields in the sheet:
- `source_row_id` or `run_item_id`,
- `write_mode` such as `append` or `update`,
- `written_at`.
Then only use update/upsert when `source_row_id` is meant to be unique and stable. If you want an audit log, use plain append and avoid mapping any existing row number.