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.
Your other option is the 2 way sync pack I developed before. It should provide you all the flexibility of automatic satellite doc creation with full 2 way sync capability.
It can be a bit to set up, but once done it works like a charm!
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.