The not found branch is the whole thing. Ours went silent for a week.
Use the find row step. It searches a sheet for a value from the conversation and brings the matching row back into the flow, so later steps can use those fields in messages and conditions.
This is the cheapest lookup you can build, and it is enough for a surprising number of real cases: order status by reference, class schedule by location, stock by size, price by plan name. A spreadsheet your operations team already maintains becomes the source of truth without anyone building an integration.
The pattern:
- Collect the lookup key in the conversation, for example an order reference.
- Find row with that value.
- Condition on whether a row came back.
- Reply using the row's fields, or handle the not found case properly.
That fourth point is where these flows fail in production. A typo means no row, and a flow that only handles the happy path goes silent exactly when the person is most frustrated. Always build the not found branch, and make it offer a human rather than asking them to try again.
There are also add row and update row steps, which make the sheet a lightweight log: every qualified lead as a line, updated when they convert.
For anything with real volume or real concurrency, a spreadsheet is the wrong store and an HTTP request to your own endpoint is the right one. But do not over-build before you need to.
2 คำตอบ
We use add row as a lead log and it replaced a whole tool.
เข้าสู่ระบบเพื่อตอบและบันทึกฉบับร่างของคุณ