10 min read

New page or new doc?

How to decide if something should be added to an existing doc or created as a new doc.

It happens all the time: you're building in Coda, and you're not sure where to add your new information. Should you open a new page within your project tracker, OKR doc, team hub...or create a brand-new doc altogether? As with so many Coda best practices, the answer is: it depends. Each organization and use case will have different functional needs, amounts and complexity of data, and processes. This tutorial will lay out some best practices to keep in mind whenever you’re adding new content.
What you'll learn
  • How to organize your content across docs
  • Why docs with too much content are risky
  • How to transfer pages between docs
What you'll use
  • Add a page
  • Create new Coda doc
  • Copy page to doc
  • Sync pages

Take stock of your content.

When determining where to place new material, consider the following:

👋🏻 Audience

Who will consume and interact with the content?

Usually, docs are designed around some matrix of use case and audience. If portions of your docs have vastly different audiences (whether for UX or privacy reasons), consider whether they should be broken apart. Similarly, if you find yourself repeatedly creating pages that will only be used by a subset of the doc’s user, consider a new doc.

📏 Breadth vs. depth

Are you trying to appeal broadly to a general audience, deeply to a set of experts, or both?

A doc can usually be broad (companywide OKRs) or deep (a single project or initiative’s writeup), but rarely both. If you have a doc that’s trying to do both, diagram out the use cases and audiences, and see where you can segment.

🗺️ Navigability

How long and deep is the lefthand page list?

When the page list becomes too long and/or too deep, a doc’s discoverability and navigability erode. If the order and quantity of pages and subpages isn't intuitive, you may want to consider separating your doc.

📠 Words vs. data

How much of the content is on the canvas as compared to in tables?

Generally speaking, it’s much easier to separate unstructured (page-based) data into multiple docs than to separate structured (table-based) data. Try to keep text-heavy docs aligned around a single topic or use case.

⏰ Duration of relevance

How long will the content be accurate and useful?

Some docs, like team hubs, are built to grow and evolve over time with use. They will always contain up to date, useful information. Others, like PRDs or project roadmaps, are tied to a specific goal or timeframe and can likely be archived once their relevance has passed. Think carefully about mixing these two types of content in a single doc, as repeatedly adding briefly pertinent content to a working hub is likely to result in doc bloat.

📡 Data connectivity

Can the structured data in the doc be broken down, or does it need to stay in a single doc?

Tables are most easily connected when the views are in the same doc. Keeping tables connected between docs is possible, but it's more complex to set up and requires the use of the Crossdoc pack. If two pages contain views of the same parent table, consider keeping them in the same doc.
Tip: When in doubt, put it in a new doc
While there are of course exceptions, you’ll want to default to putting less in your docs, not more. Focused docs are easier to use than sprawling ones! And you can always move pages into other docs if you change your mind.

Beware the mega doc.

You might be wondering, "Why can't everything just go in the same doc?" Putting tons of content into a single doc has 3 key issues.


When a doc has a large number of pages, finding specific information within can become challenging. Users may spend a significant amount of time searching for the right page, leading to inefficiency and frustration. It's also often the case in larger docs that not every page is relevant to every user, meaning users are sifting through useless pages. Who likes clutter?


If docs grow to epic proportions, they may begin to slow down. While your collaborators are likely to experience usability issues before you reach these thresholds, a doc may start to experience slower loading times if its page count goes above 5,000 (though this number is a very rough estimate—actual limits depend on how much content is on each page. Learn more about performance here).


Coda does not have page-level permissions, meaning everyone who has access to the doc can view all pages within the doc. Information with different view restrictions must be separated into two different docs. Note: View permissions are set at the doc level. Edit access can be set at the page level via doc locking.

What if I change my mind?

Fear not! Docs can be combined or split apart in the future.

Splitting a doc

If you decide a page or section of a doc would be better on its own, use “Copy page to doc” to move content into a new doc. Verify that your pages have been copied correctly, then delete the original pages from the original doc.

Combining docs

If you decide content you originally had in its own doc would be better organized as pages of another doc, you can copy those pages to the pre-existing doc. Then, delete the original doc. Alternatively, you may want to consider keeping the docs separate but displaying them together using sync pages. This will allow you to view the content together, or open the original doc to just see that specific content. It also means that your content can maintain unique sharing settings, as permissions are set at the doc level.

Was this helpful?