State of the Art: Coda Project Setup

Hey fellow codans :slight_smile:

I am starting a bigger project organizing my companys workflows.
We are a small consultancy and I would like coda to be our central work hub for:
A) customer and workflow information storage and retrieval
b) workflow guidance (what do I need to do for what customer today?) and (semi-)automation

Basically my vision is a living SOP (standard operating procedure).

Initially I wanted to go for the following setup:

  1. One Backend Coda doc with all tables that contains all information
  2. multiple frontend Coda docs divided by role / Tasks / other categories

My idea was to have all information in 1) and all workflow logic in 2) and work with cross doc to populate these workflows with information and to save data

My motivation behind this was to:

  1. ensure each workflow only has the information available that it needs
  2. make updates to the frontend easier by being able to copy a frontend doc, work on it and then “push” it to live by just telling people to use this from now on, without having to make sure all data is up to date, since all data is just linked and not saved in the doc itself
  3. Make information from one workflow available across all other workflows so I only have to save each piece of information once
  4. Make frontend docs smaller, easier to maintain and less complex by chunking in smaller pieces

But I very quickly seem to have gotten to a point that tells me, this approach might not be ideal. Cross Doc information transfer is slow. Canvas columns can not be edited.

So I turn to you, with the question:
What is the state of the art coda setup for a szenario like this?
Is there a way I can achieve my goals?

I guess I can achieve most of what I want with a single larger doc and a subpage setup for each role / task / whatever. The main question I have with this is the ability to update the frontend. What is a n efficient way to “try out things”, “update without disrupting ongoing work”, “pushing updates to the live doc”, etc.? How do you go about this?

Best wishes
Daniil from Germany

1 Like

Hi @Daniil_Lobko

It is very difficult to give a one-size-fits-all recommendation. Generally I try to keep as much as possible in a single doc, only splitting into separate docs for security reasons.

Here is a thread with quite a bit of detail:

As far as “trying out things” go, you can create a new page with the new layout in a hidden area, and then when everything is ready, make it visible to users. However, it will depend on how invasive the changes are that you want to make. If you are going to make changes to the structure of tables, remove fields, etc, then it may impact your existing layouts. But that would mostly apply to using Cross doc as well.

The best approach is to try out different scenarios with your specific setup and see how things work out before committing to a specific approach.

Gruesse aus Atlanta

2 Likes

hi @Daniil_Lobko my position is one main task per doc en connecting the docs via cross doc when necessary. So I would argue that a few docs per department are the way forward. This is how I do my work as Coda consultant.

The current tools like cross docs & sync pages are not perfect, but I believe improvements will come over time. The moment you keep main tasks in single docs, it will make it easier to improve and maintain your set up. To see the logic, you need to have a clear mental picture.

I believe in the good intentions of @Piet_Strydom , but I am afraid that his ideas often won’t work in larger organisations in which people need access to parts of information.

Cheers, Christiaan

3 Likes
2 Likes

Thank you very much for your considerations!
Right now I feel like the most practical way will be to set everything up in a single doc and treat pages the way I originally wanted to treat docs.
If in the future the need arises and cross doc features have developed to a sufficient point I will move to the setup that Christiaan has suggested (and that was also what I had originally envisioned)
Thank you guys so much for your input. You rock :slight_smile:

2 Likes

I think you are wise @Daniil_Lobko, to use a single document when starting out.

A big client of mine started out creating separate documents for each of their client engagements (using a template doc) and later added cross doc tables to share central data across the documents. But the complexity of this approach has become worse and worse as the years went by.

Many changes to data structures, formulas, or button procedures must now be replicated across all those documents. And cross doc tables are cumbersome and not highly performant. They also found that gathering data to create reports and dashboards is very difficult if the data needed is not in the cross doc tables.

So now we are re-factoring their processes to use a single document with each client engagement being represented as a (long) row in a big table. That row now contains all the details that were originally in the separate document. That row has many canvas columns, each containing the details that were separate pages in the original documents.

Canvas columns were not available when they started out. But now they can do almost everything we could do in regular pages.

To avoid that single table getting too big, we have devised an archiving system to make sure we only have the minimum necessary number of rows in the live document.

We still use the 3-tier architecture for the more complex projects, but each separate doc is focused on a separate group of users with very diverse needs, so there is little replication of formulas or buttons across the docs. All the data tables that are replicated, are implemented as cross doc tables vis the tier-3 Repository doc. But this structure needs advanced Coda skills.

So starting out with a single document, and using canvas columns to provide page-structured document-like interfaces does seem like a wise approach.

Respect
Max

5 Likes