Single Doc full of databases (then shared via cross-doc) or no?

I really liked this vid on doc structure and am trying to build similar to this when it comes to keeping my “databases” separate from the docs people are using.

But recently I tried sharing a doc with a few managers (employees) and they had access to everything, including the database pages in the doc.

So, now I’m thinking about building individual docs for each employee and using cross-doc to connect the databases to those docs. Then basically keeping all my primary databases/table in a sort of “Admin” doc they can’t get to.

Is that a good idea in-line with the most future-proof and intelligent ways to build out my team structure? It seems like there are so many limitations and possible pitfalls with relying on cross-doc to make all my “admin” databases available in all of the needed docs. But is there any better way?

I guess I’m asking for a coda-theory and strategy discussion on building out a “managers’ portal” type of structure and your thoughts on cross-doc.

(in my specific case, it would be for about 30 different managers and their respective store locations, plus a high level of 3 regional vice presidents and their respective regions, plus a president/all locations level of access or doc)

Thanks for anyone wanting to talk about it! :slight_smile:

Hi Ray,

Welcome to the community!

I have three words of advice: experiment, experiment, experiment. :wink:

You’re of to a good start watching Paul’s videos, but there is no replacement for experience.

As you have noticed, people either have access to nothing in a doc, or to everything.

You can hide pages, filter tables and in many other ways create a user friendly experience, but people can get to the underlying information in many different ways.

If people absolutely may not see information, cross doc is the original place to go to. But there are a number of packs in the gallery that addresses some of the shortcomings of the cross doc pack. Also, Coda is halfway through a major enhancement that will address the ability to restrict access to information…
The first 2 of 4 phases have been implemented. This allows you to embed pages in a new doc, and these are “two way” embeds, ensuring that changes in either end will reflect back. You cannot search from the client doc to the original, but people can still click through by following links.

How secure you need to have the information, and how much effort you are willing to put into it, will determine which route you follow.

I strongly recommend that you build two or three proofs of concept and test them out with your audience before you commit to a path.


1 Like

That’s a good idea- nothing will show me exactly what I’m asking like trying a few different ways to do it.

I don’t have anything that needs to be super secure- the info isn’t that sensitive, I just didn’t want to confuse people or make them have to find their own info. It’s exciting to hear that Coda is still actively devleping and improving. Love that.

I just came over from Smart Suite (although I was pretty amateur there as well). I love the idea that the database structure is probably on par with that, while giving me the ability to build a front-end (essentially) and share it so easily. Hoping to build out “manager’s portals” for each of our store locations, but wanted to build it in the best/most ideal way.

Really appreciate you chiming in. I’ve seen a lot of your responses throughout the forum. It’s cool to have such active people in here.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.