Here’s a new spontaneous tutorial that I just recorded
As a Coda expert for hire, I need to track my work for different clients. Obviously I do it in Coda, and I want to do it in a single doc so that I can see all the summary in one place. Today I was rebuilding it and thought it would be nice to make a template that I could copy and share privately with each of my ongoing clients, populated separately with only the data each of them can see.
Previously I showed how to build this with Zapier. This time I decided to try and build this with Cross-doc. This is tricky because when you want to import a new view and delete an old one (for the previous client), you’ll lose everything you’ve already built on top of that imported table, such as added columns and views. In this tutorial I show how to rebuild the doc so that everything you’ve built is preserved, and you can swap the private pieces of data easily.
Pardon my hard accent and my #coronabeard
P.S. When copying a doc for another client, first delete that synced private table, then duplicate the doc, then import the new synced private table. This is so that the previous client’s data is not leaked into the doc history.
Thanks @Paul_Danyliuk that’s great. Do you see any possibility to sync as well the settings, e.g. how to format a view? Means: you could have one master doc including all settings and don’t need to update every doc again
There’s no settings sync unfortunately. So I guess if you’re going to change a lot, it would just be easier to update the template once and make all the copies and share with the clients again.
OK I had to watch this twice! So let me see if I got it IN Tasks is the table you build the doc around (graphs views) and you filter that to only import the row ID so all other data is occulted. Then you still build your client specifc view table in your source doc & import that table in, and then push that data back into the ‘IN Tasks’ table such that it reboots the views and graphs that are already set up? Genius!
You have a front-end table in your doc that you cannot swap. You build everything around that table.
You have a back-end table (a data source) that you use to populate the front-end table. E.g. by linking a row from a back-end table to a row in a front-end table through a lookup, e.g. by ID match or whatever.
Either can be “normal” tables or sync tables, depending on what you want to build. The benefit of having a sync table as a front-end table for a sync back-end table is that you don’t have to bother for adding missing rows yourself (e.g. with an automation) — sync table applies row additions/deletions automatically. There may be a bit of out-of-sync time (e.g. when one table synced already but another still haven’t), but eventually they’ll both be synced.
Right now this is concieved as a one way ‘out’ flow where data is coming from the source to these clients. How do you think this approach holds up when wanting to have some client input or feedback. Maybe you wanted the client to give you a rating 1-3 on each task, or perhaps acceptance criteria. You could build a button that then chases the cross-doc url back from the table to reach back and do an update? What comes up for you with this approach?
You could use cross-doc actions to then ModifyRow remotely.
However in my actual client work I found this to be more problematic than helpful. The biggest issue with cross-doc actions now is that they are slow: the doc gets blocked until the changes go through. And that may take minutes if the source doc is already very big (running near the 125 MB limit for API access). Concrete example: we had a system where teachers were trying to check-in into classes using cross-doc actions from a teacher-facing doc. They reported delays as long as 5 minutes on those actions, being unable to click or do anything else while the action hadn’t been completed.
Since our teacher-facing doc is a single doc for all teachers, the solution was to add a checkin time table in this doc, then normally cross-doc it back to the source doc. Then join data by lookups.
In a scenario where you have dozens of individual client-facing docs, that could be a problem, because you probably don’t want to import dozens of tables from these. So it’s either cross-doc actions (potentially slow) or Zapier reacting on e.g. a webhook with task ID and feedback value as parameters and doing an update on the source doc (needs paid Zapier).
Yeah its quite something because on one hand its possible to do, which is great! AND its very fragile to maintain or develop further. Two way tables will be amazing!
In this kind of setup, is it possible for the client to add rows to the views they see? Lets say if I want them to be able to add orders, but I don’t want them to see who my other clients are, and what other orders I have are.
Edit: Oh i see, Cross Docs can’t be edited, so since the client just sees Cross Docs, they can’t add rows.
