Oh, I think you’re just misunderstanding the concepts of working with data in Coda.
You don’t have to create a new Tasks table for each phase. You don’t have to create a separate page for each phase. You don’t have to create a separate doc for each book, unless you want to share those docs with different lists of people and absolutely cannot have e.g. Book 1’s publisher accessing the data of Book 2. Instead you unify as much as you can.
If I were building this doc, I’d make:
- A table of Books where each row is a book record.
- A table of Book Phases where each row is a phase of a particular book. (presume 90 rows for 9 phases x 10 books). A column
Book would link each group of 9 rows to a particular book.
- A table of Tasks, where each task is attributed to one of the Book Phases and one of those 4 groups you’re talking about.
So in total, three base tables.
Then I’d have one page to show the list of tasks (a view of the Tasks table). I’d have some user-controls in the top that would filter that view down to only one book, one phase, one type etc.
If I wanted, I could create separate pages for separate phases etc. — but still show the views of that one Tasks base table. But there’s little benefit to doing this really — I’d rather only create different pages where I actually need to present content differently, not as a means to select which data to look at.
Finally, I’d have a separate, “admin’s” page with a view for all urgent and unfinished tasks for all books and phases. In one place. And if you ever need to access that via API or Zapier, it’s going to be just one request from one table.
And if you decide to go with one doc per book approach, the same applies there as well. You won’t need the Books table, and your Phases table will only contain 9 rows in each of those 10 docs. But in the end, in each of the docs you’ll only have one place (one view of Tasks) to read from. 1 + 10 requests overall, not 360.
Pages are a purely presentational device. They are separate from data structure. The best practice is to first think of data design, then presentation.
TL;DR: Making separate tables (actual separate tables) like Phase 1 tasks, Phase 2 tasks etc are a bad practice in Coda. You only make separate tables when you mean totally different concepts in your system, different levels of data. You cannot combine data from multiple tables into a single table, e.g. collect all Urgent tasks from both Phase 1 Tasks and Phase 2 Tasks table, because as far as Coda is concerned, Phase 1 Tasks and Phase 2 Tasks are two different concepts, even if they have columns with the same names. But you can do the opposite — take a single unified Tasks table and make many views out of it, each filtered to show only that portion of data that you need — e.g. Tasks for Phase 1, All Urgent Tasks, All Tasks Assigned to Current User etc.
