Accessible via: Main Menu -> Database

A table is structured data — rows and columns — that Sammy and your workflows can read, filter, and update. Use it for anything you’d otherwise track in a spreadsheet: leads, properties, tasks, inspections, inventory.

Tables are the difference between an automation that starts from nothing every run and one that carries state: a workflow can write what it did into a table, and the next run can read it back.

Tables hold your structured records. For documents you want Sammy to answer from — policies, contracts, SOPs — use a knowledge base instead. A table is queried; a knowledge base is searched.

Creating a table

1. Open Database in the left rail.
2. Click New table.
3. Name it and define its columns.

Each column has a type: text, numeric, boolean, timestamp, or JSON. A column can also be a reference to another table, which links the two records together so a row can point at a row elsewhere.

Columns can be marked unique, and the schema can be modified in place after creation — add, rename, retype, or drop a column on an existing table without rebuilding it.

Linking columns to the data dictionary

A column can be linked to a data-dictionary field. Do this where the data also appears on forms: it means your forms, agents, and tables all use the same canonical name for the same thing, so nothing has to be mapped by hand later.

Working with the data

Pick a table in the column to open its data view: browse rows, sort, filter, and edit inline. Rows can be added and edited by hand, but the point of a table is that Sammy and your workflows do it for you.

Using tables from workflows and agents

• Workflows can read from and write to tables as steps, so an automation can look something up, act, and record the result.
• Agents pointed at a table answer from your live data rather than a stale export.
• Scheduled workflows turn a table into recurring work — read the rows due today, act on each one, write back what happened.

From the CLI

Tables can be created and queried from the command line, which is the easiest way to script bulk changes or seed a table from an existing file. See CLI › Tables.

A table can also be defined in YAML and deployed, in which case its live schema is reconciled against the file — columns and constraints are brought into line on every deploy, not just created once. Changes that would destroy data (dropping a column, say) fail the deploy unless you explicitly pass --allow-destructive, so an unattended CI/CD run can’t quietly drop a column. Use --dry-run to see the pending schema change first. See CLI › Deploy.