These are great notes on what the wants are for permissions and also great use-case examples. There are quite a few questions about how to handle the smaller details of permissions like these and some solutions take more work than others. These examples give us a good direction to work with though.
Thank you all for the feedback!
FYI @Ed_Liveikis you can have bidirectional cross-doc already. Not ready for prime time yet and not widely announced, but not hidden either and kinda works (see gotchas):
Great @Paul_Danyliuk - yes I’d like to do the master, single-schema data sources common project management data structures that can store all goals, tasks etc for all projects, and the have filtered views within projects with permissions ensuring that only the project-specific data is available to permissioned users.
One major goal this would help solve is a master “My tasks” list that can pull data from any project. This is also something that is not possible Notion at all - so a competitive advantage opportunity for Coda.
I’ll probably wait until this is ready for prime time, at least for now since I’m also knee-deep in learning all the other basics, and I have the option to “push” project-specific data up to a aggregated (modifyOrUpdate) table via buttons, as illustrated in the post:
Can any Codan clarify if this is in the roadmap? To me this is very important since we want to keep some document sections private in our information system.
This is not on the immediate roadmap. Just to reiterate, these features are not necessarily security features. A user can copy a doc or craft a formula to access data in a doc. If you have sensitive information that cannot be shared with others, I would encourage the use of cross-doc where you keep that private information in a separate doc all together and only carry over the information you want to share.
Hi, you’re definitely losing some Business Cases here, I was just looking for better granularity and to just don’t allow the document to be copied, as per: This Other Question
Because even within the same company, you want some parts of the process to be editable/viewable by some and some parts don’t, even if data is in the same master table. Was my use case here (for the company I work with, with plenty of process and possible makers)
There is maybe a workaround for the access per column, dividing a master table in more tables per group of access rights for this (IDK) but this heighten up the bar for makers (more learning required) and don’t solve the copy issue, still, this is a very nice platform, looking for more ways to use it!
Cross-doc is all good and well for sharing data, but not for app functionalities, which is Coda’s sales pitch “a doc as powerful as an app”
As long as there is no two way sync, then the use of Coda is extremely limited with cross doc. And it’s just another doc, not an app.
Please tell me you’re working on this?
We do hope to improve this one day. It’s not on the immediate roadmap at the moment, but we do consider this version of cross-doc our V1.
And no, Coda is not for creating an actual app, it is a doc and it’s a doc with app like capabilities.
I am so sorry… If not this feature, then which one? As mentioned above many times, one of the most missing feature is giving granular access… This is also the main philosofy of many applications. Build once use many…
Coda is not for creating an actual app
Oooohh if you knew, trust me, it is! 
I wonder if there is any progress regarding this suggestion? Granular permission is absolutely a much needed feature, it will solve many of my problems with Coda.
This is something we discuss a good bit, but it’s also not an easy thing to implement. It’s in our notes and we know it’s a wanted feature, but it’s not a project yet.
At the moment, Cross-doc can offer a solution for sharing only certain things by syncing data to another doc that you can share more broadly while not giving access to the current full doc.
Still looking at the pros and cons for coda vs notion vs airtable
I am a small business owner and been evaluating between these apps. Not being able to share a single subpage, or having to go through tedious workaround has defeated the purpose of coda.
I do like a lot of the advanced referencing features of coda and the API, but not being able to share limited information is a real dealbreaker.
Looks like notion wins hands down on this.
Just following up here. @Paul_Danyliuk and others have helped to guide me in the direction of thinking of Coda documents as…individual documents, not more. With this mindset, the permissions are comparable to sharing other types of documents, like a Google Sheet, which also don’t offer lower level granularity (e.g. Google sheets do not allow individual Tabs to have individual sharing or permissions).
However in Google Drive, you can have complex folder hierarchies to store documents and control permissions.
I believe this is on the Roadmap, but having subfolders in the main Workspace view, for docs to go into would really help with permissions without requiring changes to the permissions within a doc.
Another bump for granular permissions.
I’m being forced by the rest of my team to move to Notion because of the lack of this feature - Notion has group permissions as well which is super handy. Any updates?
Any updates? This is becoming an issue for us as well…
We need this as well very urgently!
Hi everyone! We have what is hopefully some nice progress in this area. Starting today, you can copy a page to a new doc, and adjust the sharing settings of that doc so that your new audience only has access to the new page in the new doc.
Learn more here: Launched: Copy a page to a another doc
Hello @Andrew_Stinger ,
Although I am happy with this new copy option, I don’t think is solves what is asked for (and needed by so many people): the new functions makes it possible to make a new doc in a hurry, but since it is completely independent from the original doc, we now have to maintain one more doc.
Since the power of Coda is that pages can have dynamic content based on other pages, the new doc needs (in many cases) to be connected with cross doc, which is not that great of an option in many situations.
I am sorry to have to conclude that this is not really a step forward towards what is being asked for in this thread.
Greetings, Joost