Coming from Notion - how to create mirrored (view) table across all docs?

I’m looking at moving to Coda from Notion (and docs in Clickup).

One feature that I can’t seem to find is creating linked database that works across all docs. One of those features that I assumed that would be a given in Coda. :woman_facepalming: (Here is the explanation in Notion.)

For example: I have a team database (table) in the Company Wiki doc and I would like to use the same table in another doc for HR.

I have seen how to make views. But that seems only to work in side the same doc. Other than this video on syncing tables, is there a way to easily sync tables across docs that don’t need elaborate webhooks hack?

Is there a simpler or more elegant solution that I am overlooking?

Thanks!

Oh yes! That’s my video - it’s a much more technical and complex way to create two way syncs and not necessary for what you’re trying to do.

For now, your answer is cross doc. Cross doc is a pack (codas word for integrations) that allows you to pull in two way editable databases from one doc into another.

Now, there are some drawbacks to cross doc, but I cover everything cross doc in this video here

Overall though - in switching from notion you are going to need to adopt a new narrative. Coda operates under a document model while notion more aligns with a interconnected wiki type model

So you won’t find that same level of inter connectedness you would with notion.

Think of docs like little apps - if one app shares a lot of overlap with another app/doc think about making it one doc to start with rather than separate docs in the first place

There’s lots of others in this community coming from notion as well though! Maybe @Piet_Strydom or @Xyzor_Max can also shed some light.

2 Likes

Thanks Scott.

@Anastasia_Grahn - my first stab at this topic is always to ask why are there separate documents?

If there is a clear reason to have multiple docs, you have a few options, depending on your needs:

  • traditional cross doc.
  • Scott, Christiaan and Paul all have paid providing some kind of functionality in this area.
  • Coda is making progress in developing improved functionality around syncing and embedding.

The last option is highly anticipated, but will probably not be here in the next day or two, but hopefully some time this year.

Regards Piet

2 Likes

Hi Scott!

Thank your the elaborate and clear reply. I am at the tail end of binge watching or saving all your Coda videos on YT. Great stuff - thank you.

After my post, I did ask myself that question… do I need to adjust how we silo our info on Coda? One of the top reasons I like Coda is I was able to keep our information more “clean”. Our Notion documents have just gotten so … unruly.

I’m going to step out of the trees and checkout the forest. See if I can make the team table work in one doc - keeping the solution elegant as possible.

2 Likes

Thank you Piet!

I am going to deep dive a bit for inspiration on how people have structured their docs for a company.

One thing I was trying to accomplish was to have a contact button on each row of a table of SOPs for the lead person of that SOP. (Via WhatsApp or email). And a master team DB with their contact info. Use a relation to pull their WhatsApp number for the button input.

The original database would live in the folder / doc in HR - as that department would be in charge of updating the database.

As a Coda newbie, I am assuming I am taking the long hard way to do something that would have a simpler solution. :hammer::axe:

Thanks!

Hi Anastasia,

My pleasure.

One of the things that I go on and on about, is that you need to learn to think in Coda.

I have a couple of posts in the Start Here channel on that topic. When I get to a laptop, I’ll post the links.

Happy building!

Hi Anastasia,

Here is a link to the post I talked about above:

It is just an encouragement to experiment with Coda. There are no right or wrong ways to do things, although sometimes some ways may be better. I have one or two very early docs that I look back and chuckle, but what I did worked even If I would build it very differently now.

But that was a very simple doc. My big doc I have re-invented several times over the years. EVERY TIME I have moved more information that used to be in different docs, into the main doc.

As for your specific comments on the People database/table and the contact details. I would try and keep it all in a single table, in a single doc. If there is a need to store confidential information, then add that confidential info in a cross doc.

P

2 Likes

Hi @Anastasia_Grahn , wishing you tons of fun as you explore all the power that Coda unlocks (the potential pitfalls and frustrating rabbit holes will automatically come along for the ride on your discovery :-).

One thing I wanted to draw your attention to is that Coda also offers templates. While I wouldn’t recommend a tempalte for a dynamic use case (where you expect your data to change often), I think it would be a good approach for the use case you outlined.

Here’s how it works:

  • Create a template like so, and within it, store your team’s contact information (ie Phone number, Email-Address, Name, Responsible for which SOP, etc)
  • Then, within your specific Coda doc, simply type /TemplateName to bring in this table. Et voilá, you can now use this tabular data to set up your automation, allowing users to reach out to the person responsible for the SOP.

Nina

1 Like

Thanks Nina!

That’s a great idea. Out of the box solution that I can use.