Please support thisPage.Name in view filters, and introduction of Page Properties!

Hey amazing Coda team + fellow makers :waving_hand:

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:

:hammer_and_wrench: 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

:folded_hands: 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

:seedling: 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 :slightly_smiling_face:

1 Like

Everything you wish for can already be achieved if you use rows of a table with a name and a canvas column instead of pages :wink:

1 Like

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!

Hi Danae,

I owuld like to strongly support @Pablo_DV suggestion of using canvas columns in a table, It is vastly superior than trying to use pages.

P

1 Like

Yes but then you can’t use the sidebar to view pages and subpages.

But then how do you create a user friendly outline and navigation bar? If you use a workaround to create one in the canvas, you lose precious space.

Yes, that is the main downside of this approach.

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!

Coda also promotes the use of canvas columns, compose columns and many other things.

How long have you been using Coda?

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.