[Video] Sync data changes from one doc to multiple docs (e.g., admin → individual users' docs)

In this video tutorial you’ll learn how to set up a system where data changes in one doc (e.g. Admin panel) are propagated to multiple individual docs (e.g. user dashboards) using a free Zapier plan. As an example, I’m building a freelancer’s task tracker where I’m logging tasks for different clients, and those changes are then synced to every client’s individual dashboard doc.

This multi-doc setup is a workaround for the fact that Coda doesn’t have granular permissions yet. It allows to make sure that certain users will only get certain portions of data and not access all of it.

Of course, this is a very simplified example. But if you need something more complex (e.g., lots of tables, many-to-many access, 2-way sync etc), you may still employ this technique and deduce the rest… or you may employ me, since I’m doing Coda consulting for tricky cases just like that :wink:

UPD: YouTube is having some troubles now. The video may be unavailable for a bit — if so please check later, or get it from Google Drive here.

Also this is my first public screencast/tutorial ever :smile: I hope it’s not a complete disaster, in which case I’ll be doing more of this soon.


A few key takeaways, so that you don’t have to watch the whole 30 mins of it:

  • When you clone a doc, all table IDs and column IDs remain the same across cloned docs.
  • In Zapier, instead of selecting a specific doc to insert/update a row into, you may select Custom value and provide a Doc ID that comes from the first step, along the data.
  • These combined will allow you to dynamically specify the target doc, and the automation will still work because table/column IDs are the same. Zapier will complain because it won’t be able to pull table fields from the dynamically specified doc, but the integration will work nonetheless.
  • Zapier cannot react on row updates in a source doc, but on row inserts only. The solution is to create a new supporting table and copy the data there as new rows each time the original data changes. See this Krunal’s tutorial
  • There’s a gotcha though. Zapier doesn’t pull rows in the order of their creation, so if there are multiple rows for an entry in that supporting table, it may not apply the freshest one last. So whenever you copy a row to the supporting table, make sure that you clean up previous rows for the same entry.

Great video tutorial and tips, @Paul_Danyliuk! I’m not sure if this would work in Zapier, but what if you created a table that not only contained the unique doc IDs of clients, but also the table/column IDs as well? This means you wouldn’t be constrained to copying the template doc and worrying about the column names changing because you have an index of the doc ID => table IDs => column IDs. My hunch is this wouldn’t work in Zapier, but might be a more dynamic solution if you are setting up a data sync on a platform like Google Apps Script.

1 Like

Hi @Al_Chen_Coda, since you mentioned it, how would you populate such index table of IDs?

I did something of the kind for my fetch json doc. However to get the IDs I had to recourse to regex and hacks, especially a pretty shady one for the column ID.

May I suggest having a native formula for that? Let’s say uniqueId(object reference):


Good suggestion! I was referring to creating this index table manually. As @Paul_Danyliuk showed in his video, you would turn on the developer mode and copy/paste the IDs into an index table.

1 Like


Regarding table/column IDs, that would be much trouble tracking these too, no? And yeah, that won’t work with Zapier because it only lets you use custom value for the doc, but not for the fields. The set of fields is always pulled from the last specifically selected doc and is not dynamic.

And yeah, never thought of using Coda with Google Apps scripts, even though I’ve had some experience with the latter. Another realm for me to discover.


This got obsolete fast —

Although… Doc pack will be paid, my approach is less convenient but free.

Still excited for native doc-to-doc sync tho!