Is it true that if you share a page, you’re sharing your ENITRE doc? Is there any way to only share one page without them being able to everything else you’ve got in there?
Hey Kelly - thanks for posting! Unfortunately, there isn’t currently a way to share just a single page of a doc. This is definitely a commonly requested feature, so I’d be happy to add a “vote” to this on your behalf
Some possible alternatives in the meantime…
- You can use locking to limit what viewer can see/do on each page, but this won’t entirely block them from viewing the page
- If you don’t need pages securely blocked, you have the option to hide pages.
- Finally, some folks use cross-doc to sync certain tables out to new docs, then they grant access to just those new docs.
Sorry for any inconvenience - but thanks for sharing your idea
+1 to improve page sharing and cross doc access. Also moving pages to other docs is a real pain. In this regards, I would hope for a structure like in Notion. One workspace with pages which would equal One doc with pages in Coda.
@Lena_Webster - can you add a vote for this on my behalf as well please.
How exactly do i vote?
can you add a “vote” on this for me aswell?
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.