), then clicking to “Add to doc” (or “Try it” / “Buy” for the Pro pack).
If you’re already in the doc, you can simply type the Coda command /merge then select the Merge Table (Lite) or Merge Table (Pro) Pack and click to Add to doc (or Try it / Buy for the Pro Pack). You can also open the Insert menu on your doc, then open Packs, then search for “merge” and follow the same steps.
You will need to copy the table links to configure the Merge table to merge the rows from these tables. The table links can be retrieved by opening the three dot menu next to the table in the doc, then choosing "Copy link".
You should get a link that looks like: https://coda.io/d/_11rndmchars/Page-name_suAbc#_lu123, that when pasted into a doc appears as the name of the table.
If the tables you are merging are themselves sync tables, in order to get the latest data you’ll need to refresh each of the tables that are included to be merged before refreshing the Merge table (making sure to wait ~10 seconds). Refreshing the Merge table will not in turn refresh the tables it merges!
If columns you want to merge have different names (that won’t be considered equivalent, see
) in the various tables included to be merged, aside from renaming those column(s), you could add adapter column(s) to the tables that simply copy over values from those inconsistently-named columns using a Formula, but name them such that they are the same across all tables. You can even hide the adapter columns (as long as you enable the Hidden Columns sync table configuration option)! An example of this is in the
If the merging requires some other custom tuning, you can always use the union merging to pull in all the columns, then add formulas to perform your own column-wise merging logic. An example of this is in the
You can tell which table a row was merged from with the Table Name property that is returned for all rows in the Merge table. Simply hover over any row “chip” (the little box thing) in the Merged Row column in the Merge table, and then find the Table Name property. You can also directly add it as a column to the Merge table by clicking to “Add column”! Pro tip: if you add it as a column, the Table Name can be used in the Merge table’s sorts, filters, groups etc., and Formulas in the table or elsewhere can use this column to choose how rows are treated based on which table they come from.
General sync table tips
You can create any number of views for a given Merge table
Refreshing any of the Merge tables (the base sync table or any of its views) refreshes all the others
This pack provides a sync table, referred to as the Merge table, that you configure to pull rows from any number of other tables from any of your docs. It will detect columns that share the same name across the source tables, and merge them together under a single column in the resulting Merge table. Each column in the Merge table corresponds to a set of equivalent columns in some or all (depending on the configured columnMerge, see Column Merge section) of the tables. This process follows rules to accommodate discrepancies in the naming of the columns (think upper case vs. lower case), and to resolve different column types.
Say you configure the Merge table to merge Table 1, which has a column named “Date” of type Date, and Table 2, which has a column named “date” (notice the lower case spelling) of type Date and time, the resulting Merge table will have a single “Date” column of type Date and time, which is how we would naturally expect the merging of those two tables to occur. This process follows rules to merge any tables together in a predictable way, which are explained in
There are a few special columns that are always included in the resulting Merge table, representing metadata to keep track of where the rows were taken from. These columns will overwrite any equivalently-named columns in the tables included to be merged.
“Row URL” is an absolute link to that row in its source table
“Row Name” is the name of that row as specified by its value for the display column in its source table (even if that display column was not picked up by the merge)
“Row Link” is a Mardown-formatted link to that row in its source table, with the “Row Name” as the link preview, and the “Row URL” as the link URL.
“Table Name” is the name of the table where that row was pulled from, which can be used to discriminate the row’s type/provenance
The “Row Link” column can be added as its own column in the table, to support use cases where having the default sync table row
as the display column is not desirable because of the different UI this presents (which includes the pack logo).
Is this pack right for you?
The motivation for this pack comes from the common use case of having neatly structured data in various tables, where the share several columns in common. These similar tables would benefit from being viewed together, but are just different enough to warrant keeping distinct, or it is somehow impossible to combine them.
These are the main use cases this pack enables:
I have different tables that serve the own purposes but share some similar columns, and I want to combine them all into a single table, so that I can view those similar columns for the rows of all those tables together.”
I have many different copies of the same (or very similar) table distributed across different pages or even different docs, and I want to combine them all into a single table, for presenting / bookkeeping / external integration / analysis.”
Much of this is discussed in this community topic, which sparked the creation of this pack:
) could be having tables for Tasks and Projects. Both might have names, dates, people (assignees or owners), priorities, and any number of columns in common. There are very valid reasons for keeping the data in two separate tables. For one, conceptually it doesn’t make sense for two completely unrelated concepts to share the same table, merely because they have some aspects in common. It also makes managing any logic on the table, such as formulas, defaults, conditional formatting, etc. quite unruly. On the other hand, having them both in the same table would enable viewing all the tasks and projects together, for example to see all task and project dates in a single calendar, or view the tasks and projects for a person.
It might sometimes make sense to combine the tables, maybe because the concepts are similar enough, the data complexity is low, or there is no logic applied on the table. To avoid having to combine the tables, the only other natively supported ways to remedy this are:
Build a formula that reads the rows from each table, extract what is relevant (or common), and generate new rows in another table that mimic the original ones
the data by factoring out the commonality into a separate table referenced by each of the similar tables
The first approach requires writing a fairly complex (and highly domain-specific) Formula that reads all the rows from each table, extracts the relevant (common) columns, then creates new rows in a separate table (which you would also need to create), with back-links to the original rows in their tables. It can be done, but it’s non-trivial and requires abusing the column reference types to get to a tenable result.
The second approach requires completely redesigning your tables as well as re-creating the rows (same goes for combining the tables, especially tedious if there are already many rows).
In fact this pack pretty much implements the first approach, although without needing to handcraft some complicated Formula to implement it.
Similar tables that cannot be combined
There are also a number of use cases where data is actually pulled from different data sources, and cannot be redefined to a single table. For example, one might have many docs for many clients, each with their own Invoices table (for security reasons). Visualizing all the invoices in a single doc would require using the
to pull in each of the Invoices tables individually, with no straightforward way to collate them into a single table. For such use cases, where the number of such similar tables grows quickly, the first approach is not practical, as it requires creating a new Cross-doc table and modifying the formula each time a new client doc is created. The second approach would also not be applicable.
Some of these features are only available in the Pro Pack, see
Interoperability with ✨ Cross doc ✨ and other Sync Tables
This Pack supports merging together Sync tables from the Cross doc Pack. It will also automatically strip out the “Row” identity column from the resulting merge table (unless it is no longer the display column) as it is usually redundant. Note that if your goal is to merge tables that are found in another doc, this Pack already supports doing so without the need for using Cross doc sync tables as an intermediate.
The same applies for merging together other Merge tables, where the “Merged Row” identity column is omitted if it would not result in losing the row’s display name. Note that if your goal is to merge together more than two tables, or merge such that all the columns (even those not common) are picked up, this pack already supports doing so without the need for using multiple Merge tables, with the Table Links sync table parameter, and the Column Merge sync table parameter set to “union”, respectively.
Lite vs. Pro Version
This pack is distributed under two different versions with their own Pack listings: the
and in the sidebar menu when configuring the pack’s sync table.
Unsupported column types
Columns of the following types will always be omitted from the merge:
This is because a) the Coda API used to retrieve the row data does not provide enough information for values of these types to recreate them, and b) Coda Packs do not support returning information in these formats in sync tables. See
Columns of the following types will be included in the merge, but will not include the column metadata:
Formula (i.e. columns that use a formula to produce their values)
Columns of these types will be treated as no more than the value in the cell of the rows for that column (the selected Select list option, or the value produced by the Formula), but the column type-specific information will be discarded, such that the resulting column in the Merge table will appear simply as the selected/produced values in their resulting type (as resolved). As such, there will never be any columns in the resulting Merge table with Formulas, or of the Select list type.
This is because Coda Packs do not support returning information in these formats in sync tables. See
. This may change in the future, although unlikely.
A special case is Canvas type columns, which will not lose any metadata per se, but will appear in the resulting Merge table as Text type columns (with the canvas body recreated as a best-effort, YMMV). You can opt to change the type of the resulting column back to Canvas.
Pack sync tables do not support lookups for non-Pack tables. This means that columns in the resulting Merge table cannot lookup other tables in your doc. Any lookup columns in the tables included to be merged that are picked up in the Merge table will appear as broken lookups by default (same as in Cross doc tables), or can be set to appear as links to the looked up rows in their source table for ease of navigation.
Most of the discussion surrounding this pack and its development can be found on the Coda Maker forum under the topic here:
Feel free to join in on the conversation, or share your use cases elsewhere in the community. Additionally, if one of your doc makes use of the pack and can be showcased publicly, please make sure to publish it so that it can be highlighted in the pack listing for others to see!
If you have any questions, concerns, or problems while using the pack, feel free to comment with your situation on the