Tables

Tables store structured Project data that Agents and Workflows can read and maintain. Use a Table when information is naturally row-and-column shaped and needs to be reused consistently, such as product mappings, routing rules, supplier reference data or maintained working data.

People who can access the Project can read Tables. Project Builders and Owners can create and change Tables and their records; Operators get a read-focused view and can still filter, search and export data.

The Tables surface

The Tables view is the Project-level inventory. Each card shows the table name, description and current record count, with controls to open the table or manage it further.

The Tables inventory with search, label filtering, sorting, view controls and Create Table.

At list level you can search by table name, filter by labels, sort the inventory and switch between grid and list views. Create Table offers three starting points: import data from CSV, Excel or JSON; use a template; or start from scratch.

Some Projects with already-synchronised data can also show a Syncs control. Do not use staff-only ERP controls as a model for the standard customer surface.

Work inside a Table

Opening a Table takes you to its record grid. Builders can add and change rows and fields, create views, import data and configure the Table. The toolbar also includes record filters, search, row density, column visibility and export.

An opened Table showing the record grid, New row action, filters, search, views, import, export and column controls.

The primary action uses the Table's record type, so it may read New weekly plan row, New supplier row or another domain-specific label rather than simply New record.

Operators see a reduced version of the opened Table: they can filter and search, adjust display density and visible columns, and export the data, but they cannot create records, import data or change the schema. A Table can also be configured to restrict manual editing, so even a Builder may be unable to edit cells directly when that protection is enabled.

Use a board view

A Table can also be shown as a Kanban-style board when the records represent work moving through categories or states. Switch from the grid to Board, then choose a text, single-select, yes/no or person field to group the records into lanes.

A current Board view in a synthetic demo Table, with work orders grouped into lanes.

Each record becomes a card in the lane for its current grouped value. Dragging a card to another lane updates that field on the record, so the board is another way to work with the same Table rather than a separate copy of the data.

You can choose which field is used as the card title and which additional fields appear on the card. Board controls also let you sort cards, reorder lanes and hide empty lanes.

When to use a Table

Prefer a Table over a document when:

• values belong in defined fields;

• rows need to be updated independently;

• the Agent or a Workflow should query or write specific records;

• the data is a maintained mapping or working dataset rather than prose reference material.

Prefer the underlying business system when it is the authoritative system of record.

Design Tables for operational use

Give Tables and fields names that explain their operational meaning. Keep mappings narrow enough that a builder can tell who maintains them and what a row represents.

A Table that nobody can distinguish from an ERP export or a one-off spreadsheet quickly becomes another ambiguous source of truth.