Triage Coda customer feedback into Linear issues with a daily email

Every weekday at 9am in my local timezone, triage new customer feedback sitting in my Coda feedback tracker, turn the actionable rows into Linear issues, and send me a daily rollup email. The trigger is cron. Coda does not have a first-class poll trigger for us, so cron plus a status column filter is the right pattern, and writing status back to Coda is what keeps this safe to run daily without duplicates.

Step 1. Use Coda List Table Rows to pull rows from my feedback table where the Status column is empty or equals "new". I will paste the doc ID and the table ID during setup, so treat both as required inputs on the workflow. Only fetch rows in that unprocessed state, and ask for the row's customer message, any severity or urgency field, the reporter's name or email if present, and the row ID so we can update it later.

Step 2. For each row, classify the feedback into one of four buckets: bug, feature request, question, or noise. Skip rows classified as noise (spam, thank-yous with no request, off-topic) and skip questions unless the customer is clearly reporting an issue. For anything classified as a bug or feature request, draft a crisp Linear title (short, imperative, no filler) and a description that quotes the customer verbatim in a blockquote, followed by a one line agent summary of what the customer is actually asking for. If the reporter's name or email is available, include it in the description.

Step 3. Call Linear List Teams once at the start of the run and cache the result for the whole run. Pick the right team per issue (default to the first team in the workspace unless I add routing rules later). Then call Linear Create Issue for each actionable row. Set priority based on severity language in the customer's message: words like "blocker", "cannot use", "broken for everyone", "urgent" map to Urgent (1); "important", "major", "frequent" map to High (2); typical requests map to Normal (3); "nice to have", "minor", "cosmetic" map to Low (4). Use "bug" or "feature" as an implicit hint in the title. Capture the resulting issue URL from Linear's response.

Step 4. Use Coda Update Row to write two things back to the source row: the Linear issue URL into a column called "Linear Issue" (or the closest matching URL column), and a Status of either "triaged" (for rows we filed) or "skipped" (for noise). This write-back is critical. Tomorrow's List Table Rows call filters on empty or "new" status, so any row we updated today will not be re-triaged.

Step 5. After all rows are processed, use Gmail Send a Message to email me one digest at my own address. The email should include: the total number of rows scanned, how many were filed as Linear issues, how many were skipped as noise, the new issues grouped by category (bugs, then feature requests) with each item showing the Linear title as a link to the issue URL, and a clearly labeled "needs your eyes" section listing any rows where the agent was not confident about classification or priority, with the raw customer quote and the Coda row link so I can decide. Send only one email per run, even if there is nothing new (in that case, send a short note saying the queue is empty).

Guardrails: never create more than one Linear issue per Coda row; if the Coda update fails for a row, do not create a Linear issue for it on retry (or if the Linear issue is already created, still attempt the Coda write-back with a note so we do not double-file next run); respect Coda and Linear rate limits with small waits between calls; and always send the digest email at the end, even if some rows errored, so I know the run happened.