What you know about Cross-doc is not entirely correct
Think of any pack table — e.g. GMail import. You connect the GMail pack and get a table that’s populated with emails from your inbox. You can’t add or edit those email data (well, technically, you can add more columns to that table or even edit the existing columns to calculate something else). You can’t add or delete rows. You can refresh the table to fetch fresh data — manually, or automatically in paid plans.
GMail is your data source. A Coda Pack is a piece of code that reads data from that data source and transforms it into a sync table in your doc, like described above. The pack controls what gets returned in that sync table — the number of rows, the columns to display by default, the mechanism to identify each email, and an object containing email data for each message that those default columns are reading from with simple formulas like thisRow.Email.Subject.
Cross-doc is totally the same but the data source is a table in another doc.
Cross-doc are not the same as local table views. These are sync tables. You cannot add and delete rows, and you cannot edit the data in loaded rows — it won’t automatically update in the source doc. Just like in GMail pack there’s a SendEmail action, in Cross-doc there are AddRow, UpdateRow etc actions that you have to perform to make the edits elsewhere.
Sync tables can be used with formulas just like regular tables. I.e. you can reference rows from a cross-doc sync table just like any other table, e.g. calculate sums, do filters etc.
You can add columns to sync tables and insert the data there or make those formulas like in any other table. Just be warned that if a row is deleted at the source and you don’t have the “Keep unsynced rows” option turned on, the row will be deleted from the sync table upon the next sync and you may lose any data you entered in such table. Hence it’s a better idea to mentally treat sync tables as read-only and store extra data elsewhere.
View loading time is pretty much the same. There’s some overhead in using sync tables that’s related to its longer object identifiers, but this will only matter to you when you have thousands of rows and your doc grows close to the API size limit (which you likely will never hit if you only use Coda for personal or small business needs).
The pros of using cross-doc are:
Preventing the duplication of data in multiple places (e.g. a list of employees in each team’s doc) but keeping it in one place and syncing it to the other docs
Access control: you can track private data in one doc that you don’t share with anyone (e.g. a table of Employees with salaries), and only “export” a view of that to other docs (e.g. a table of Employees with only names visible but no salaries). This is the only way currently to prevent users who have as little as View Only access to your doc from seeing all the data. It just physically has to be in the non-shared doc.
Cross-doc is pretty essential to support doc scaling. Some teams make lots of small docs (e.g. a doc for each meeting) but some track everything through a bunch of “central” docs, and they can’t grow forever and retain their performance. So Cross-doc is used to set up data flows and archiving so that those “super-engineered” docs keep only the sliding window of currently relevant data and archive everything else elsewhere.
I talked about this in a video some time ago:
Cross-doc isn’t just Team/Enterprise. You get basic Cross-doc in a Free plan (100 rows per table, no actions, only manual sync), Pro plan (10,000 rows per table, which is a pack max, daily and hourly syncs but still no actions), and Team plan has actions.
I’m building my own version of Cross-doc that works around some of the by-design limitations of the default one. Consider using this one already if you plan to scale your docs — you won’t be able to easily replace one with another later.
It’s $3/mo/maker but it’ll have essentially all the “Team” plan cross-doc functionality in it, and some more.
