If I want to create a company wide doc that includes most of the company’s internal operations like:
- Project Management System
- CRM
- Goals, OKR, KPI tracker
- Meeting tracker
- Development Management
- Support
- Wiki
- HR
- Financial
- SOPs
From a performance and sustainability standpoint, should I combine everything into one doc or have separate docs for different departments/functions?
To be clear, I do not have a specific use case, however, I am curious to know that if an average small size company decides to move most of their operations onto one platform, in this case Coda, is it better to have one doc or use multiple docs with the improved Coda cross, sync, or embeds functionality.
I know it’s hard to give an answer without specific company details and present usage information but for those who have experience with this through working with clients or in their own business, are separate docs better than a single doc for the purpose listed above?
Previously the way to go has been to put as much as possible in one doc.
Now with two-way sync tables I believe the meta might change to having multiple docs with their own isolated purposes. Haven’t had time to experiment with this yet myself though
1 Like
Yea, I was wondering if two-way sync had changed anything. Thanks for the reply.
1 Like
hi @Mike_Ray
contrary to what many others may suggest the following:
split between docs in which all makers are allowed to see everything:
- wiki
- support
- meeting tracker
- goals, okr, kpi
use other small and simple docs with sensitive information and limit access
small and simple docs are the ones you understand as maker directly without spending time trying to find out about complex buttons, automations etc. This type of complexity often show how little the maker understood of the core processes and or how coda operates.
avoid using Coda for situations in which you have to mix sensitive data with makers like a CRM. The current Coda approach in hiding data is not consistent and therefor somehow a risk.
both cross docs and sync pages will generate a lot of work and limited added value. I would only use them is specific situations and try to avoid that you have to keep track of the many filtered views living in a source doc and shown in a wide range of target docs you no longer can understand or follow without using an extra doc for your notes. That is not intuitive and in my opinion counter productive.
In short, keep it simple, very simple even to the extend that most users in the doc never see a table again and only work with controllers (to show data) and forms (to enter data).
Cheers, Christiaan
7 Likes
Coda is not yet ready for company-wide deployment.
- You cannot have financial, CRM or performance information for multiple users in one document due to poor coda security (everything is seen from a search), and
- If you have multiple documents, you will have poor UX performance and reliability issues with cross-docs, as each sync takes time. Cross-doc is a temporary fix, not a long-term, viable solution.
- If you’ll need to split the document later, you will need to rewrite all formulas that reference tables in the main document (such as lists of departments, employees, etc) as formulas, as for now, can’t auto-reconnect to DBs from cross-docs or sync pages.
- In most cases, support will not help you and will reply with the quality worse than the old GPT 3.5 turbo, once a day, with mostly misleading information.
1 Like
I do not agree with the conclusion that Coda is not ready for company wide deployments.
There is a vast amount of non-confidential information that can be used in Coda.
As far as confidential data goes, Cross docs are not the only way to share information between documents, just the original way. @Paul_Danyliuk , @Christiaan_Huizer and @Scott_Collier-Weir at a minimum has packs/strategies available to share information between docs. And you can also write your own bespoke packs of needed.
The original premise of Coda (a doC) was just that, a single doc to share information without barriers in a team. In the 5,6 years since launch, Coda has evolved tremendously. And is busy evolving to better address confidential portions of documents.
As far as splitting documents go, major changes in any non trivial environment will cause non trivial effort.
1 Like
I have used strategies from @Paul_Danyliuk, the Coda OG, and @Scott_Collier-Weir to protect doc data.
However, from my understanding, it’s not recommended if you MUST protect the data. For legal reasons as an example.
This is because the data is still available via API and possibly other means.
It works for me with simple docs because hiding access to the information is good enough for the docs I’ve developed. But it’s not a solution for all companies.
Piet, thanks. Things you described are not contradicting my thoughts. You can use Coda for some team work. Not serios business work that has need of data protection. It looks like Coda is focused on individual users and small teams, not on business.
This is a nice opportunity for competitors and a huge disappointment for developer community that can not build anything enterprise grade with Coda.
1 Like
OG here 
It’s not about the size of the team. It’s about whether you need to have user-facing content or not.
Coda is perfect for all sorts of in-house stuff. These can be large teams and numerous teams — usually there will be a way to set it all up in a way that’s secure enough and also not too painful to set up. Besides, within a company you can always patch security holes with policies 
i.e. having everyone know that if they accidentally tamper with something they shouldn’t have access to, there will be consequences to their career.
But when you want to open parts of your setup to the public, that’s where there are no easy solutions with Coda and you’d rather just build a regular client-server web app.
P.S. On OP’s question. I think I answered it some time ago and of course I cannot find the post. In a nutshell: split the doc down when you need separate access lists to separate parts. Keeping all the data in a single doc has the least overhead but also when a doc is shared with someone, the entire doc is shared and no amount of filtering or locking can prevent seeing all the data in the doc — it’s just a file that’s entirely loaded into your machine.
I’ll use this chance to plug my YouTube channel https://www.youtube.com/@CodaTricks — things are going to happen there really soon (this Monday already), and the episode on whether to go with one or multiple docs isn’t very far away in the queue 
5 Likes
Paul, I love your content. But let’s be candid. Coda is ignoring it’s community’s needs for permissions.
Please do not say that creating documents and views for each employee or manager is a viable solution. It’s not if you have dozens or hundreds of employees and multi-level management.
Here is a great article I have found from a respected community member:
and there are wonderful comments from Jean-Marie_FAVRE and many others.
4 Likes