Cross Doc Update — Coda
Why an updated pack doesn’t instantly solve everything
My blog, provocatively titled “Is the End of Cross Docs Near?”, has been one of my most popular posts. The relevance of syncing data between docs cannot be underestimated in my opinion.
Given Coda’s significant updates to this pack, there’s plenty of good news to discuss. I’ll reiterate the points I made in my updated spring 2023 blog post.
Coda’s September 2024 update to the Cross Doc pack makes things easier: filter and grab columns right in your target doc, no source doc views needed. Each target doc can now handle up to 10,000 rows, even with a massive 50,000-row master table. Two-way sync is also here, but only if you can access both docs, and it’s not as speedy as promised yet.
While it’s a big step up, there’s room to grow. Referencing users in a people column still needs their email addresses (via cross-doc or webhooks). As Joostmineur notes, Coda has a bit more work to do for a truly smooth experience.
It is a pack
Cross Docs is not built-in, it’s an extra feature. Even though it’s free and made by Coda, it’s still something they added on later, not part of the original design. What started as a quick fix turned into a major feature. Why?
- User demand: Cross-doc functionality likely became a popular request from users who needed to connect and share data across multiple documents. Coda responded by developing the pack to address this need.
- Complexity: Building seamless cross-doc functionality directly into the core software is likely a complex task, requiring significant development resources and time. Releasing it as a separate pack allowed Coda to deliver the functionality faster and iterate on it more easily based on user feedback.
- Flexibility: A separate pack gives Coda more flexibility in terms of updates and improvements. They can release enhancements and fixes to the pack independently of core software updates.
Essentially, it seems Coda initially underestimated the importance of cross-doc functionality, viewing it as a minor issue that could be addressed with a simple workaround. Simple because packs are promoted as simple, everybody can make and maintain them. Coda has even an (a great and friendly) employee dedicated to promote and support packs making.
What do cross docs sync?
Contrary to what the name seems to suggest, cross docs do not sync docs, instead they sync tables, which live in docs. Previously they synced a table view, which you had to prepare in the source doc. The sept 4 update changed that. The updated pack allows you to bring in the full table and apply filters in the receiving document. At April25, 2024, Coda introduced 2 Way Sync for users with access to both source and the target doc. This has some advantages, but they are not huge and that relates to my next point.
How do we use cross docs?
From what I understand, the Cross Doc pack came about as a solution to an unanticipated issue. Coda initially thought a single document could handle all your needs, but the widespread use of cross docs and (later in time) sync pages, suggests people prefer linking information from various sources.
Sync pages, as the name implies, synchronize entire pages, including both structured and unstructured data. It’s based on an embedding mechanism, and although you can currently edit a synced page with access to both the source and target docs, the goal is to enable editing of the synced page data even without access to the original document (stage 4).
Even if this becomes a reality, a cross doc-like solution will remain crucial. The main reason is that you can reference cross doc tables within a doc, but you can’t reference tables or other data on a sync page.
This referencing is key for creating intelligent workflows. For instance, you might need a list of active and available employees per department in department-specific docs to build department-specific workflows.
In these cases, we use cross docs to share data, and then we create views within other tables based on that shared data. As I mentioned in a previous blog post, tables have two main roles:
- Data Storage and Retrieval: The default table view is perfect for this.
- Data Presentation: This includes timelines, cards, charts, etc.
It seems to me that cross-docs are primarily used for data storage and retrieval, rather than data presentation. They work behind the scenes, feeding other tables with data. The tables you see rely, at least partially, on data brought in through cross-docs.
Cross-docs are one way to bring in data from other documents. Another option is to use a webhook pack..
3 table types
There are many discussions within the Coda community about limitations associated with the cross-doc pack. It’s widely known that there’s a 10,000-row limit, but other restrictions exist, such as those related to the canvas column, the people column type, and the confusing process of changing column names.
I’ll wrap up this cross doc update by focusing on three table types. First up is the grid, which is like a simplified table, but it doesn’t have all the features I thought it would to be truly useful.
Grids (simple tables) allow you to create beautiful layouts that showcase your content, without worrying about column names, filters, or other advanced table features.
The second type is the table as we know it. You can cross doc this type of table and use your data in your target doc. The normal table is also used as starting point for all sorts of views (card, calendar, charts, etc) and the building block behind forms. A variation is the sync table used by pack makers to bring data into a doc from a — to Coda — external service.
The third table type is one we don’t currently have, but I anticipate its arrival. For now, I’ll refer to it as a power table. Its key features are speed and capacity — it can handle millions of rows in milliseconds. Power tables offer limited view options like charts and calendar views. You can effortlessly sync them to other documents without any size restrictions. This is possible because power tables are essentially a view of a table hosted on Azure or a similar large data platform. The process of creating power tables will differ slightly from what we have today. Finally, power tables won’t be free, but rather a premium service.
I believe in this concept because the 10K row limit for syncing data isn’t technically necessary. Recently, they also capped CSV imports at 10K rows, while earlier in September, this was unlimited. To me, these signs hint at something bigger on the horizon.
A power table would be a great solution for the numerous problems makers face today, especially for those willing to pay for such a feature. This also implies that I don’t think Coda is going to address all the inconveniences associated with cross docs.
Coda offers various sharing logics to accommodate different needs.
I hope this article was informative and helpful. Did it help you to solve a problem you unlike would have solved other ways? What about a donation?
My name is Christiaan, and I regularly blog about Coda. While this article is free, my professional services (including consultations) are not, but I’m always happy to chat and explore potential solutions. You can find my free contributions in the Coda Community and on X. The Coda Community is a fantastic resource for free insights, especially when you share a sample doc.
