Skip to content

Lemma · Tables

The list your whole team keeps current.

Deals, follow-ups, customer files: one row each, in a real table. Your teammate updates rows as it works; your people see them as a board or a checklist and tick them off.

Deals
Remy's deals table shown as a board grouped by stage, each card with its owner and value.

Remy’s deals, piled by stage.

What a table is

One row for each thing the work is about.

Each deal, follow-up or customer file gets a row, and each fact a column. What your teammate learns lands in a row, where the next question, page or workflow finds it. You don’t design it: say what to track, and it sets up the columns.

One sentence in, a table out.

Views that choose themselves

Stages become a board. Due dates become a checklist.

The table reads its own values and draws the view that fits, then says why. Show as table is always one click away.

Due dates and done boxes: a checklist.

  • BoardRepeating stages, a name on every row.
  • ChecklistDue dates and done boxes, soonest first.
  • TimelineNamed things that already happened.
  • ChartOnly dates and numbers.
  • Reading viewLong writing a cell would cut off.
  • GridEverything else, and any very large table.

Kept current

Whoever hears the news moves the row.

Saltbox signs. Priya tells your teammate in Slack, and it moves the deal to Won with Priya’s access and no more. Or she changes the stage herself in two clicks.

One message, and the deal moves to Won.

  • Move itEach card’s stage is a picker; a refused change bounces back with the reason.
  • Tick itDone boxes are real. Ticked rows sink; late ones get flagged.
  • Edit itForms are built from the columns and checked before saving.

Each person, their rows

Everyone sees their own rows, and Postgres enforces it.

Give rows an owner and row-level security does the rest: Priya and Aditi open the same Follow Ups and each sees theirs. When Priya asks in Slack, your teammate reads the table as Priya.

Same table, two people, two lists.

Ask the table

Ask a question, get rows back.

Every table has its own chat. Ask which open deals are over 10,000 and your teammate runs one read-only query, then answers with the rows, the total and the query itself, so you can check it.

45,500 across three deals, query shown.

Rows start work

A new row can start a workflow.

A customer file added to imports starts the First import check on its own. Any table can trigger work: on every new row, or only when a deal’s stage changes to Won.

A row added in imports starts the check.

How it starts: a row added in imports, on for everyone; beside it the runs, one waiting on Dev at Dev approves the fix.

Underneath

Real Postgres, shared by pages, apps and Claude.

The same rows, under the same access rules, wherever they’re read.

The interviews table, inside a page.

A table view inside a page listing five interviews by company, role, theme and excerpt.
  • Typed columnsText, numbers, dates, choices, people and links; required or unique.
  • Read-only SQLJoins and totals, run as you, never past row security.
  • Every row has a pageWith links both ways, kept for you.
  • In pages and appsPages show the same rows; apps read and write them.
  • From Claude or ChatGPTQuery and write rows over MCP, as you.
  • From a spreadsheetLoad a CSV with the Lemma CLI. No formulas.

The rest of its space

Every part of the job, in one place.

What lives in a sheet nobody trusts?

Say what to track. Your teammate sets up the table and keeps it current.