> For the complete documentation index, see [llms.txt](https://guide.tiledesk.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guide.tiledesk.com/ai-chatbots-and-automation/actions-explained/data-tables.md). # Data Tables ## Introduction

Data Tables is a Tiledesk feature (currently in BETA) that lets you create simple, structured tables of data directly inside the Tiledesk Design Studio and use them as a lightweight database for your chatbot flows. Each table is made up of typed columns and rows, similar to a spreadsheet, and can be read from and written to while a conversation is running. Data Tables are designed for use cases where a bot needs to persist or look up small amounts of structured information without connecting to an external database — for example, storing user registrations collected during a conversation, checking whether an email already exists before creating a new record, keeping a simple FAQ or product catalog, or maintaining counters and flags across sessions. ### What Data Tables are used for * Storing information collected from users during a chat (e.g. name, email, preferences) so it can be reused in later steps or later conversations. * Looking up existing records before creating new ones, to avoid duplicates (e.g. “does this user already exist?”). * Maintaining simple reference data for the bot to consult, such as product lists, FAQs, or configuration values. * Feeding retrieved values back into the flow (messages, conditions, AI prompts) using flow variables. ## Creating and managing Data Tables from the Console Data Tables are created and managed from the “Data Tables (BETA)” section of the Tiledesk console, accessible from the same workspace where your Flows and AI agents live. ### Creating a table To create a new table: 1. Open the Data Tables (BETA) section and click Create table in the left-hand “YOUR TABLES” panel. 2. In the Create table dialog, enter a Name for the table (e.g. “Users”). 3. Define the table’s Columns. For each column, set a Name and a Type. Supported column types are: string, number, boolean, and datetime. 4. Use Add column to add further columns, or the × icon to remove one. 5. Click the confirmation button to save and create the table.

**Note**: Column types are enforced when data is inserted or updated, so choose the type that matches the data you plan to store (e.g. number for counters, boolean for flags, datetime for timestamps). ### Browsing and editing table data Once created, a table appears in the “YOUR TABLES” list on the left. Selecting it opens a spreadsheet-like grid view showing all rows and columns, with the following controls available: * Add Row — manually inserts a new empty row that you can fill in directly in the grid. * Add Column — adds a new column to the table, with its own name and type. * Search — a search box in the top-right filters rows matching the entered text. * Row deletion — each row has a trash-can icon to delete it individually. * Refresh and row counter — a refresh icon and a “Total number of rows: X / 200” counter are shown above the grid.

### Storage limit There is an overall storage cap of a single Data Table. Its size cannot exceed 30 MB. This limit applies to the combined size of all rows and columns in the table, so it is worth keeping column content (especially long strings) reasonably compact, particularly for tables that are expected to grow toward the maximum row count. ## Using Data Tables in a Flow Inside the Design Studio flow editor, Data Tables are accessed through the Data Table (BETA) block, found under the “Most used” / block category panel (the grid icon). Dragging this block into a flow lets you perform CRUD-style operations against one of your tables as part of the conversation logic. ### The Data Table block Each Data Table block is configured with the following fields: * Data table — a dropdown to select which table the block should operate on (e.g. “Users”). * Operation — the action to perform on the table. Available operations are: Get, Insert, Update, Upsert, and Delete. * Match conditions (Get, Update, Upsert, Delete) — one or more conditions used to filter/find rows, each defined by a Column, an Operator (e.g. Equal), and a Value. Multiple conditions can be combined with all (AND) or any (OR) logic, and further conditions can be added with Add condition. * Assign result to — the name of the flow variable that will receive the operation’s result (e.g. data\_table\_result). * Assign error to — the name of the flow variable that will receive error details if the operation fails (e.g. error).

Every block exposes two outgoing paths, shown on the right edge of the block: * Success — followed when the operation completes successfully. * else — followed when the operation fails or no matching row is found. ### Available operations


Operation	Purpose
Get	Retrieves one or more rows from the table that match the specified Match conditions. Typical use: check whether a record (e.g. a user by name or email) already exists.
Insert	Adds a new row to the table with the specified column values, without checking for existing matches.
Update	Modifies the column values of existing rows that match the given Match conditions.
Upsert	Updates the matching row if one exists, or inserts a new row if no match is found — useful for “create or update” logic in a single step.
Delete	Removes the rows that match the given Match conditions.

### Example: looking up and inserting users A common pattern combines a Get block with an Insert block to avoid creating duplicate records. For example, a flow can:

1. Use a Data Table block with Operation = Get on the Users table, matching the Name column (Equal) against a value such as the visitor’s name, and store the result in data\_table\_result. 2. On the Success path, send a confirmation message such as “User found!” (optionally offering follow-up actions). 3. In parallel or as a fallback, use a second Data Table block with Operation = Insert on the same table to add a new row (e.g. via an “Add User” button in the chat), storing the outcome in the same or a different result variable. 4. On the Insert block’s Success path, send a confirmation message such as “User added!” to let the visitor know the record was created. In both cases, the else path can be connected to an error-handling message, letting the bot gracefully inform the user (or an agent) that the lookup or insert did not succeed. ### Using the results in the flow The value(s) assigned via “Assign result to” become a flow variable that can be reused anywhere later in the flow — for example, inserted into a message with curly-brace syntax, used inside a condition block, or passed to an AI/agent block as context. Likewise, the “Assign error to” variable can be inspected on the else path to branch the conversation based on the specific failure. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://guide.tiledesk.com/ai-chatbots-and-automation/actions-explained/data-tables.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.