I’ve been building a large-scale doc where each page corresponds to a single item — like a feature, character, or deliverable. But there’s a huge bottleneck I keep running into:
There’s no way to filter a table view based on the current page’s name.
All I want to do is: “[Page Title] = thisPage.Name” …so the table view only shows the relevant row for this page.
But currently:
You can’t use “thisPage.Name” in filters
Dropdown canvas controls break for new row creation
Helper tables often cause circular reference errors
And hardcoding “Page Name” into every filter just doesn’t scale
Please support “thisPage.Name” (or equivalent) in view filters!
This would instantly:
Eliminate fragile workarounds
Make row-level filtering simple and reliable
Unlock scalable per-page systems with no clunky setups
And while we’re dreaming…
It would be amazing if pages could have properties, like Status, Tags, Linked Row, etc. Basically — let us treat pages like Notion-style records, with native metadata. This would power:
Auto-generated dashboards
Smart filters + rollups
Cleaner, integrated tracking systems
I genuinely believe this would unlock the next level of Coda’s potential as a structured creative platform.
Thanks for considering — and for building a great tool
I’m curious, is the information for every single item totally different? So much so that “single source of truth” tables would not have been reasonable to use? I like to run everything from base tables because there is so much I can do with it from there, so a setup that is wildly different would be interesting to see!
But creating a page for each item is just not a sustainable practice.
There are multiple UI workarounds, none of them as convenient as having the items directly on your sidebar, but we all find something we can live with.
Thanks everyone - I’m learning a lot by reading your comments.
I hear what you’re doing sounds like it’s working well, for me if I’d wanted to go down that road I probably would have chosen something like Airtable.
The reason I chose Coda was because it seemed to provide a more hybrid approach (structured thinking - with tables, formulas; narrative writing - with pages, sections; and creative freedom - with layouts, callouts, embedding visuals.
I feel as though Coda promotes the use of pages, but then we’re not quite at the level where this is sustainable because of a lack of things like this page metadata and ability to reference its own pages.
And @Shannon_Bradley - I do use base tables for some things, although the way I’m doing it (not sure if this could be done better!) means that I end up with those incrementing view names every time you use the table. Also, filtering the view of the table is frustrating because I have to hardcode the filter, rather than using “thisPage” or similar!
Ha, was it that obvious? I have only started using it recently. I’ve got >100 pages in my doc now, and that will multiply by 3 or 4 easily. I have been trying to future proof having this many pages by building things out like page “metadata”, but it’s been really hard to make it work.