Hi
i just joined Coda as a doc maker. I would like your input on the best way to use coda for our purposes.
We are a legal compliance team in a larger legal department. our main goal is to have a one stops shop for our policies and procedures, which we can distribute to the rest of the department. we also use ai tools like notebooklm as a kb we would like also to be connected. wdyt? thx!
My business is mostly conducted among āRegulated Industryā clients in Aerospace Engineering (FAA regulated), Clinical Research (FDA regulated), and Financial Services (SEC regulated).
So I have been using Coda in these contexts for years with excellent results. We have migrated compliance teams from using MS SharePoint, Google Docs, and various proprietary document repository products.
Coda provides an excellent vehicle for building your own highly tailored repository of managed documents, which also contain Tables, Formulas, Automations, and Integrations with other applications.
However, this is only worthwhile if you are prepared to put in the effort to develop and maintain your own tailored solution - otherwise, it may be cheaper and easier to stick with an off-the-shelf solution.
But the rewards for building your own specific solution that matches your business requirements are well worth it in my experience.
Coda does not come out of the box with all the mechanisms required to implement āControlled Documentsā for compliance with ISO9000 regimes.
For this, you need to apply your own policies on top of the default Coda platform. The most important one is the need to have full version control on your controlled documents.
For this, we always add a version number to the end of every document title. And we ALWAYS copy the current version and modify that copy to generate the new version.
We have added our own document control table to each document to record who changed it, why, when, and with what approval process.
To ensure that users always access the correct document version, we keep a āMaster Documentā for each department that contains the links to the latest documents. That way, we can control which version is āliveā at any time. And we can roll-back if needed. It also provides the document change history needed by auditors.
An alternative approach might be to only rename the OLD versions of the docs and move them to a separate folder where users wonāt see them.
But we have found the āMaster Docā provides a place for keeping a lot of the meta data about policies and procedures, and document versions, etc.
We have found that the armies of auditors that must review and approve our controlled documents LOVE this approach to document control.
Coda also lets you use a single document to store the process definition AND the usage data needed by auditors to show that the procedures have been followed, etc.
One difficulty you will need to address is the inability of Coda to easily separate the DATA tables from the rest of the document, so moving to a new version of a document often requires us to kick users out of the live document while we migrate to the new version. (We hope Coda will be addressing this soon with āworkspace tablesā that reside outside the documents.)
Reach out if you need any further help.
Respect,
ā¤ššš
First, thank you so much for replying and sharing from your experience!
The main usage you do with Coda is repository of policies?
Thx again
Michal
Actually no. We do use Coda for that - but the main usage is to IMPLEMENT standard operating procedures within regulated environments.
So the Coda documents that automate the procedures are controlled documents, so we need to enforce version controls etc. We also have a setup with DEV, TEST, PRE-PROD and PROD folders.
In DEV, the maker builds or modifies the doc and uses their own unit tests to ensure the changes work correctly.
In TEST, we build a set of regression test cases that further test the docsā functionality. Those test cases are used every time the doc is modified to catch the cases where we fix one thing and break something else.
In PRE-PROD, we test the docs using a redacted copy of our live data, so we can check it works with realistic cases.
In PROD, the document goes live and is used by our user population for real business cases.
So every change to a working automation must go through each of these stages before it is considered safe to use in real business with live data.
This is a far more stringent deployment regime than is needed outside of regulated industries, but it is essential for clinical data, financial services, and aerospace maintenance applications.
This is beyond just using Coda to maintain a set of compliance documents.
So I suspect you will not require the same level of ādevopsā (development operations) that we use. However, you will probably need to version control all your documents.