- QURPLUS
- Posts
- Modules that *might* seem redundant (Add a Row > Search Rows example)
Modules that *might* seem redundant (Add a Row > Search Rows example)
So I’m building an automation that generates content after filling out a form and I see this design pattern:

In this case where Typeform is being used to grab responses, Google Sheets is used as a single source of truth, and we’re using data from Search Rows to set multiple variables.
I start wondering “Why is there a Search Rows module right after the Add a Row module?”…
Here’s what I found out about this…
Add a Row module does not always return full row data reliably.
Even though Typeform has the raw data and even though Add a Row wrote it, Typeform’s structure could change and so Google Sheets serves as a source of truth.
Data might be transformed or enriched in the sheet.
If downstream modules need row IDs, Search Rows can provide that but Add a Row cannot
Ok, that’s all good and well, but here’s the kicker… I made another iteration of this automation where I hot swap Typeform with Google Forms:

Notice that I use neither Search Rows nor Add a Row. I’m just using a google form that is linked to a sheet, so I’m using Watch New Rows as the trigger and I’m using that data to Set Multiple Variables.
So I began thinking; “Why does it work when I do it like this? Should i reconfigure it? When would I want to use a Search Rows module?…
Here’s what I found…
Watch New Rows actually returns real data in full, so in this iteration there’s no need to go fetch them again.
I’m not using Typeform, so my structure remains consistent - no risk of API structure changes like could occur when using Typeform.
When to use Search Rows: you only need to add a Search Rows module after the trigger if something else inserts the row (such as a Typeform). In my iteration, the trigger is watching the sheet directly so I don’t need to re-grab anything.