Manipulate Pages/Sections like Rows

I want to be able to manipulate pages as though they are rows

Long story short: Let me make a column type called Page that is built out of the contents of a single Row, let me edit it with the flexibility of a regular Page, but the structure of Table Detail view, let me use thisPage to access columns in its row, and let it inherit its formats from the columns themselves.

Rows are great because I can:

  • Create new ones with buttons
  • Update them with buttons
  • Sort them with filters
  • Format them with conditions
  • Nest other tables inside them
  • Link other tables/rows to them
  • View them in various states (hiding columns, etc.)

I want to do all of these things with Pages as well.

There are a range of requests out there with a common thread related to this proposal. Here are some of them in a single list:

I think there’s a way in which all of these can be addressed by a single, simple interface. There are some things I would like to do that this would enable:

  • I could dynamically generate documents (press a button to populate a page with information)
  • I could dynamically generate presentations (someone fills out a survey, their information builds a presentation that determines which Coda sections I show to them, in what order, and with what information)
  • I could reuse the same structure of a document in multiple places (the much asked for “template” feature)
  • I could build a wiki that simultaneously merges table structure and page structure

The way I would want to interface with this is as a new column type called a Page (or Page Template or Page View or Dynamic Page or Larry Page, not too concerned with the name rn).

Rather than a Select List or a Lookup type column, a Page type column lets you build a Page out of the contents of your current Row. By selecting Page type you turn each cell in your column into something that looks a lot like a normal Text type column, however this one can be built much like the Customize layout feature of Detail view:

