Data sharing between docs

Suggestion Box
1

@Coda_hq

Thank you for the bringing us 4.0. I am looking forward to working with the new options to enrich and enhance my documents.

Coda has many beautiful features and can be extended almost beyond believe - even without using custom packs.

I am an active member of the Coda community and I have seen a lot of suggestions (or critical remarks) about layout, simple tables, spacing and even though I think a lot of these postings make a lot of sense, I really believe that some expectations are unreasonable: Coda is not a page makeup program, it is not a spreadsheet, is is not document storage system, etc. etc.

But Coda is a lot of other things and with some perseverance, you can build incredible things app like documents. CRM, planning, financial proposals, forecasting, calculating, mailing - the only limit seems to be your imagination. Looking at all the old and new functions and features and reading about what is coming I feel that Coda agrees that it wants to be a lot of things for many users and makers.

I never really liked cross-docs all that much, but with 2-way sync as a new option, it opens up a whole new set of possibilities. In particular the option to have almost real time syncing back of edits to the source is wonderful.

However, the sync to the target doc is going to take up to an hour if you set it to sync every hour. If the source table has cross doc relations to multiple documents where 2-way sync is activated, you almost know upfront that there will be sync errors someday in some doc.

The refresh rate of every hour seems to me like a waste of resources, but above all, very impractical. Why not sync to the target doc upon any change in the source table. There is also the issue of the 10K row limit. You have to actively monitor your tables to see if they go over the limit. I could understand why there would be a 10K limit per batch, but it’s an absolute max. 1 row over the limit and your new rows won’t sync. Considering the above, I feel that (2-way)cross doc will serve some people, but it is not what so many of us have been waiting for.

About the sync pages: I thought I was desperately waiting for step 3. I think step 3 will indeed be useful for a number of situations, but it will not be the answer to sharing, for example, items like proposals and invoices. Perhaps if you have a handful of clients, but not if you have quite a few more. A sync page can hold a filtered table, but it has to be filtered at the source. This means you have to make a view of your table for every client and you have to make a separate doc for every client to present the (correctly filtered) synced page. On top of that, the target doc has zero interaction with the data on the synced page. This makes it of very limited use.

I think there are two solutions:

  1. authorizations on sub doc level, as you already whispered about. I understand the complications, but it would solve a lot of problems since it would allow you to filter tables based on the user accessing the (limited number) of shared pages.

  2. a new table option in the source doc: interdoc yes/no (or whatever name you decide to choose :grinning:). It would allow all makers with access to the source doc to show views of this table in any other doc. If the table depends on other (relational) tables, they would have to be set to interdoc as well. I understand the complications, but it would free us of so many of the workarounds - it would allow for filtering based on logged in users and many other things.
    Access to a table with the doc users would help (it can be done through a pack, but native would be better) to allow us to make extra columns with unique ids, authorization levels, some logging history and whatever else we can (and will) think of.

Sub 2) can be accomplished to a great extend with webhooks, but it is error prone and a lot of work to accommodate for deletes, backup, etc.

I like sub 2) best - I can even envision a doc just holding tables (and functions) with subdocs for makers, subdocs for management, subdocs for users, etc.

Having said all this - I love Coda and I can do more things better and quicker than ever! I also think Coda is the extremely fair priced, at many other platforms you have to buy a seat for each editor. And the number users is often limited to. Or projects are limited. Or all of the above. I think it is totally fair to charge for maker seats and have a few limitations for editors. Coda has chosen for add pages, that is something you can overcome - or if you are a bigger company, getting an extra maker account should not break the bank.

Kind regards,
Joost

3 Likes
2

Because that would require an event broadcaster and event handler. I’ve been recommending exposing events to CFL since 2019 and Packs since 2020. No movement on this idea, although Coda obviously uses them internally.

Have you considered a Pack that broadcasts changes to target docs via webhooks? It’s not an easy pathway, but it does work and the latency can be as quick as 30 seconds.

1 Like
3

Hey Bill,

I agree with what you say in the 1st paragraph - therefore it should be feasible for Coda to build upon that idea.

about a Pack that broadcasts changes: yes, we are doing that now, but it requires every setting (locking, no deletes) to be exactly right. You have to write routines for syncing deletes, use extra columns for housekeeping, etc. Coda has most of this in place already, so I hope for a native solution.

But honestly, I hope for the option that would allow us to use views of tables in other documents. These type of views (interdoc views) would be like a super 2-way cross doc without the overkill of syncing stuff - looking at the interdoc table you are looking at the real data. It would require some careful naming conventions of your tables, because interdoc tables should not have the name of existing tables elsewhere, but I am convinced that the makers that are going to use this will manage.

3 Likes