A request from the inbox becomes a row in a table
An email from a customer turns into a row with a name, an address and the gist; newsletters pass by.
What the scenario looks like
- Execute + Data
- Data
- LLM
Requests that arrive by email live in email: to count them, somebody scrolls through a month of correspondence and copies things into a spreadsheet. Doing it on the way in produces something that did not exist before — data about how many requests there are and what they are about.
What is inside
- Scheduled trigger — the entry.
- New messages fetches the unread and marks it read. Unlike the digest, this check changes the mailbox on purpose: the flag is what stops one request being filed twice.
- A request in the email — the model decides whether this is a customer or a newsletter and pulls the fields out at the same time.
- Is this a request? — the branch. Newsletters go to a dead end and do nothing.
- Row for the table builds the document; Write to the table stores it.
One email is parsed per run: | first takes the newest. That keeps the example readable; to
process all of them, put a loop in that place — the shape is in “One summary for every
address”.
What to set up for yourself
- What counts as a request. The prompt lists the exclusions; add your own.
- The fields. Currently name, address, gist. Add a budget or a city and add it to both the schema and the row template.
- The collection on the write node.
What to connect
A mailbox over IMAP, a collection under Tables and the Schedule target. Do not turn off “mark as read” until you have another defence against duplicates.