Tables

A Table is your workspace database in your own shape — not the platform’s fixed lead/company schema, but the columns you actually need (roof area, deal stage, “uses SAP?”), with no code deploy per customer.

Bound and standalone tables

A table can be bound to existing leads/companies: every row points at a real lead or company, and the table extends that record with your own columns without touching the core schema. A table can also be standalone — an imported phone list, say, that never becomes leads. Both are equally valid; the binding only decides whether a row additionally exists as a lead/company.

System fields of bound records appear as virtual columns in the table — you see and filter them like any other column, but changes run through the existing lead/company paths, never stored twice.

The Database area

Tables live in the “Database” navigation area — that’s where bulk work happens. There is no second lead list beside it: case-by-case work happens on the Deal, bulk work in tables.

Import with a structure proposal

1. Upload — CSV/XLSX, up to 50,000 rows per file (larger files are split automatically).
2. Agent proposes a structure — column names, types, mapping to existing lead/company fields where unambiguous, own columns for the rest, and a dedupe key (email or domain, for example). A proposal only, with no effect yet.
3. Approval by a workspace administrator — you rename, change types, remove columns before anything is created.
4. Import runs as a Run: table, columns and rows come into being; bound rows link to or create leads/companies through the existing creation paths.

Every imported value is then a Cell carrying its file origin — filterable and sortable immediately, with no deploy.