Granular Permissions

I’m trying Coda and setting up a complete company structure, and this seems to be a problem.
We can invite specific members to folders at the workspace level - and keep others private. This is great for most cases.

Where it is breaking down is that we have many projects, and members should only be able to view the projects that they are part of.

Here is the initial prototype structure, with the intention being that all projects go into the Projects folder, each as an individual document:

However it appears there is no way to limit access to the documents within the workspace folder to individuals. Does anyone know a workaround, or perhaps a suggestion on a better layout?

If not - Coda devs is this on the roadmap? Thanks!

Replying to myself, so one solution is to put all the projects in another workspace, and then put each project into its own folder and set invitations as needed. I tried cross-workspace table syncing and it works. Not sure if there are other limitations yet.

This is a hack though and problematic:

  1. Doubles our plan price - we are starting small with coda and are a small company.
  2. Instead of just having a project in a doc, now we need to put it in a folder also.
  3. What if we find other doc-level permission issues in any other of the above folders in our workspace, we can’t just keep creating workspaces and adding paid plans just for permission access…

Would love to hear from Coda devs - is the intended solution? Forcing us to buy two plans just to be able to set permissions in a reasonable way, artificially segmenting our workspace (now we have to send two invites to users, etc), seems far from ideal.

I’ll try contacting support because we need to know what the plan is here so at least long term we can look forward to a solution. We could work around this for now by giving each project its own folder in the main workspace, e.g. “Project A”, “Project B” folders, but that will get messy fast.

Other than that though, after 1 day playing with Coda, I have to say it is so exciting, great job!

1 Like

You can make the Projects folder private, invite only those who should see all docs in the folder, and then individually share each doc with specific people.

They won’t see the Projects folder in your workspace even if they are members of your workspace but aren’t added to that private folder. Docs shared that way will display for them as not from any workspace. They’ll be on the list of All docs and of Shared with me.

1 Like

Hi Paul,

That sounds like a perfectly workable solution…wonderful. Thank you! I didn’t pay for a plan yet so was not able to try it.

I am in the process of filling out the various risky sections in the folder structure I shared to see if there are any other blockers. I found a couple bugs so far that I will be reporting, but otherwise things are going well - burndown charts, data sources and views, formulas all good stuff. And I expect things like cross-doc sharing to get better (bidirectional) over time, for now making do with the limitations.

It’s so nice to be able to define the flow just as we need it, and not have to worry about exporting data or using an API to represent things in ways that aren’t possible with preset tools like Asana, or even Jira.

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!

1 Like

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):

1 Like

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:

1 Like

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.

2 Likes

Hi @Jonathan_Solorzano,

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!

1 Like

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?

3 Likes

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.

1 Like

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…

3 Likes

Coda is not for creating an actual app

Oooohh if you knew, trust me, it is! :smirk::smiling_imp:

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.

5 Likes

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.

2 Likes

Another bump for granular permissions.

3 Likes

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?

1 Like