Using Space Build
Tables
Simple spreadsheet-like lists of records that people, automations and agents all share.
A table is a tidy list of records, a bit like a spreadsheet or Airtable: customers, leads, tasks, orders. People edit it in a grid, and agents and automations read and write it too.
Why use a table
- A shared source of truth that people and agents both update.
- A way to trigger things: “when a deal becomes Won, send the welcome pack”.
- Structured memory for agents: a leads list they can read and add to.
Creating a table
Open Explore › Tables and create one, or ask the copilot: “Make a table of sales leads with company, contact email, stage and value.” You confirm before it's created.
Column types
| Type | For |
|---|---|
| Text and Long text | Names, notes |
| Number | Amounts, quantities (1,200.50 is fine) |
| Yes/No | Flags |
| Date and Date and time | When things happen |
| Select | One choice from a list you define, such as Stage |
| Email and URL | Addresses and links, shown clickable |
Every value is checked as it goes in, whoever or whatever adds it. You can mark a column required. Changing a column's type converts existing values, and is refused (with the number of rows that can't convert) if some can't.
Editing
The table opens as a grid. Click a cell to edit, add rows at the bottom. An empty cell is simply empty, and means the same thing everywhere.
Who can do what
Each table has levels of access:
| Level | May |
|---|---|
| None | Nothing. The table doesn't even appear. |
| View | Read rows. |
| Edit | Add, change and delete rows. |
| Manage | Change columns, settings and permissions. |
A table's owner gets Manage. Everyone else gets the table's default access, which you can set to None, View or Edit. You can also grant a specific person or group a level, and the most specific rule wins, so you can shut one person out of an organization-wide table or let one group edit it.
| Table scope | Who manages it |
|---|---|
| Personal | You. Nobody else sees it until you share. |
| Group | The group's admins. Members get the default access. |
| Organization | Org Admins. Everyone gets the default access. |
Agents and tables
An agent's access to a table never exceeds the person it works for. On an agent's Resources tab you can choose specific tables and make some read-only. Under Permissions › Check with me before › Tables, you can make it ask before it changes any row.
Work for someone else's request (like a Front Desk answering a colleague) gets only tables you've picked explicitly, and only read-only.
Triggers: act when data changes
On the table's Triggers tab, set something to start automatically when:
- a row is added,
- a row really changes (saving the same values doesn't count), or
- a row is deleted.
You can narrow it: “only when Stage becomes Won”. This fires when a deal becomes Won, not on every later edit of a won deal. It can run an instruction, a playbook or an agent.
Triggers fire for changes from anyone: the grid, an agent, a chat, an automation. They never trigger themselves in a loop. A chain of automations stops after five.
In playbooks
A Table step can query, insert, update or delete rows with the access of whoever runs the playbook, and a Wait step can pause until a row matching your conditions appears. See Playbook steps.
Good to know
- Changes need confirming. Creating or changing tables through chat always asks you first, so unattended automations can work with rows but not change a table's design.
- Row edits aren't individually logged, but each row records who created and last changed it, and agents' work shows in their logs. Schema and permission changes are in the audit log.