Can Coda docs behave as databases?
The advantages of well defined and interlinked data containers
When I explain my Coda approach, I tend to present docs as databases. Why I do that, I try to explain in this blog using the concept of core docs and secondary docs. I conclude that you save money and time by showing results before expanding.
Before we dive into the matter, you should understand that Coda is as much about the tool as it is about a way of thinking. It is an approach to process data. Once you learn how to Coda, you learn how to review your processes. The formula language, the actions, the packs and all the rest is secondary to the question: “how to create process that work for me instead of me working for the processes.”. Time to get started!
The doc as a database
Docs blend structured and unstructured data. Tables represent mostly structured data, while the canvas is mainly used to store and show texts and images: unstructured data.
The essence of a database is to provide a structured and efficient way to store, manage, and access data.
Strictly speaking, docs cannot be databases. Not all data in a docs is structured and can be retrieved. Nevertheless how we deal with docs comes close to the core concepts of a database:
- Data modeling: The process of defining the structure of the data in the database.
- Data storage: The process of storing the data in the database in a way that is efficient and secure.
- Data retrieval: The process of querying the database to retrieve specific pieces of data.
- Data manipulation: The process of updating, adding, and deleting data in the database.
- Data integrity: The process of ensuring that the data in the database is accurate and consistent.
When you review these similarities it is not too hard to see that docs focused on well defined themes have a lot in common with databases. They look alike, they behave as databases.
In my point of view, we should have docs related to clients, products, employees and so on. To make these docs intelligent, they should be linked and work together. Data not only relates in docs, but also crosses docs.
Syncing tables and pages between docs
In the last 12 months I wrote several times why syncing matters and I explained why difficult is not the same as complex and how we can reduce complexity. It is mainly complexity dragging us down. When something is difficult, you can learn how to overcome the barrier and make progression, when something is complex, you get lost, there is too much going on at the same time. It gets worse when something difficult is made complex to hide the fact that sometimes you need time to learn a thing or two. More about this in another blog.
In the blog below I also show how to set up a webhook to sync data between docs. It is a technique I’ll keep using until Coda releases a mature two way sync solution.
Coda followed up on their own strategy and for me the most important update of Coda 4.0 at Oct 4, 2023 was the announcement of a solution not yet present: sync pages and content sharing.
You can read all about the step 1–4 in the thread. My point is that in the near future, docs can be natively related without shared permissions on both sides (source & target doc). When this happens clients have access to their specific data in their docs based on data living in the main or core client doc with all other information you in your role as for example client or employee do not have access to.
In this concept docs behave as databases.
The community is for good reasons exited about these updates and keeps asking for more. I am rather sure that once Coda makes this happen, it will shake the no code world. Makers across all platforms will come to Coda to share data intelligently.
Since Coda works on the real thing, we have to use intermediate solutions like the webhook pack I discussed. Please notice that when I create this set up for private use or for a client, all actions are stored in automation, none in buttons, but buttons explain easier in a blog.
Before you can share data, you have to put in place a structure, a logic, a schema and this requires reflection. No code does not equal no thinking.
Core Docs — Secondary Docs
When we can label docs as data bases, it is not to say that all docs are data bases. Some docs, maybe most of them, will retrieve (filtered) data from so called core docs. These secondary docs are the docs we spend most time because they contain the data set we need to work with. These docs can be linked to an individual (besides the maker in the workspace) or to multiple people like a team. The data in these docs is partly retrieved from core docs, partly added or altered by the users.
An example.
You have a Core HRM Absence doc to keep oversight over all holiday plannings and other types of absences (sick leave, maternity leave, etc.) in the organization. This doc is updated via secondary docs shared with team managers of the several departments like Finance, Sales etc. Team managers fill out the requests and approve them and when HRM does (they normally follow) the remaining time is recalculated and confirmed.
This main doc on HR level (the absence inventory) itself is a secondary doc, based on the core doc all employees. This core doc is maintained on HR level and data parts are shared with various teams throughout the organization.
This most interesting doc schema requires preparation and that means discussions and an inventory of the current and desired processes. Replacing spreadsheets sending over from one department to another may have hidden advantages we do not spot immediately. When you are open to the idea that there could be benefits, you can look for them. Too often I heard that sending files is not efficient, but there could be other motives than efficiency. The social acceptation of Coda is as important as the technical part.
The HRM department may end up with a logic like below. In this set up you easily get many secondary docs, even to the extend that you can’t see the wood for the trees. To avoid that a process designed to improve the work flow starts working against you, you better select a few strong use cases and leave the rest for what it is until the moment the Coda adoption is on a higher level. As I wrote, social acceptation of Coda matters.
When you dream of a logic like below, it only makes sense when you solve real world problems in an intuitive way. More often than not, this takes more time than expected and only many small steps together can change the direction on how to collaborate fundamentally. It is a long process and showing the need for 100 plus docs to serve all kinds of needs is probably not inspiring. That said, you need to have this kind of logic in the back of your mind to guide the discussion and keep the application smart and strong.
To avoid all sorts of mistakes, it helps when users cannot destroy the docs you shared with them. That brings me to my next topic.
Makers — Editors
Part of the Coda 4.0 update on Oct 4, 2023 was the announcement that the creation of new pages became the prerogative of makers, editors no longer can. I don’t like this.
Coda missed the opportunity to transform makers into real makers, editors into real editors (not into makers light as they are today) and viewers as real viewers. The current mix up harms most use cases and the duct tape solutions like blocking the editing on pages, or blocking the deletion of rows in tables, etc. are bad temporary fixes at best. They are bad because they are not intuitive and require a great deal of attention and focus to implement and maintain. It is messy, things become complex and complexity — and here I repeat myself — drags you down.
What we need are simple roles — and likely a different pricing — that help users to enter data, push buttons to trigger automations etc.
Structured data should live in easy to maintain and fast responding tables. Columns filled with text as outcome of an action keep tables fast; understanding AddOrModifyRows() and how to apply Filter() and ForEach() are important. May you feel the need to refresh the basics on how to Coda have a look at blog below.
Smaller tables
Coda docs benefit from small tables. The fewer columns the better, data is stored in rows, not in columns. Tables are no spreadsheets. This vision contradicts with makers as Piet who favors large tables.
I prefer small tables:
- The human mind has limited capabilities to process structured data. You need to see at a glance what the table is about or you risk to miss out on important information.
- Specific data is easier to maintain via relations. Something simple like clerks, workers and consultants is easier to manage in a separate table like in this example. These are only three items. One table with 3 rows and a few columns. That is all it takes.
- tables behave as relational databases, data is stored in rows, not in columns.
Small tables become problematic when you don’t know how to chain and or when your table names are confusing. Most makers develop over time their own conventions. It saves time and avoids frustration. Figure out your own logic, improve when needed and apply it rigorously.
It also helps to structure your docs in a consistent way, it supports you and the user to find back information easier. It starts with naming conventions, but there is more to gain.
Visual support
Making it easy for the eye to see what you created helps. One table per page and the name of the table is the same as the name of the page. That principle saved me quite some time.
The moment you need documentation to keep your doc understandable, generally speaking your doc grew out of hand. The main idea behind a doc is oversight. Logical related information linked together. That principle holds on every level. Documentation is often a sign of duct tape based solutions. Run away from consultants that sell documentation as part of their solution. When you need to understand functions, automations and so on, aks for training, practice what you learn. Coda maybe difficult, but there is no need nor room for complexity in your docs
Templates — workspace variables
For data that comes back often I created templates. The advantage is that once the template is integrated in the doc, I can remove parts I don’t need. I have templates related to:
- Countries
- VAT values in Europe
- Bill of Material logics on prices, addresses etc.
- Notifications related to events like birthdays etc.
However when you share data in your workspace across docs, a kind of global variables approach active throughout the workspace would be beneficial. Today you need to duplicate all your tables (via templates) feeding lookups with variables that are the same everywhere, but are not controlled by a n overarching logic. When I change the logic type: clerks, workers, consultants into something a bit different like employee — clerk, employee-worker, non-employee-consultant, things break. You don’t want that. A possible solution is a table logic that acts as a kind of global variable that can be called in any doc of your choice to solve this problem. We are not there yet with Coda, but it will be an essential ingredient in moving data through docs. I am sure that when Coda folks read this, they know what I talk about and why.
Embeds
When people are used to excel sheets, google sheets or other document types and they like or need to keep working with them, it is nice to bring them into Coda. The embed function permits to edit the embedded document via the Coda doc. All relevant information is in once place, although the data living in the embedded doc is unrelated to the data living in Coda. Visually speaking they live in harmony and there is stops. I can imagine use cases that this is all you need.
Conclusion
This blog has shown what is possible when you see docs as data bases, it gave some pointers on how to set up these relations properly and why prudent maneuvering is important by showing results using a clear and for the human mind comprehensible logic. Once you have a few docs that makes it easier for the people to get their work done, you can add more docs. Give it time, you cannot force the Coda adaptation: it is a new way of thinking and working that requires reflection.
As Max wrote somewhere:
NoCode may have removed the need for coding skills, but it still requires good analysis and design skills to exploit NoCode tools to the max (i.m.h.o)
My name is Christiaan and blog about Coda. Since the summer of 2023 mainly about how to Coda with AI to support organizations dealing with texts and templates. Why I focus on Coda AI you can read here: ⤵️
I hope you enjoyed this article. If you have questions feel free to reach out. Though this article is for free, my work (including advice) won’t be, but there is always room for a chat to see what can be done. You find my (for free) contributions to the Coda Community and on Twitter.
Coda comes with a set of building blocks ー like pages for infinite depth, tables that talk to each other, and buttons that take action inside or outside your doc ーso anyone can make a doc as powerful as an app (source).
Not to forget: the Coda Community provides great insights for free once you add a sample doc.
