If I could build just one pack in my lifetime, it would be this.
Almost all my clients asked for this. There’s a dozen threads in this community where a fair hundred of makers asked for this. I asked for this. Now I built it myself.
I called it Cross-doc Plus. This is a code name and I would easily change it if Coda tells me to. The pack includes some features that the original Cross-doc couldn’t include.
It will be a premium pack (tentatively $3-5/mo per maker) and I’ll launch it as soon as Coda launches the paid packs platform.
What it can do already:
Swap the source: Tables can have their URL changed without having to reimport anything. This will allow to build templates of multiple connected docs, e.g. a Freelance Work Tracker with Individual Client Docs. You’ll copy the template, set up new URLs and voila!
Row-level security: Share subsets of rows from a common view with flexible access rules. No need to create one view per client anymore.
Union tables: Combine multiple tables (from separate docs!) into a single sync table with a flexible query.
A video is worth a thousand words:
It also has a lot of subtle improvements over the stock cross-doc, which I’ll tell you later in a more detailed article.
And there’s more where it comes from. For instance, I have an ambition to implement Push tables — a mechanism that would sync two editable tables and apply changes from one to another and back. It would be limited at first — mostly because of the limitations of Coda’s own API for upserting rows. But it will work for many common scenarios.
These two are sweet! We’ve started encountering use cases for these. The table source swapping is a general feature I would love to see Coda introduce, even for regular View tables.
Here Paul addresses some must-have functionality to enable Coda as a truly powerful document management framework in project-like and consultancy-like business.
This is the #1 pack, in my opinion. Being able to centralize document management, while automatically take portions of its data to show my customers and contributors without having to manually edit their documents is just what i needed, for long, long time.
I would pay for this, and am especially interested in Push tables if you can get that to work. Although I wish I didn’t have to, that and such functionality came pre-baked in vanilla Cross-doc.
There are good reasons why these couldn’t be in vanilla cross-doc but could be in an addon created by a 3rd party. As an insider I know how Coda approaches designing their features, and trust me, adding these into vanilla cross-doc would be more of a problem than a blessing.
TL;DR, the expectations are lower of 3rd party addons than of officially made packs and features. Hence it’s easier for makers like me to make opinionated decisions and basically say “wanna use it — deal with it” rather than try to make a neutral and universally understandable solution.
Row-level security: I could just tell people to create a specifically named column and define the new syntax for row-level rules. No way Coda would do that — they would have to create some absolutely new UI for setting up row-level security more visually. Then take into account all the documentation, training, all the support efforts etc. Make the feature discoverable. Think of the migration from older cross-doc version to newer cross-doc version. All of this clients would expect from Coda but not a separately created pack.
Same for queries. I could easily create a whatever query language without giving it much thought. Coda wouldn’t do that without considering all the implications. Most likely they wouldn’t create a query at all (because it’s too technical) but have to come up with yet another UI for selecting tables for merging and then mapping their columns.
And same with swappable sources. While I agree this should be a part of the core offering (to support templates but also let people re-link cross-docs in case their source docs are compromised and they have to revert to earlier versions — which creates a doc copy so relinking is necessary in that case), this is also problematic. Coda already built its security system around the idea that for each imported table a new token is created. This guarantees that whoever imports the table can be sure that through that connection, only what they imported can be loaded but nothing else. Remapping the source would imply surfacing an intuitive way to make new connections with tokens to just those tables. And since it’s Coda, it can’t just be a list of technical instructions like “go and create a new connection yourself”. Most people (including me) would just go and create access-all tokens with no restrictions and use those, potentially compromising data security. In my pack there’s mandatory row-level security on all tables, through which one can make sure that a person with a certain secret token can only access what’s surfaced for that token. This way, no individual connections are required and everything can be accessed through one account.
So yeah, in general it’s the safest for Coda to keep vanilla Cross-doc the way it is — useful and simple just enough for most of the casual cases. And for all of these extra scenarios, that’s exactly why they opened up the packs platform to 3rd party makers like me
Thanks for the insights Paul. And yes, I guess I do belong to the minority of extreme tinkerers who are not afraid to trade simplicity for functionality sometimes. Hopefully the expanding pack ecosystem will cater more to us folks.
On another note, do you plan on including more robust syncing features in your pack? I am dying to have the ability to initiate a sync of a single row form within the cross’ed IN table via button click for example.
That’s a great idea and I think it may even be possible — there’s a mechanism in Packs SDK that allows updating one row in a sync table upon an action (e.g. replace an item that has just been edited) So technically I can make an action that does nothing but updates a row. I’ll explore.
Update: no, not possible apparently because of the dynamic nature of cross-doc sync tables. The structure of those tables can change table to table, and that mechanism I told you about needs a stable schema.
Maybe they’ll add this capability later. There are some foundational changes lately that could enable this.
That was a bit of an emotional rollercoaster , thanks for investigating.
!rant!
I run my business on coda and use Cross-doc as a band-aid, in the absence of the ability to create “views” of a single doc, one for each user role.
I can get around the fact that Cross-doc is not true two-way sync with some - extremely hacky and brittle - tricks. But I could never get around the sync delays and the bafflement it causes colleagues who are working at the same time on two sides of a cross-doc’ed table.
I really wish Coda allowed me to fully embrace the monolith, and have subviews of a single doc dedicated to each of my teams.
!rant over!
I logged them a feature request for that. Let’s see if/when they add it. They’re currently working on some fundamental changes that should make it much easier to implement that feature request as well. Packs SDK is still new and they’re still working on it. It takes some time before people start building packs and running into obstacles, and only then one can see what else can be improved. The team behind the packs SDK is very capable and very open too.
With this feature or not, I’ll eventually (maybe in v2) add the push sync between two local (editable, non-sync) tables. This requires a bit more of engineering: in the context of paginated loading I have to come up with a diff mechanism that would apply edits from A to B, from B to A, and then somehow also resolve conflicts.
There are architectural limitations to why it’s not easy to just share individual pages or publish sub-views of a doc. I discussed it a lot and Coda discussed it too. And I doubt that e.g. Notion has it implemented properly. I am nearly sure that if I were to investigate the security behind Notion page-level sharing I’d find that a lot of context leaks along that page. Sure, average users would be happy and cheer for Notion and criticize Coda for not doing this because they wouldn’t know. But hackers would see portions of the doc that weren’t explicitly shared with them just by digging a bit deeper.
Love your pack idea, and can’t wait for Coda to enable paid packs so that I can pay to get my hands on this pack The query table in particular is gold to me.
I was thinking on whether one could automate the creation of the view for Out tasks (as most clients would probably not want/remember to do these themselves. But an easier solution would probably be to set up the view for the OUT-table on the client’s side when preparing the doc for client’s use.
Thanks! This is also part of that opinionated design — I want users to be very mindful of what they’re exposing through the pack. Hence the requirement for views, not base tables: a client has to explicitly create a dedicated view and set up all the columns they want to show. If it were a base table, it would be prone to exposing newly added columns (the client would forget to hide them), tweaking filters and so on.
The idea with those views in client docs that you’d then query is that you don’t create them manually in each client’s doc — you prepare a template doc with all the dashboards etc and that OUT view, and only then you copy the doc for each client. This way all the docs will have the same View IDs to use in the query formula — you’d only have to substitute doc IDs. If you generate doc copies automatically through Coda API (directly or Make/Zapier etc) you’d have those doc IDs automatically populated e.g. into your table of clients.
Thanks Paul, happy to be a beta tester of Cross-doc Plus if you have the need for that.
On the topic of page sharing, I don’t want to hijack this thread but I have a strong view that as a community we’re going about this backwards. We should leave secure data sharing to Cross-doc (and Cross-doc Plus ) and just push for Doc Locking on steroids for within a single doc.
Think of a “Hide if” option for each page that takes a formula, a similar “Disable If” option for columns that makes them read-only, and so on. Doc sharing remains unchanged, so we keep the working principle that sharing a doc with someone means they can see everything if they are motivated. But it gives us makers the tool to make more user-specific ux from within a single doc.
@Nad I really like your idea. Having the option of using a formula to determine row-, page-, and/or column locking would be incredibly powerful. Hopefully Coda implements this!
@Paul_Danyliuk I’d love to beta test your enhanced cross-doc! Let me know if you’d like some input. Similar to you, I’m a power user who has created some pretty advanced docs, so I might have some useful feedback
From now on, the pack will be called Advanced Doc Connections (or ADC for short).
As much as I wish to keep Cross-doc Plus, it’s going to do more harm than good to people confusing it with the regular Cross-doc in the Packs list and the / slash menu.
Also I’m adding more features to it and hoping for a close launch. Stay tuned!
P.S. If you have any better ideas, I’m all ears This is not final until it’s published anyway.
I’m a college teacher and it seems this is exactly what I’m looking for.
That is, I want to give students and teams (private) grading feedback on assignments (‘simple’ assignments, as well as papers, incl. multiple drafts of a paper, etc.), but also allow fellow students to leave publicly viewable comments. Also, a place where students can mark assignments when they’re done, and where I can give feedback, all in one place…
(I’m new here, so if there’s a better way to do this, I’d love suggestions!)
The query table in particular is gold to me.