I have a database of products in Products DB (Doc 1) that is being synced via Cross-doc to Project Products (Doc 2). I am making a specific filtered table view in Doc 1 per project and then syncing that view to Doc 2. Then further information is associated with each of those products within Doc 2, meaning that I add several columns onto the synced table that gives project-specific information.
However, because there appears to be no way to re-associate a cross-doc table with a new data source, it’s seemingly impossible to sufficiently template out Doc 2? The only way to get that unique cross-doc linkage working for each table view is to essentially do it from scratch each time.
This means Cross-doc really isn’t going to work for me here since Doc 2’s template is complex and can’t be built from scratch every time the data source changes.
My question is does anyone have a solution or workaround for this issue? Is there something about Cross Doc that I’m missing?
One solution that could work, but seems unviable for its own reasons:
If I could transfer all the columns, filters, and styles from one dummy template table to the newly imported cross-doc’d table using a button. However there doesn’t appear to be any functionality that lets you make new columns as an action or transfer filters between tables formulaically.
I know this would be solved by simply cross-docing the entire database over and filtering that table within Doc 2, that way the data source could be consistent between duplicates of Doc 2. However, not being able to filter the Cross-doc at its source is just fundamentally less ideal because it creates a lot of workflow quirks, you are more likely to hit your sync limit of 10k rows, and also potential privacy concerns.
Indeed, Sync Tables Pro was built to solve just this. Not only you can template out the receiving docs, but you can actually template out systems of interconnected docs — my pack allows swapping the source of cross-doc tables as well.
One thing though; it’s only launched ‘softly’ and still requires some work, which I never had the time to put into it. There’s also no documentation other than the videos, although those should be helpful enough. Lastly if you get confused or something doesn’t work feel free to just bother me either here or via email.
Thanks for your response! Love your videos, you’re the guy who showed me how far you can really take Coda.
I was not familiar with Xano until you released a pack for it, but it makes a lot of sense to use a scalable database as the back-end and then reserve Coda as the space where everything feeds into and where you actually work.
The thing is, we’re a small company so this 10k sync limit is something I am avoiding more out of an abundance of caution than anything else. So we’ll see if we like the price on the peace of mind a separate backend would provide.
Thanks for your response. I was aware of your pack and definitely noticed that it seemed to have some solutions to my current dilemma. I will definitely give it a demo now that I have a firm corroborated answer that doing it natively in Coda isn’t realistic.
But I wasn’t certain on the long-term prospects of the pack since cross-doc has since had 2-way sync functionality added, which I know was on the list of what you wanted to tackle for the pack.
Are you thinking you’ll continue development on it? Especially with promises of better private sharing of documents like they mentioned when they released Sync Pages, I can completely understand if motivations are low to continue to develop the pack hoping that Coda’s core features “get there”.
I don’t believe that much into sync pages, to be honest. Even if they pull off truly secure sub-doc sharing (which, right now, sync pages is not) there’ll still be room for parametric row-level access control. For instance, sync pages won’t solve your pain of having to re-import a different view of a table (i.e. a different page for each client) and then re-map everything in your template to that new view.
So nope, it’s not the thing that would demotivate me from finishing my pack.
The only thing that keeps demotivating me so far is low traction on the things I build. I’m not really in a good standing to try many things in the long run so I throw out ideas and see what sticks the best. I hoped for STP to become a no-brainer replacement for Cross-doc, but too few people gave it a try upon the launch so I ultimately had to do other things that’d bring me some income. The pack sure has the potential but a) I’ll only have time to spend on it when I have a sort of a passive income channel and can make time for development, and b) I have a large enough audience to promote it to. My hope is that both will be solved by the eventual launch of my Coda Tricks YouTube channel — so I’m working towards that whenever I can.
On the 2-way sync functionality, I will eventually bring it into STP probably. You must realize though that it also has to be designed with the same security model in mind — there must be devices to be able to configure who can actually update which values. With regular cross-doc it’s all or none; that’s obviously easy and designing a proper security model that cannot be breached is not. Besides, with the introduction of webhooks I don’t believe that cross-doc actions or putting values through the API is the best way anymore. Webhooks offer a much better transport mechanism to send updates from one doc to another: payload is easier to construct, it’s possible to perform a whatever number of updates in a single request, and you can also have validation. Sure it’s more trouble to set up but at the moment I’d prefer that way over anything else anyway.