Unlike the current Customize layout feature, however, in the Page cell it looks like you are editing a normal Coda page, with the familiar formatting options, table views, etc. The only addition is that you can access the content of the current row with formulas like thisPage (because technically, your page is a row! #namespacesforfree)

You can’t create new tables in this view, only reference existing ones. This isn’t a true page, just a fancy way to view a row. Just like with the detail view of a table, you are able to edit the contents of the fields in the row. So if I have a field called, “How are you feeling today?” I should be able to see that and edit its contents and input my own, “I’m great!”.

You are able to show views of tables, too. Right now, duplicating multiple views of tables is quite an ugly experience. I now have a View of Sentiment Tracker 3 12 in one of my Weekly Meeting docs. That’s ugly. Instead, this would let me select a table to view, then apply a filter to the table. If I only wanted to show the sentiments related to this meeting date, it might be something like Filter: thisRow.[Meeting Date] == thisPage.[Meeting Date] where thisRow is talking about the row in the Sentiments table and thisPage is talking about the row related to this Page in the Table where this Page type column is held.

Calling Activate on the Page type Column opens it like a regular Coda Page, creating a temporary page associated with it in the sidebar, optionally it can be saved so that it remains after switching to another Page. There are options to automatically create a new page whenever a new row is added to the Page’s source table. These types of pages will be a bit different from standard pages. They will be somewhere between the Play and Edit type permissions, where source content can be changed (you can click buttons, edit text, and check boxes with permanent effects) but the structure cannot be changed (you can’t move a table below another table, because doing so changes the structure of the Page, which would affect all the pages in that column). If you want to edit the page you have to hit the Edit Page button under the three dots

or hit the edit page button under Page Options.

I believe this would be more flexible than the current Detail view too, so your Detail Layout options would also list any Page columns you might have:

so you can render them inside the bounds of the current Detail view.

Text formatting can be inherited from the column format itself. So if your page has, thisPage.[Customer Name] in it, you can edit the formatting on the Customer Name column and it will automatically update the Page formatting.

This is all fitting a bit too well. Was this the plan all along?

To try a Shishir / Matt eigenquestion (Right Click > Add to Dictionary): Is Coda only a tool to manipulate Tables inside Pages, or also Pages inside Tables?

To reveal my bias: the former is COBOL, the latter is lisp.


Let me know if images would help make this clearer

I agree this would be very useful feature! Right now Coda dosen’t seem work very well for generating lots and lots of meeting notes etc. as you can’t organize them like a database.

The ability to have pages nested in tables is really the only reason keeping me from switching from Notion to Coda.


Huge agreement from me. The challenges inherent in using Coda as a tool for note-taking have driven me all over the place in search of a good solution. I have tried, at this point:

  1. Using the rich text editor available in text fields (whole experience collapses if you need something from somewhere else in the doc while writing a note)
  2. A semi-integration with Dropbox Paper; basically you create a “Note” record in Coda (“New Note” button), then open Dropbox Paper, copy the URL, come back to your Note record, paste in URL in URL field, which actives a “View Note” button that opens the URL. This…actually works pretty well, although obviously hinders search.
  3. A Zapier integration with Evernote. Just too tricky to make work right.
  4. Using sub-pages with a “Note Template” sub-page favorited that has several tables on it that allow the note to be associated with a note record, as well as a meeting, or a project, or whatever. This works VERY well, except it’s impossible to keep organized, and it takes me about 30 seconds to set up the note.
  5. Constant flirtation with other systems that do a much better job of this (Notion, obviously; can’t ever stick with it because it is so limited otherwise), and other systems that do a slightly better job (Fibery, Zenkit) of simply displaying a rich text field in a table.

Please please please, this would make Coda the world destroyer. At least for me :D.


This particular post of yours I think highlights how useful this functionality could be in Coda, where I have found it challenging to distinguish how to structure the two main entities - sections and tables - into a comprehensive solution.

@GJ_Roelofs has some great posts about this in case you didn’t see (and I realize this is an old post now, but still very relevant:


1 Like

Yes please for the love of god add this. This is also the only thing keeping me from migrating from Notion to Coda. Just allow “layouts” to look like sub-pages instead of just the modal view we see now.

This will make Coda the ultimate tool when this is added, having everything in Notion and way more, making it a better tool. As it stands it has way more than Notion, but not this key feature that makes Notion wonderful.


100% this. I agree that this is the one area where Notion still outshines Coda.


Could not agree with you and @Daniel_Petty more. This is something that makes it hard for me to get comfortable creating in Coda, while in (I hesitate to mention it again…) Notion, it’s a breeze. This is nothing unique they’ve hit on, other tools also allow easier creation I think. But since you guys are both bringing up this point, I wanted to add for the benefit of the community and Coda Product Team that I also have this issue.


1 Like

would use this to have a page for each project

1 Like

Yassss :raised_hands: This functionality would be perfect. Well explained!

This is the only thing keeping me from moving from Notion at the moment.


Biggest thing missing is this ability and integration of the API with other popular and CHEAPER services than Zapier. Zapier is the most high priced for an individual to use. IFTTT is much cheaper as is Microsoft Powerautomate.

@Susan_M_Davis while that might be true, I’m not sure this thread is related to integration with external APIs

Well I think my post was unclear. I was agreeing that THIS ability of managing pages AND the API integration with other apps were both things I think are missing. So, yes I think my comment goes here, it just wasn’t worded very well. I definitely want the page integration mentioned. It’s a HUGE thing. Which I believe the API integration is second to the pages being the FIRST and MOST IMPORTANT thing missing in Coda.

1 Like

Agree with everyone on this thread. I am migrating my PARA implementation from Notion to Coda. Will be awesome if Coda has the ability to make each row a subpage.



Rows as pages would provide amazing flexibility for combining structured and unstructured data, and for streamlining the inclusion/exclusion of items in the page list.

1 Like

I am also looking for this functionality so just wanted to add my voice to this list. :slight_smile:



The same here. I would love to see this functionality. I miss this from Notion.

1 Like

Great news, they are going to do a project related to this!


Hi all, as Connor has pointed out we have started looking into this more seriously :partying_face: .

With that in mind, what would be helpful for us is if we could understand more of what users are try to actually accomplish with this feature. What would you use it for in your daily work? How does pages/sections like rows fit in?

Asking for this because we are convinced by the concept/idea but and are now thinking about execution!

Edit: forgot to say, fantastic write-up @Connor_McCormick !

1 Like

In my opinion, my main goal with this kind of feature would be to dinamically update documents, so the information can be handled in tables database-like, while the final consumer (i.e. a customer for whom we are developing a project or so) can access, comprehensive up-to-date documentation.

Other scenario is where you usually deploy some control over documentation, such as when you are dealing with a [methodological] system (i.e: quality management system, business manual, or documentation for development process such as different components, functionalities or so).

In all those cases, you use database (or coda tables) to keep track of data in an structured way, and generally, documenting it could be perfectly automated out of that data, if document could be handled in that way.

Take the “development process” scenario. We use tables to track teams, tasks, components, backlog and so. Documenting it in a human readable way could easily achieved if we could create sections and populate them dynamically. It would simplify a really necessary task to capitalise organization knowledge, share required parts with customers, investors…

Wait for it, I’m having my All-in moment:
Please, let us automate documents. If we could dynamically create entire documents and populate them from another, say, master document, that would be winner hand, because:

  • You have a master document, then you want to share certain information with customers and other with externals. You can have another document with cross doc enabled, but you have to remake it for each new project to share, because you have to delete cross doc tables and remake them with new filters
  • Same scenario: you update your template, but there is no template. You need to update each single document , or recreate all of them, changing cross doc tables on each scenario