Cross-Doc Into Single Table?

Hello there!

Is it possible to put multiple data points from various tables into a single table via Cross Doc pack? I’ll give an example:

Table 1, Doc 1 - To Do at Home:
Project - Pick Apples | Due Date - 6/12/20 | Notes - Only pick ripe ones!

Table 2, Doc 2 - To Buy:
Project - Buy Ladder | Due Date 5/29/20 | Location - Home Depot
Project - Buy Juicer | Due Date 5/29/20 | Location - Target

Table 3, Doc 3 - Errands:
Project - Visit Cidery | Due Date 6/30/20 | Location - Michigan

Table 4, Doc 4 - Master Projects (done via cross doc on to a separate doc):
Project - Buy Ladder | Due Date 5/29/20
Project - Buy Juicer | Due Date 5/29/20
Project - Pick Apples | Due Date - 6/12/20
Project - Visit Cidery | Due Date 6/30/20

Obviously, this is a simplified example. The reason I’m looking for cross doc to one table is that I have multiple docs with various tables that all differ slightly. I’m looking to bring them together for a “Master Project Dashboard”. I have over 100 ongoing projects so putting everything into one doc is not an ideal solution (it would be a gigantic doc). I’ve played around with cross doc a little, but it seems like it’s more suited to bringing in tables to another doc in their entirety. I haven’t yet found a way to bring in elements of multiple tables into a single table.


No. That’s not the [apparent] intended function of Cross Doc.

What you’re describing is Merge Docs and that hasn’t been invented yet although there are some similar mentions scattered in the forum. Ideally, it could be implemented by making the table selector [in Cross Doc] a multi-select option and a lot of changes in the underlying code, of course.

I’m not an expert concerning Integromat (per se) but I believe you can do this by creating the unified table and then use Integromat integration formulas to join the disparate tables (and their common fields) into a unified table.

Another approach - use a scripting language (like Google Apps Script) and the Coda API to read from the disparate tables and write to the unified table. This is essentially what Integromat provides without writing code.

Lastly, there may be a way to use Coda Actions to trigger copying of certain new records from one table to another, thus creating a real-time blending of data from each disparate table to the unified target table.

@Bill_French is right in that Cross-doc doesn’t lend itself well to a “many to one” solution. Its best used in a “one to many” setup. There are some workarounds if you want to sync in tables from those other docs, then run an automation to add the new rows to a combined table. It might become pretty inefficient though and inherently doubles your data.

Having a single doc with all the info where you created separate views for each project, then synced that view out to the project doc would likely be the most efficient setup. But like you mentioned, could be more work than it’s worth depending on what you need from it.

Would it be possible, in my previous example, to merge elements of various tables into one? I’m trying to NOT have a very large table with various blank cells and instead have multiple tables with a few common elements (columns) and some unique to each case.

I guess I’m still trying to figure out database design (or whatever that’s called).

The solution would be to sync tables from other docs into that one core doc you’re talking about. Then you would create a new table in the core doc, and buttons or automations from the others that would copy the rows into it. This would create you one core table to work from, but it would be disconnected from the others.

There isn’t a way to sync from multiple other docs and tables into one table automatically.

I’m sorry, I was just re-reading my comment and realize I wasn’t clear. Would it be possible if ALL tables were in the same doc to somehow merge various columns from separate docs into a separate table?

For my (actual) example, I have clients at various sites, with each site containing various elements. I am attempting to make a large table with all “demographic” information (e.g. date of hire, position, etc.) as well as unique values to each site (e.g. office number only exists at certain sites, and other sites have open office layouts and don’t need this information). That was a vague example, I know, but it’s a bit more complicated than that and the table is extremely large so I’m attempting multiple “micro” views.

Does it make more sense, in terms of database design, do have one large table where certain cells are blank, or to have 2 tables where all cells are filled in? My ultimate goal is to get various macro and micro views of my tasks/projects because I have 100+ projects (of varying sizes) going on throughout the year and losing track isn’t an option!

It sounds like all you need is the basic table and then views of that table that show only the info relating to certain values (like demographics) - all in a table and then you make new views in different section dividing it up to see the best of both worlds -

in your words, one large table with some empties is fine - you can filter those out of a view where you want to see only what is most relevant for that intended view.

am I understanding you right @Benn_Bennett?

its a problem when you get to having a monster amount of info - we deal with that and split it between docs only because of the size problem, but its still the right way to set up the information