Essentials: Doc Structure

[@mr.octopus-plag]

Great, now let me watch again but this time taking notes

[@marandaroth5604]

This was very helpful as I'm starting with Coda. Thanks!

[@TheOriginalCatfood]

Notes: 8:47 Use specific icons for certain tables. What icon makes sense to me won't necessarily make sense for others.

[@hugoassuncao]

Just applied this structure to one doc... and will be doing it for many more.

[@brenocn]

I've been using these best practices for years now and have never looked back.

[@musyaffasb]

very useful, thanks a lot!

[@evelynedelcourt3533]

thank you so much for this video!

[@seun-ohm]

Super helpful.Thanks!

[@fabienhammerer3588]

Cool video! Started using Coda a few months back and constantly amazed at all its potential regarding workflows. Looking to make it more of a base tool for our workflows and this video is going to be a great start. Cheers!

[@cmonmeow]

Great presentation. I'm relatively new and this really helped me, especially coming from notion where things are close but not exactly the same. btw, I didn't think the tempo was too slow like you mentioned. You cover a lot!

[@brianroehrich8228]

I really appreciate this video. It's so helpful to have someone explain best practices, especially when trying to self educate. Id love to see more content in line with this video. best practices for: writing formulas setting up tables, cross tables, and sync tables deciding what type of column is best suited for different applications different/best ways of connecting data between tables and i know you touched on front end here, but i would really like to learn more about how to make the app clean and easily understood for users both on pc and mobile, especially because i find myself feeling limited with what coda can do with a front end design. if you have any references for learning these things please share! Thanks!

[@OrangeBookClips]

take all notes. thanks paul

[@AndrewMalcolmson]

Drag a table by clicking and holding on the three dots menu. Wow, how did you discover that?

[@CodaTricks]

I don't know 😅 I guess I just was around when they made that feature and included a gif of it in their community post ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

[@yurijmikhassiak7342]

Great video! Unfortunately, you will need to hide columns in the base table and default modal layout if you don't want users to find them in search.

[@CodaTricks]

It's the search that's broken then. We already have a discussion on that in the internal Coda slack. Universal search already can reach into all the data in the docs, hidden or not. I'm yet to say this on this channel but I'm saying this at least twice a month in the Community - filtering, locking, hiding etc are not meant for security. If a doc is shared, it's shared in its all entirety. Same applies to search and api. The only way to really restrict access to certain data is to have it in a separate unshared doc, and only sync it through crossdoc, Sync Tables Pro, or push through webhooks etc.

[@yurijmikhassiak7342]

@@CodaTricks Paul, your view is poisoned by your programming experience, 99% of usecases in an average org does not require strong protection against bad actors. But we need to protect against people accidentally finding info they should not see. I was able to achieve what I need with hiding columns and changing view layout to protect against "Global Search issue" and link to the source table in every modal. It also helped with exposed subtables.

[@CodaTricks]

I disagree on security, but that wasn't even my point to start with. The side effect of not hiding columns is that they appear on the @-reference popup. My point was that it's not that the idea to unhide columns was wrong - it's that the popup was broken. Same with the universal search: if we can't control what shows up in the search, it's the search that is broken (also IIRC it would find you the hidden tables, rows, and values even if you hide them.) Call my view poisoned but in the end of the day we all use the software that is created by programmers. It bloody helps a lot to have that experience and thus know how a piece of software might work internally and what to anticipate, rather than just trust the docs and get massively surprised when one's org data gets leaked 🙂 That said, happy to know that you find workarounds that are sufficiently good for your use case. As I just wrote under some other video, there's the handbook-right stuff and then there's common sense and doing what's viable and good enough.

[@Brian_Cox]

Do you recommend putting all DB Tables in one doc if using cross doc for different use cases? I am setting up a "work orders doc" that needs to reference customers information in my main doc. Should the "Work Orders" table live in the main doc or the doc it will be used in? (I need to use a cross doc so that the person using it cant see sensitive information in my main doc)