Columns

A Column is a typed action that runs on every row of a table — not just a label. Creating a new column is a data entry, not a migration.

Column kinds

Kind	What it does
manual	Editable by hand only
source	Mapped from an import
formula	Computed from other cells, at no cost
ai	A prompt against a model, with typed output
tool	Calls an integration through its category
enrichment	Enrichment/validation via an integration category, waterfall included (below)
relation	Reference to a row in another table
system	Passed-through field of a bound lead/company, read-only

The domino rule

Every column can carry a condition (“only if ICP score ≥ 60”, “only if email is empty”). Rows that don’t meet it skip the column automatically — a row scoring 45 produces nothing for the enrichment and sending columns behind it. Your process emerges from configuration, not from program code.

Waterfall on enrichment columns

An enrichment column can list several providers of the same category in order: the next provider only runs if the previous one delivered no acceptable result (an email that fails validation, for example). Every attempt stays traceable in the cell (provider, result, cost); only the attempt that actually delivered is charged. The order is adapter-agnostic — it references categories, never a specific vendor; a default order applies per category in the workspace, with a per-column override.

Reuse: templates

Proven column chains (prompt, output schema, conditions) are available as templates — the standard enrichment, for instance: research → ICP score → email → email status → copy → send. You instantiate a template through Command or the web app; every row still generates individually, a template does not replace the actual generating.

See also: Cells for what each column execution leaves behind per row.