A data table is a small, structured store that belongs to your tenant: columns you define, rows you fill, and a flow that can read and change them while a conversation is running. An agent can look an order up by its number, check whether a customer has opted in to messages, and write back what it decided, without an integration behind it.
What it is good for
The case that fits best is a small reference list the conversation needs to consult, and one you would otherwise have no home for: order records for a demo or a pilot, opening hours per branch, a list of promotion codes, per-customer contact preferences. The flow reads a row, decides something, and carries on.
The second case is recording what the flow already knows. A conversation that cancels an order can write the new status straight back to the row it read, so nobody re-keys it afterwards.
What it is not
This is the part worth being straight about, because a data table looks like a database and is not one.
- It is not your business database. The ceilings are deliberately small: 20 tables in a tenant, 50,000 rows in a table, 25 MB per table and 100 MB across the whole tenant. That is enough for reference data and for what a conversation records. It is not enough for a customer master, a transaction log, or anything that grows with your traffic.
- It cannot join. One operation reads or writes exactly one table. There is no way to match rows across two tables, and no relationships between them, so a design that needs a customer table and an order table to meet in one query does not belong here.
- It is not built for reporting. Only the columns you mark as Fast filter are indexed, at most five per table, alongside the row's creation date. Anything else is a scan. If the question is analytical, the Conversations pages and the export are the place for it.
- It is not a system of record. Deleting a row is permanent, there is no restore from these screens, and automatic row deletion will remove rows on a schedule once you switch it on. Anything you would be sorry to lose belongs in the system that owns it.
- It is not an integration. If the data already lives in a CRM or an order system, call that system with an HTTP node rather than copying it here. A copy is stale from the moment it is made, and keeping the two in step becomes your problem.
A short way to decide: if the data is small, changes rarely, and no other system owns it, a data table is the right home. If another system owns it, call that system instead.
Where the feature lives
Data Tables is a tenant-level module, not a project one, so a table you create is available to every project in the tenant and the module has to be enabled for the tenant before the menu appears at all. Tables are managed from the Data Tables entry in the main navigation, and a flow reaches them through the Data Table node in the designer.
Limits
These apply wherever the table is used, from the admin screens and from a flow alike.
| Item | Value |
|---|---|
| Data tables per tenant | 20 |
| Columns per table | 20, at least 1 required |
| Fast filter columns per table | 5 |
| Rows per table | 50,000 |
| Storage per table | 25 MB |
| Storage per tenant, all tables together | 100 MB |
| Text value | Up to 200 characters |
| Long Text value | Up to 8,000 characters |
These are the maximum values, and a tenant can be configured with lower row and storage limits, so check what your own tenant reports if a table stops accepting rows earlier than this suggests. Two places show where you stand: the Data Tables list carries a Total Rows column per table and a Data Tables Storage bar for the tenant, and a table's row grid shows its own count in the footer.
Next
- Creating a Data Table: defining columns and their types, the two ways to create a table, what you can change afterwards, and automatic row deletion.
- Managing Data Table Rows: adding, editing and deleting rows by hand, and exporting to CSV.
- Using the Data Table Node in a Flow: reading and writing rows from a conversation, the five operations and the three output ports.