to integrate Coda with the other apps your team uses. A few months in, we realized the number one Packs request wasn’t for another service, it was for another Coda doc.
Cross-doc lets you pull data from one doc into another, so you can retain that ever-elusive single source of truth. We expect this building block will likely reshape how you organize information in Coda. Instead of one giant doc with views for every team, you could now have one Coda doc for the master data set, feeding into separate team docs.
Our makers have been asking to connect docs for a long time. Over the last year, we’ve built several prototypes in hackathons and tested a couple approaches in our own docs. But none felt quite right until now. Cross-doc hasn’t been an easy design challenge, so consider this our humble first iteration.
Why was it so hard?
Putting aside technical hurdles, we had to start by understanding how a table should work when it wasn’t in its original doc. Who can make edits? What data should editors see? We wanted to make sure the solution had the security and integrity of your data at its heart.
Back to building blocks
Like all of the best Coda docs our breakthrough came from our building blocks.
which enabled syncing external data into a doc. Now, we’re adding the missing piece, which is a new scoped API that enables pulling data from a specific table, not the whole doc.
The last piece is key for Cross-doc, as it enables us to create a UI to share parts of docs. It means you only share what you need and nothing more.
To go a level deeper, we operate on a what you see is what you get model, meaning we only sync the data that is shown in the original doc, not the hidden rows or columns. This means you can keep sensitive data completely hidden when you sync a table from one doc to another. For example, you could use cross-doc to distribute feedback for each of your direct reports from a master feedback doc and hide columns containing information from other direct reports.
We started with one-way sync to protect your data so no one can edit a table from another doc. In the future, we’ll expand this to allow edits the other way in certain scenarios.
Given some of these nuances, we want to share some of the best use cases we’ve seen for Cross-doc both from our own experience and from our beta customers.
(1) Single source of truth
We heard many makers use the term ‘single-source of truth’ in our research and it quickly became our target scenario for Cross-doc. It’s ideal for situations when there is a central doc that is updated as your source of truth and teams want to use that data in their own docs.
— Managers can store all their team’s performance reviews in one private table and create views for individuals that can be synced into their 1:1 docs. This means a manager can keep an overview of their team, but share the results privately with each report.
(2) Combine multiple sources
It’s possible to do deeper rollups and aggregates from multiple docs into one, but this case takes a little more work. To do this, we put together a helpful