Forms & tables

Forms and tables are Dailybot's way of capturing and storing structured data inside the platform. Forms are the input: you define questions (text, choice, date, number, etc.), share a link or embed in chat, and collect responses. Tables are the storage: each form submission becomes a row; you can also create tables manually or have automations write to them. Together they are the memory of the system — the place where structured data lives so that Intelligence can summarize it, Automations can trigger on it or update it, and check-ins can reference it. They sit in the Capture step of the loop, alongside check-ins.

Without a shared memory, visibility is ephemeral. Check-in answers disappear into a report; someone fills a Google Form and the data lives in a sheet nobody else sees; automations have nothing to read or write except chat. Tables give the platform a durable layer. Incident reports, onboarding checklists, approval requests, agent run logs — all become rows in tables that the rest of Dailybot can use. When an automation creates a ticket from a check-in, it can also write a row to a "tickets created" table. When Intelligence summarizes the week, it can pull from table history. The loop needs memory; forms and tables are that memory.

For people filling forms, it feels like a short survey — often right in chat or via a link. For leads and ops, it feels like a single place to see what was submitted: open a table, filter, sort, and export. For power users, the link between forms and tables is obvious: create a form, connect it to a table, and every submission auto-appears as a row. Automations can add rows, update rows, or trigger on new rows. In v3, agent activity can be written to tables too — so the same memory holds human and agent data, and the rest of the platform can act on both.

Many tools have forms or databases, but they live outside the coordination loop. In Dailybot, forms and tables are first-class building blocks. They feed Intelligence (summaries and signals can be built on table data). They feed Automations (triggers on new or updated rows; actions that create or update rows). Check-in responses can be copied into tables; automations can create records that trigger other automations. And in v3, tables can store agent outputs — so the memory of the system is unified. You don't need a separate wiki or spreadsheet; the loop's memory lives where the loop runs.

Forms and tables are the Capture-side memory. Check-ins are the other main capture input; both feed Intelligence and Automations. Intelligence reads table data to produce summaries and signals. Automations read and write tables — trigger on a new row, update a row, create a record. Tables can also be used to drive approvals, track incidents, or log agent activity. Kudos don't write to tables (they are recognition, not status); but for everything that needs to be stored, referenced, and acted on, forms and tables are where it lives.