Please add a +1 vote for me as well.
Another +1 from me, thanks!
Another +1 from me, i need this, thanks!
Transparently, sub-doc sharing is a very common request, and one we’ve discussed at length (we’ve even Hackathon-ed potential solutions to it). The biggest challenge with Coda is that docs can be very interactive, and so defining how a “subdoc share” should operate can be tricky.
Some questions we have to answer:
- What should happen to views of tables that are not included in the share, or formulas that refer to other parts of the document?
- And how should we handle security for users that are creative at seeing everything that comes across to their machine - should we not transmit unshared data?
As we looked at some comparable products to Coda, many of them took shortcuts on these expectations, which we weren’t very comfortable with.
This is why we’re tackling this request in a few stages.
First, we launched cross-doc (with cross-doc actions) as a way to handle this for table data. Then, we started with what might seem like an unrelated launch, but is quite foundational: progressive loading of docs. We launched this as a performance improvement, but it’s also a key building block that allows us to start separating docs into parts, and not send all of them to the client. More to come as we build on this concept.
While we continue to think through this challenge, we’d love to know more about your desired use cases—please sound off in the comments! Key questions we’d love your feedback on:
- What types of docs would you like to share subsets of, and how would you describe the shared subset?
- How interactive would you want it to be (e.g. is read-only ok? would you want it to update when other parts of the doc updated?)?
- And if you’ve already tried cross-doc, which cases did that solve vs. not?
We’ll keep you posted on our progress here, and hope you’re as excited as we are for some big upcoming changes to our editor and overall product performance that help us get further down the road on the request to enable sub-doc sharing.
I take notes with my docs, with each page being a page of notes. I’d love to be able to share read-only pages with my classmates to take a look at my notes.
Hi Nathan, thank you for the update!
Regarding the interactivity, it would be great to have the ability to edit the doc from either folder, and have updates post in real time. The goal is to allow cross functional teams to be able to work collaboratively on docs that would live on both respective folders.
Don’t really care about interactivity for now, read-only would be more than fine for MVP. One more request would be anon commenting. Thanks for the transparency!
I’m very interested too in sub-sharing a doc, ideally with the same functionality you have when you normally use a doc, but with a limited number of pages.
Crossdoc can help solve some problems but if you really want to unleash the potential of a coda doc, you need real-time updates, otherwise it’s not as useful and It’s better to just split the doc into two different ones
@Lena_Webster +1 for improved page sharing permissions
My scenario: there are Projects in the document, each project has its own Design and Programming tasks, which are located on sub-pages.
I would like the programmer to see only his tasks on his page and some project settings that are displayed to him in the view and in the same way with the designer.
How “hidden” do you want the other pages to be?
Because the simple solution would be to have a page for the developer with a view into their tasks. It only becomes a problem if you want to simultaneously prevent the developer from seeing marketing tasks.
The document has a page hierarchy and this document has a Production page. I would like to show my programmer only the Production page and not show him the Design / Settings / Project / Marketing pages.
The Production page contains the Board view with Cards. Row / Card contains 20-30 fields and subtables with tasks. The programmer open the card to make changes. Production also links to the Settings table on another page. The Lookup Settings field is hidden in the card itself, and other fields through formulas display the necessary Settings data, so the programmer sees the data but cannot edit or navigate, which is great.
However, it can go to the Settings table via the document (
The option with Cross-doc also does not suit me. Since I would like to display data in the Board view, but Cross-doc only displays columns for me that are displayed and showed in the source table of another document. As I understand it, I need to enable the display of the field in the source table so that it is displayed in Cross-doc. However, in the Board view, all 30 fields will not fit into the card)
Here’s another scenario, for example. In the Projects table, I have access to various accounts, I would like only the Project Manager to see these accesses, but it turns out that my designer can just see them, which is unacceptable for me.
I tried to use Cross-doc again, I will speak in my own words and in my opinion it is terrible. I have been setting up views with a large number of columns for a long time, and now I need:
- Set up and create fields in the cross document in order to be able to enter new information.
- Explain to the programmer, designer, that after each data entry, it is necessary to press the Push button.
At first glance, it seems to me that the access problem could be solved in the following way:
- Give access to a specific page, as implemented in Notion for example.
- If the user does not have access to the page with the table on it, then he does not see the data of this table, but he can still see the data and copy it if you create columns with formulas that show specific information.
The Projects page has a Projects table with a Project Name column.
On the Design page there is a Design table, which contains the Lookup → Projects (name - Project) column, we hide it from the designer and do not give the ability to display hidden columns (this is already implemented in Coda).
The Design table also has a Project Name column with the formula Project.Project Name. And this information is shown to the Designer, since we configured the display of information using a formula.
Two years ago, when I was looking between Notion and Coda, due to the lack of a solution to this issue, I chose to work with Notion. Now tasks require much more automation and after switching to Coda I set up all the work for about a week, and everything turned out exactly as I wanted, but this problem is like a fly in the ointment in a barrel of honey for me. I really hope that it will be solved soon.
+1 here! I would love to share just one-page of a doc.
I think that people who will share this would probably not want to share the connections to the tables, etc… just the value of it.
For example, you may want the user to see the value of the cell, but not the formula behind it. Or maybe you could add the functionality for cross-doc.
Hello @nathan ,
I would like to share my use case: we record activities for a lot of people. There is a people table, there are activity tables, there are condition tables (like location, the wheater, etc.).
I have a page with a view of a table, it is filtered to only show activities of the logged in user. The table itself is related to a lot of other tables, which are stored in my doc, but not on this page.
I would love to share just this one page with a group of people so that they can see, upon logging in, all of their activities. They would have access to just this one page, but the page itself would have to pull information from all over my doc. By setting the proper locking scheme I can secure my table against unwanted changes. I am using this scheme already (for some users), but until I can make sure that users can only access this one page, I can’t roll it out to just anyone. I would also put some buttons on this page (or group of pages) that would register in some table that this user is online, or at a certain location, or things like that. These buttons would interact with tables elsewhere in my doc, but those table or pages would not be accessible directly by these users.
Likewise, my team has access to my entire doc, but I would like to prevent them from accessing the pages where my lookup lists and default settings are stored. If I make views of these tables (probably filtered) available to them they could change data in the main table through the views, but by making columns hidden and by filtering, I could control exactly what could or couldn’t be changed.
I am sure I am forgetting a thing or two, but that’s the direction I would like to see this go.
+1 to everything @joost_mineur said above.
One specific use case for me is sharing project updates with clients. I want to set up a page that shows them the tasks I’m working on, stuff they owe me, links to invoices that are due/paid, etc. All of these things would pull from elsewhere in the doc, where other clients’ info also lives (hence the need for single-page sharing and tight privacy).
In terms of permissions, I’d like to be able to say a “guest” (in this case, the client) would be able to:
- click buttons
- open and view cards
- filter using input fields
- vote on things via “reaction” functions
- make comments
…but make no other changes.
And I’m desperate to be able to share that level of permissions with a “guest” without them having to create a Coda account. I’ve found that currently-required step to be a major barrier for clients who don’t want to adopt a new thing in order to interact with my workflow.
+1 to everything you listed above.
I think there is a fundamental question to the doc…
For my case, I work as private tutor and also do blogging. In order to plan every aspect of my “online academy content” I write them down in a single doc (website design, marketing, course content, etc…) because I can access elements between different pages. Nevertheless, we cannot access elements from different docs.
I think it’d be great for the doc to be able to share just one page and its child content. About the content from other pages/tables/… you could just “paste-values” instead of referencing and making accesible the whole content.
Just a little reflection on this that may help on clarifying this Feature Request…
PD: it may also be the case that I don’t get the coda philosophy (just yet)
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.
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