Pro hack: Trigger cross-doc sync with an action (hidden formula)

Let’s say Doc A is a data source and Doc B is where you have the sync table from Doc A. I see the process like this:

  1. Doc B inserts a row into Doc A through a Cross-doc action
  2. Doc A has an automation listening on new/updated rows in that table you just inserted a row to.
  3. When automation triggers, Doc A updates that trigger cell in Doc B through a Cross-doc ModifyRow action.
  4. Doc B has an automation listening on that cell change, as per the trick. This triggers the startsync/synctabletable scenario, and the table eventually updates.

So the idea is to replace who’s modifying that cell and triggering the sync. Previously it was Doc B who updated that value. Now it should be Doc A remotely into Doc B. This should work because the automation in Doc A will only fire when the added row has actually landed into the snapshot.

Regarding setting this up, I personally always prefer to set up any actions in buttons, not in the automation settings directly. I think editing buttons is easier, partially because it preserves newlines.


Thanks for clarifying @Paul_Danyliuk.

I set this up and it worked. There’s still a bit of delay before all is complete and the sync completes, but it’s working more reliably now.

This is a clever approach - thanks for taking me through it and teaching me many things along the way.

That said, will this delay be a permanent barrier or are there plans to make it more “instantaneous”?

I ask as in my use case, I’m asking a user of the doc for input data, storing that in a remote doc, and then I want to have the user see what they just input via the sync’d table. This is equivalent of a web app presenting a modal form, the user providing some information and clicking “save”, and that information showing up in a table of like information immediately so the user has a sense of their input being “saved”.

If there’s not a more instantaneous sync solution, I may have to remove the “table of like information” so that the user just submits information and it goes off into the ether, but they’re not waiting for it to show up like a traditional web app would (by instantaenously making a call to a backend that will pull the updated data from a database, for example).

Huge thanks again for this clever pro-hack.

I wouldn’t know — I’m not working at Coda :slight_smile: But given how Coda works under the hood (which I had a chance to learn purely by reverse-engineering it myself), I doubt that any improvements to this particular use case will happen anytime soon.

And yeah, if you want to build the UX where the user immediately sees what they have submitted, you should probably build that UI around the “local” table, not the sync one. The user adds the row to that table (via a form-like layout, for example), it gets submitted but they see it already. Then when it’s synced back (into a separate, sync table), it’s looked up into that local table and e.g. a checkbox “Saved” becomes true for that row as a confirmation. Something like that.

The problem with this approach though is that users can delete rows from this local table in Doc B, thinking it would also delete rows remotely on your Doc A.

(and yeah, I’ve built a solution like that for a client a few months ago, and in the end chose to base the end user’s UI on a sync table and just warn them that the data would not appear immediately)


Thanks, at least I’m netting out in the same spot that you ended up, even with starting to warn the users. :slight_smile:

I had the same concern about local edits to the table and that’s why I wanted to source of truth to be the remote table (similar to a remote data store / database concept).

Thanks again for all of your insights!

1 Like

Paul what do you mean by this?

Ah, only that the line breaks in the formula (indented code formatting like I usually do) are gone in automation formulas, making them harder to comprehend and edit afterwards. (82)

ahh ok yes! I agree. It would be nice if linebreaks would remain in code blocks here too :slight_smile:

You mean the community? You wrap a code block with three accents before and three accents after, on separate lines:

(also it was another reply to you :wink: )

are there are any problems you can’t solve @Paul_Danyliuk!! :slight_smile: that little nuance has bothered me as I like to give solutions to people and I know how difficult it is to parse/interpret when its new info and hard to read the run on sentence. Thanks again!

This isn’t a supported strategy and is strongly discouraged.

This may break at any time or your docs may have calculations turned off if they include this workaround.


Ben what would be the supported way of having a CrossDoc action sync the table? This is imperative to making a UX a Doc user can intuitively understand. Many times a user doesn’t know or have access to the table that would need to be synced after the CrossDoc action. Thanks!

There isn’t 2-way sync right now. We just don’t support it at the moment. Cross-doc is meant to pull in data on a particular cadence of hourly or daily. I’d work to design your schema around those parameters instead of trying to force a solution that can break.

I struggle with this response as crossdoc already feels like a quite poor solution to a fundamental weakness of Coda.

Serious users of Coda can have some fairly large datasets and many different users need access to some or all of that data but each set of users might operate in different Silos… imagine a large organisation that has sales teams needing access to thousands of clients and an accounts team also needing the same client data however they cannot share the same doc as they each have other private tables that cannot be exposed. The 10,000 row limit is already an issue, and waiting 1 hour for a sync is not practical for many systems.

In reality many Coda users probably dont want sync, they want live access to a shared table, but since they cannot have this, sync becomes a workaround.

There does not appear to be any schema that can overcome this.


I would say try not to read this as the only and permanent solution. Coda is a growing product, and part of what helps us grow as fast as we do is getting solutions out there, taking in feedback, iterating, and improving. After all, how can you build a great product for your customers if you don’t actually build it with your customers?

This isn’t something that can be solved overnight, but we do have our eye on things and the product will continue to improve.

Thank you for letting us know your use-case and needs.


I just tried this, but when the automation is triggered it gets flagged with an error that says “Syncing table from cross-doc failed due to an internal system error”. It triggers the Cross-doc sync in my table, but after the table starts syncing and it says “Loading Table from CrossDoc…” and never actually loads. It just gets stuck there. Any thoughts?

Maybe they disabled this finally. As Ben said above, this is a discouraged solution. I shared it because I found it to work at the moment, and was excited to share this hack. But it’s still a hack.

Ok, gotcha. I will keep my eye out for another option and see what happens. Thanks!

I am merely trying to Cross-doc in some tables from another doc.

The usecase is that my user will duplicate the Template doc, then click a button to sync the new doc with the source doc, then do some work. They never have to sync with the source doc again after this.

How do I do this? My solution right now is to ask my user to click the sync button for all 6 tables:

Hey Coda team!

Any updates on this with respect to 2-way edit syncs or forcing a sync through an action? It’s really really hard to use Cross-Doc right now at our org without a reliable sync solution baked in since we use automations to trigger Slack notifications based on changes in the referenced doc.

1 Like

Hi, is there any plan to put a smoother way to trigger cross-doc sync? It’s really blocking to have a one hour limit and not being able to trigger it via action. News on this!!

1 Like