Hi Coda Community,
I’m leading the design of our agency’s internal wiki/knowledge hub and would love some advice from those who’ve gone down this road before.
Context
We’re a mid-sized creative/social media agency (150+ people) transitioning to a new operating model built around Pods (client delivery teams) and Centers of Excellence (internal craft/discipline teams). We already use Coda for dashboards and some workflows, and now we’re aiming to centralize our documentation (processes, rituals, resources, charters, etc.) into a clear, scalable wiki structure.
Goals for the Wiki
-
Provide a single source of truth for teams (Pods, CoEs, leadership)
-
Balance consistency (shared templates, navigation patterns) with flexibility (each team evolves its own content)
-
Integrate smoothly with dashboards, trackers, and OKRs already built in Coda
-
Reduce confusion by clarifying where different information lives (vs. Asana, Figma, Slack, etc.)
Questions I’m Hoping to Answer
-
Architecture: What’s the best way to structure this? A hub-and-spoke model (Agency Hub → CoE Hubs → Pod Hubs) vs. one giant doc with sections?
-
Navigation: Any best practices for organizing navigation (tables vs. page folders, templates for consistency, cross-doc linking)?
-
Scalability: How do you set this up so it doesn’t get bloated over time? Tips for maintenance or ownership models?
-
Examples: Are there any great examples of company wikis built in Coda that show strong structure, naming conventions, or navigation?
I’d love your guidance on what has worked (or not worked) in practice, and how to avoid pitfalls as we scale this.
Thanks in advance for any advice or examples you can share!
1 Like
@Brianne_Bracken Well… you have to break it up just enough not to end up with a giant doc, but not too much to have so much fragmentation that context is lost.
Regarding the architecture… it depends on what is needed, where it is needed, and how often it is needed. Only after you establish what you actually need, you will be able to choose the technical solution. (Cross Doc, Webhooks, Sync Pages….).
Navigation in Coda, well, users have at hand multiple ways of getting somewhere, and I recommend you do not expect users to follow your super strict way of navigating somewhere, as long as Coda doesn’t give you tools to enforce the restrictions. My advice? Keep it simple. Page folders inside docs for logical grouping so that users don’t have to scroll 3 screens to find a page in the sidebar, button navigation between pages where it makes sense as an additional way of getting around, and maybe use Coda Admin pack (enterprise), to create some “table“ navigation.
Scalability? How many rows does your current biggest doc have? I have clients with docs that have 70-80k rows, 100+ views, and a few dozen base tables that work just fine.
Examples: I would mention here that consistency is more important than a specific “naming structure”.
If you want, I can guide you over a call (absolutely free and with no hidden upsell). Cheers!
3 Likes
I’m a big fan of using tables within docs to create structure for wikis rather than putting the information on different pages. I find this template really useful because it allows you to use tagging within tables to organize information, and then you can reference the table rows in other areas of your doc, or even within other docs. This would let you pull in views of your wiki into other team docs using sync pages, too.
6 Likes
I absolutely agree with you on this. It gives you unlimited ability to store meta data - when created, by whom, modified when and by whom. You can add scheduled revision dates.
It gives one so much flexibility. And if you just have to have the info on pages, create a page with a view of the table filtered to the specfic row.
You can use the data in other functions. For example, you can add your Capex policy, and then build an approval workflow using the authorisation limits in the policy. If they change, you only have one place to update.
The possibilities are endless, and you don’t need a single line of code, and a minimal number of makers.
2 Likes