Lookup Columns & Cross-Table References

A Relation column stores a reference to a row in another table — not a copied text string. To set one up: click a column header → change type to Relation → choose the target table. The cell shows the target row's display column as a clickable pill. Why this matters: rename the target row once, and that name updates everywhere the relation is used. No stale copies, no manual find-and-replace.

Once a Relation column exists, pull any field from the related row using dot notation. These are "virtual" derived columns — they compute from the relation automatically and update whenever the source row changes.

You can chain any column from the related row: thisRow.[Project].[Due Date], thisRow.[Project].[Status], and so on. Each lookup column is read-only — to change the value, edit the source row in the related table.

Sections 01–02 looked up data from child to parent (Task → Project). Now flip it: from the Projects table, get all tasks that belong to each project using a filter on the Tasks table, then chain aggregate functions.

Tasks.Filter([Project] = thisRow)

From there, chain additional operations to produce the numbers your dashboard needs:

// Task count per project
Tasks.Filter([Project] = thisRow).Count()

// Total estimated hours
Tasks.Filter([Project] = thisRow).Sum([Estimate])

// Completed task count
Tasks.Filter([Project] = thisRow).Filter([Done] = true).Count()

// Overdue open tasks
Tasks.Filter([Project] = thisRow)
     .Filter([Done] = false)
     .Filter([Due Date] < Today())
     .Count()

When you set up a Relation column in Tasks pointing at Projects, Coda automatically creates a corresponding linked relation column in Projects. No formula needed — Coda maintains both directions. Edit a task's project in either table and both stay in sync.

This enables bidirectional navigation: from a project row you can see and open all its tasks; from a task row you can navigate directly to its project. No formula column required for either direction.

A Subtable block shows related rows as an inline editable mini-table inside a canvas column or a row's expanded detail view. Add a Subtable → choose the relation column → related rows appear. Best for viewing a task list inside a project detail view without leaving the row.

The most common mistake: writing thisRow.[Project].[Owner] in a table where Project is a plain Text column. You can't "dot into" a string. The formula will error. Fix: open the column settings, change type to Relation → Projects, then the lookup works.

Full CRM example: a Contacts table with a Company Relation column pointing at a Companies table. Derived columns pull Company data through automatically.