Linked columns: showing a field from a related table

Show a field that lives on a related table as a column of one view — Company → Region, Supplier → Lead time — without adding anything to the table's schema. The display half of filtering by a linked field: if you can narrow a view by a route, you can now see it too. Add one Open Columns in the view toolbar and choose Add linked column. A picker opens on the table you’re looking at: click a relationship to step across it, keep clicking to go further, and tap a field to finish. You can also pick the linked record’s own name rather than a field on it. It’s the same picker, on the same routes, that the filter bar uses for Filter by a linked field — deliberately, because they answer two halves of one question. There’s no route syntax to learn and nothing to type. The column appears immediately, headed with the route it came from (Company → Region). Rename it from the column’s own menu: a route reads long in a narrow heading, and once the column is on screen you usually just want it called Region. It belongs to the view, not to the table This is the whole point of the feature, and the thing to be clear about before you reach for it. A Lookup field is a schema decision. Once it exists, it exists for everyone: in every view, in the REST API, in exports, in reports, and to formulas. That’s why creating one is an admin act. A linked column is one view’s lens. Nothing is added to the table, no migration runs, and nobody else’s screen changes — so any member can add one to a personal view and answer their own question without asking for a schema change. On a shared view it’s a view edit like hiding or freezing a column, so it takes the same permission. Reach for a Lookup when the route belongs to the table — when formulas should read it, the API should return it, or everyone needs it. Reach for a linked column when you need to see something while you work. When the link reaches several records Some routes land on one record — a deal's company. Others land on many: a customer's orders, a company's contacts, a deal's activities. A linked column never turns one row into several; a row is a record, and it stays one. Instead it asks what you want from the many, as soon as the picker notices the route fans out. • List them — the values, comma-separated, de-duplicated. Good when the names are the answer. Up to 25 show before the rest become a count. • Count — how many records the route reaches. Usually the right answer, which is why it's the default. • Sum, Average, Min, Max — offered when the field at the end is a number. A column that counts or totals is a rollup, and behaves like one: right-aligned, showing 0 rather than a dash when nothing is linked, because 0 is the answer. Only counting some of them Under Only include where you can narrow which linked records are counted or totalled — “the orders that are posted”, “the deals that are Closed Won”. Add as many conditions as you need; all of them must match. The field you test can live on the linked record itself, or one step further along. The picker lists both: Stage is a field on the order, Company → Tier travels from the order to its company and tests the tier there. That second kind is what lets the thing you're filtering on stay where it belongs — you don't have to copy a country, a type or a tier onto every child record just to make the filter possible. So “the total value of this customer's orders, only the posted ones, and only where the contact is in the US” is one column, not a schema redesign. Seeing the records behind a number Click any rolled-up number in the grid — a linked column that counts or totals, or an ordinary Rollup field — and the records it was made from open in a list, each showing what it contributed. Click one to open it; Back returns to the list. If the number only counts some records, you get exactly those, because it's the same working-out that produced the number rather than a fresh guess at it. The list is also current: a record that has changed since the page loaded shows as it is now. What it can and can’t do A linked column is a Lookup that nobody chose to keep, so most of the grid treats it as exactly that: • Resize, freeze, reorder, hide — all work normally. • CSV export includes it, under whatever you named it. • Public share links publish it, so a link can carry context from a table the reader never sees. • Permissions are enforced on the route, at every hop and at the far end — see Permissions travel with the route. Three things it deliberately does not do, all for the same reason: the value isn’t stored anywhere, it’s worked out per row as the page loads. • You can’t sort by it, and it isn’t offered in the sort menu — there’s nothing in the database to order on. • You can’t total it in the summary row. • You can’t filter on it from the column menu. Use Filter by a linked field in the filter bar instead, which travels the same route and is fully supported; the column menu points you there. If you find yourself needing to sort or total one, that’s the signal the route belongs to the table: add a Lookup or Rollup field and you get all three. Permissions travel with the route A linked column can’t become a way around a permission. When you add one, RowFold checks that you may travel every hop and read the field at the end; if you can’t, it says so rather than adding a column that would sit permanently blank. The check is applied again when the view is read, per person — which matters, because a route saved on a shared view is travelled by everyone who opens it, not just whoever added it. A colleague who can’t see the far-end field sees an empty cell there, not somebody else’s data. Limits, and what happens when things change • Eight per view. Each one is a real lookup for every row on screen, so this is a genuine cost ceiling rather than tidiness — and a grid needing twelve of them is really a report, which RowFold already has. • Up to five hops, the same depth limit lookups and rollups use. • Removing one takes it out of the column order too, so the freeze boundary stays where you put it. • If the relationship or the far-end field is deleted, the column stops resolving and can simply be removed — nothing else in the view is affected, because nothing depended on it. Tips • Rename a linked column as soon as you add it. The default heading is the whole route (“Company → Region”), which is honest but wide; once it’s on screen beside its records, “Region” is usually enough. • Add one to a personal view to answer a question without changing anything for your team — it’s the fastest way to check a hunch about related data. • Adding a linked column and filtering by the same route are two halves of one job: add the column to see the value, then use “Filter by a linked field” to narrow by it. Good to know • A linked column can’t be sorted or filtered from its own column menu, because its value isn’t stored — it’s computed per row as the page loads. Filter the same route from the filter bar. (It can carry its own total when the route reaches several records; what it can’t do is appear in the grid’s summary row.) • It doesn’t appear in the REST API, in formulas, or in reports — those read the table’s schema, and a linked column isn’t in it. That’s the trade for needing no migration. • Eight per view is the ceiling. If you’re hitting it, the route probably belongs to the table as a Lookup field, or the question belongs in a report. Who can do what • On a shared view, adding, renaming or removing a linked column is a view edit and takes the same permission as hiding or freezing a column. On a personal view, it’s yours. • You can only add a route you are allowed to travel: every relationship on the way, and the field at the end. A refusal names the problem rather than adding a blank column. • The same check runs per person when the view is read, so a shared view never shows anyone a field their permissions hide.