Controlling access per page in Coda, OR, is it best to set up and link out to other docs instead

I love the idea of putting all of my pages into one organised doc, covering:

  1. My company Wiki
  2. Data tables
  3. App-style areas that we could provide various parties access too

However, after setting this type of structure up, I’ve found that we won’t be able to provide access to only specific pages/subpage structures within this doc.

I could separate out items based on the things we want others to be able to access but this will make us less efficient and won’t provide a single UI to access all of our business information/ items.

Another issue by separating the docs is that, when I move the current pages in our Wiki, for example, over to a new doc, any relational columns we’ve set up will no longer reference the original table.

Wondering what you guys think the best practices are here.


Hi @Marcus_Layton

I went through the same discovery when starting to use Coda. Thanks to advice offered here (I believe it was from @Paul_Danyliuk yet again :)), I ended up migrating to separate docs for separate goals.

It’s best to think of docs simply as docs, not apps. You would not have a single word or google document for all of your company processes, I recommend approaching Coda the same way.

Things start to fit more naturally in Coda’s design that way, especially permissions, although you will have to manage cross-doc table imports for dependencies. Note that cross-doc imports can limit scope to only what a view of a table has, not the underlying table, if you need to expose only a limited, non-sensitive aspect of a table to another doc.

Unfortunately the transition may be tricky as copying / moving sections or tables from one doc to another is not very well supported at the moment (I was unable to do so with certain tables, copy paste error), so you may have to do a lot of manual work to get things moved over. You could try duplicating your current document many times and then stripping out the extra content from each copy to turn them into the more focused targets.

For example we have the following documents:

  • HR doc for rolodex and candidate process
  • Deals doc for clients and sales
  • employee billing document that pulls in tables from HR and Deals, and keeps financial data decoupled for permission flexibility
  • Projects doc for project overviews
  • Specific docs per project as needed, aimed at small to medium projects (larger projects would probably go outside of Coda) for single source of truth + project tracking
  • Management doc for strategy, meetings + management tasks

I hope to see Workspace folder nesting in the near future and perhaps better cross doc support, but this may not be a need for you in the short term.