I find myself, on a daily basis, craving a better cross-doc experience, and I thought it would be helpful for me to share back what it is like right now from a user perspective.
The cross-doc experience comes at a price to Coda in terms of potential users not being able to get the best/most powerful experience out of it. The syncs can take time, and the complexity feels hard. This can be overwhelming and makes users hesitant to adopt Coda without expert/creator support. Please know I absolutely love Coda as a tool, and I am blown away by what I can accomplish in the tool with a pretty low-code approach. This feedback comes from a place of care.
I am sharing my cross-doc structure below, the various packs I am using to enable this use case, what I love about the packs, and what I wish worked differently. As a doc-maker, it is hard for me to tell what is a coda constraint versus a pack constraint – but guessing the sync times I mention below might be out of pack-maker control.
(click to zoom, or here is the link on Miro)
Essentially, some version of source docs feeding into a main doc → linkage/smart processing in a main doc thanks to Coda’s powerful formulas and data relationship capabilities → and then getting disaggregated via user-specific docs where folks can see the segment of the data relevant to them. I have seen other posts that have similar setups.
I hope this is helpful to the community, and helps build stronger functionality for all in the future.
thanks for the compliments and feedback. can you elaborate on your wish? What do you mean by rule based instead of row based? What kind of rules do you have in mind?
Hi @Christiaan_Huizer, essentially I wish I could apply it at a table level rather than the row level.
So, for rows for which X condition is true, send them forward to the target table.
Here is an example: Our main doc has active comp ranges for the year. At the end of the year, we want to send these forward to another doc to keep historic record. I know I can currently add the pack button to each row in a source table, and then build a canvas button that clicks those row buttons, and then push that main canvas button or even use an automation to do that. It would be amazing if there was a way I could simply apply the pack at the table level rather than the row level.
Overall though, I really love how fast the pack works and its simplicity. So this is more of a cherry on the cake ask from me
thx @Astha_Parmar , to make sure i understand, today you have to select manually the columns you want to push to the target doc. When your doc has 30 or 40 columns this is indeed a bit of clicking.
Would you instead like to see the option that all columns are already presented in the function, thus preselected?
I hope you do not add one column per button, because you can put all of them.
for those wondering what we talk about, see this blog.
Hi @Christiaan_Huizer – I actually love how it works in terms of columns because I don’t have to vary the view and can just specify what I need to be sent over.
Its more that I wish to use it in say automations and whole table level actions. The more I think about it, maybe this is my own learning curve…perhaps the most flexible approach is for it to be a row level action that I can then control via automations and canvas buttons.
I am so impressed by the approach you took to this, and really appreciate you moving the cross-doc capacities forward!
in the button you can create filters to exclude certain rows
an automation runs on changes in the table (any row)
in the target doc you don’t have to worry about the names of the columns, only about the order
you can replace any button in any table with an automation, so yes that is very well possible. In step01 you have the change of rows, in step2 the webhook.
I needed this pack to get rid of cross docs while working with clients. Cross docs are a costly affair due to how they operate (time consuming and view based) and when working with and for clients, I need to move on. Born out of necessity
One of the things that is actually nice about the crossdoc set up is that I can have local columns that folks can edit, while keeping columns from the source table safe (since they are formulas).
How do you deal with this in your two-way sync?
-A
in a bi-directional sync logic, the idea is that you can edit the columns on two sides and that each side will overwrite the other side. In case you want to avoid certain columns to be edited, you better use a normal sync and you hide these columns since the input in the target doc will be overwritten with the data from the source doc. The values you need elsewhere in your target doc, you can reference in your formulas.
Two way sync is wonderful, but maybe not as often required as many makers believe. The one way sync solution, certainly when fully automated, thus without buttons is fast and and flexible. I have docs in which one table is the source table for many other docs, each time with different filters. Since we cannot comment in your automations on what we are doing and you easily have a lot of them, it can get confusing.
