• 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.