Hello @Roger_Hu ,
After some more testing I can confirm this works exactly as you said. Which, I kind of regret…
I am sure it will find useful applications, perhaps mostly in larger organizations.
But what so many of us are desperately waiting for, protected sharing of partial documents, is not here yet.
Greetings, Joost
I love the feature especially for bringing together separate Google Sheets!
My big pain is that I have to do it one by one. Is there any ways to add multiple Google sheet links at once with the full page embed??
Thanks!
This!!
Like Joost said, I guess some people might find a usecase for it, but this is not the feature we’re so desperately waiting for for multiple years now.
I’ve filled in multiple surveys about this and had e-mail exchanges with some Codans, but unfortunately so far… crickets… 
Excuse the rant, but I’m becoming more and more annoyed by the lack of progress, or maybe the direction of progress. Instead of addressing some obviously lacking features Coda seems to prioritize adding new shiny clutter.
Worst of all, we don’t get a timetable of what they are working on so I don’t even know if it’s worth to hold my breath until these issues are finally addressed, or if I should just move on from Coda all together. What am I supposed to tell my manager? He’s not seeing any progress made and he’s bankrolling my big bet on Coda. We’ve heard “This is definitely on our radar. Stay tuned” far too many times already. Communication, communication, communication…
Yep - I have empathy for users (including myself) who have clearly signaled the need for added sharing agility. I recall at least two telephone calls with in-depth discussions of scenarios, etc. This single capability is a barrier to significant expansion of Coda in enterprises. Indeed, we desperately need the ability to purpose slices of documents to facilitate awareness without making sub-copies and throwing more human effort at an unsustainable process. In that sense, the lack of partial sharing runs contrary to a fundamental ethos of Coda - hyper-productive success patterns.
I can appreciate the likelihood that the timing of AGI put a dent in the schedule. However, Coda was always AI-enabled through packs from 2021 and possibly earlier. If resources were diverted from this core functionality, it probably wasn’t necessary.
In any case, a roadmap status on this feature, which seemed imminent at one time, would be helpful.
Hey Folks, I am curious…the reference to ‘partial doc sharing’, is it primarily referencing:
I think I am asking because #2 is a big pain point for us…and I keep worrying that just addressing #1 won’t solve for it. So trying to understand the direction in which coda is looking to solve for this,
-A
@Bill_French, @Bas_de_Bruijn, @Astha_Parmar and our maker community,
I’m the product manager working on various projects in the content sharing space, including page/sub-doc sharing and full-page embeds. We know how crucial this topic is to many of you, so I wanted to share some of our thoughts and plans.
I want to acknowledge that we clearly hear your frustrations. It’s not lost on us that this is one of our top requests. We’ve discussed this topic deeply, conducted extensive research where many of you have shared feedback, explored, and even prototyped various solutions. Through this we have learned that this is equally challenging, as it is important to solve.
What makes Coda docs so powerful is their interactivity and the interconnectedness of data. This becomes quite challenging when you want to share part of a doc, and have it operate well in isolation. This means ensuring we meet our maker’s expectations on the data boundaries of what people can or can’t access, and building features that have enterprise grade security — it can’t just look secure. While we’re up to the challenge, transparently, it is a large undertaking to meet these expectations without the shortcuts we see in other tools.
While I can’t share specific timelines on feature launches due to the challenges, I thought we’d share a bit more with you about how this latest launch fits into the overall picture, and the progress we’ve been making. We spent the last year conducting extensive research and exploring various solutions. One of our largest learnings is that we have many makers with diverse needs when it comes to better organizing and sharing your content from Coda docs. Sub-doc sharing is just one piece of the puzzle.
Full-page embeds are the first major building block on our path towards sub-doc sharing. On their own, they also enable a variety of use cases we learned about through our research and from customers using it.
Taking all this together, we see each step as building upon the last. Full-page embeds were a crucial step along the path and it’s certainly not the final stop.
Additionally, I wanted to share some related and exciting news. As we continue to review feedback from the various channels, we also learned that sharing a page isn’t always the end. Sometimes the true destination is about enabling people to see only a certain part of a project tracker or OKRs on that page. While Cross-doc enables this today, we plan to make this much richer, so people can work from any doc they please and all Cross-doc changes are always in sync. In the coming months, we will be working on Two-way Cross-doc to enable a variety of scenarios where you want to share parts of your data with other people, while allowing them to edit what they have access to.
Please know that the feedback you have all shared in the community, surveys, directly with Codans, and more has been incredibly important and one of the many bright spots of the community for me personally. We continue to reference your feedback and ideas as we explore and make decisions in the content sharing space.
We’ll continue to make progress and share updates as we have them. Many thanks again for your thoughtful questions, push, and patience while we lay the foundational building blocks to address feature requests like these.
Thanks indeed for the feedback @Tamas_Mahner!
Curious how often you run into this and the scenario? For example is it more about when you’re setting up your doc with page embeds or you find yourself needing to do this for every doc.
this communication is exemplary.
a clear statement of the range of use-cases being targeted.
explanation of the issues preventing a simple quick deploy.
reasoned direction and probable sequence of feature releases.
sets great expectations, and reassures us all of the strategy… so we keep the faith and have patience.
but also makes it clear that predicting timelines is not possible.
THIS is the kind of update we need more of!
well done @Ayuba_Audu and team. take a bow. accept our applause.
max
Thank you @Ayuba_Audu for your extensive feedback. My takeaway is you have a clear picture of the needs and the challenges. Your explanation of the steps needed to reach the goal makes sense. However;
This sounds like you’re still trying to come up with a solution and nothing is being build yet. “We plan to make…” “We eventually plan to allow…” “We will be working on…” AKA check back in a year or so.
On the upside, two-way Cross doc is apparently being worked on actively which would be a great help.
I’ll return to the sidelines and impatiently wait for updates 
thanks @Ayuba_Audu for the update.
It is the first time that I remember that we see ambitions in this realm clearly expressed in the community and I do appreciate this a lot. Two way sync is an often asked for request and touches many Coda fundamentals.
I hope and expect to read your regular updates in the community. I understand that this may not be easy for the Coda team, but a good challenge never is.
Cheers, Christiaan
Thanks Ayuba and Coda for providing some transparency here, this can be a delicate dance. I for one appreciate even the attempt to do so, the clear messaging and expectations in this post is a cherry on top for me 
.
Thank you @Ayuba_Audu ,
This is precisely the kind of explicit, context rich, and community considered communication we have all been hoping for, much appreciated.
And most importantly it gives me the confidence to further deploy Coda into my org and to spread the word more confidently.
My only comment being that it is so fundamentally important to Coda’s development that I feel it should have (or should still be given) a lot more exposure (I’m well invested in Coda and the community but would’ve missed this if @Christiaan_Huizer had not emailed me to let me know about it). So I’d strongly suggest including a summary of this in the monthly emails, or a Coda blog post or at the least a seperate ‘news from Coda’ post.
@Ayuba_Audu – echoing what other said here. Thank you so much for the update, the clarity, and laying out the direction.
I am glad and excited to hear about the two-way sync. I hope it comes with column lock so that folks can have best-practices around where source data is being generated for specific columns and where it is being consumed as context.
Thank you!!
-A
Thanks! I really enjoyed reading about the process and goals.
While these are desperately needed functionalities, I have begun to recognize the sharing horizon is wafting up mirage-like ripples affecting my vision of what it means to “share” parts of documents and data. I fear that by the time you sort out the deeply complex machinery necessary to ostensibly make copies of shared resources, a different approach will become obvious because competitors will already be doing it.
I have seen glimpses representing the future of sharing in various communities and it has changed my perspective concerning logical reflections of information. A good way to think about this challenge is to embrace the nature of data science. We use aggregations to distill and reflect upon information sets that are often so large there is no alternative approach. Data science has helped us master the art of aggregation to tell stories.
I think the short answer is the architectural limitations. As brilliant as Coda must be under the covers, it is [apparently] not prepared for a future where data-sciency-like aggregations could occur. This may explain why we have no API access to document texts. It also [perhaps] explains why we have no formulaic access to texts or the DOM. Feel free to enlighten me if I’m misstating this intimation.
Sharing document slices or data filtered by human-crafted queries through discrete UI settings, configurations and other guided programmatic nudging, may be completely unnecessary. AI is most certainly how this will be achieved in the very near future, possibly next week.
Imagine creating a briefing summation that rolls up three Coda documents and presents the state of the information in a shared report with executives. The report includes high-level charts based on data tables in the documents and may even include a chat feature that allows users to ask questions not specifically expressed in the report aggregation.
This is how AI will revolutionize work. Carving off slices of information for specific personas and use cases will require an abstraction that can only be achieved [practically] through AGI. This vision is not a wild idea; it is already being demonstrated at Microsoft using OpenAI.
It will require an underlying information architecture that is sensitive to such “aggregations”. Pandas, for example, is the architecture data scientists use to magically distill and separate signal from noise. There is no equivalent of Pandas in Coda, or in any document system and this forces us to cache-forward our document content into a Pandas-like design pattern to make this possible.
As Microsoft has done so well, I can also demonstrate what I presented in the briefing summation vision using PaLM 2 and a collection of Google Docs. Sadly, I cannot do so in Coda.
Sorry for the late reply
What I find extremely useful is to pull into 1 view multiple Google Sheets, which is then shared with the specific people with specific permissions. In this way I do not have to click around to find 30 people’s travel reimbursement sheets, but I have one view to work with it. Huge step towards page-level permissions in a way that I keep using what is built in Google Sheet but already within Coda.
The specific use case of mine is to bring travel reimbursment sheets of participants into 1 view (Doc) and this I need for each project and I have 15 projects at least annually (or more).
So now what I do is doing the same sequence of clicking for the 30 participants in each project. It would be awesome if I could pull from a table or a Google Sheet the links I collect for each travel reimbursement sheets and then it creates automatically pages with full-embed with the Gsheet links. taddammm!
Thanks a lot for all you efforts Coda is amazing!
Many thanks for sharing the details and examples @Tamas_Mahner! No apologies needed as feedback like this will help us as we prioritize future updates.
We have another exciting update to full-page embeds — embeds of Coda pages are now editable! Coda page embeds will now be presented with your same level of access as the doc you’re embedding from, so in addition to having all your information together, you’ll also be able to make changes without having to open another doc. Your existing Coda page embeds should update with no changes required and new ones will automatically inherit your access level. Note that some edit actions are limited on embeds. Editors can:
Additionally, this update introduces compatibility mode, an update to the “force” parameter which is now supported for both canvas and page embeds. You may need to toggle compatibility mode on from the embed options menu to successfully embed certain links.
Thanks for your continued feedback as we improve and expand Coda’s content sharing capabilities!
everyone,
As Gleb shared above, we’ve now made Coda page embeds editable! This is the first step in the path toward granular content sharing that I outlined in my previous response. We hope this will provide a more seamless experience for you all and broaden the range of use cases you can leverage full-page embeds for.
As mentioned, the next step in Coda’s content sharing evolution will be to allow secure embedding of a single page in such a way that no other parts of the embedded doc are accessible. We’ll continue to reference your feedback and keep you in the loop as this takes shape — many thanks as always for your insights!
Hi @Ayuba_Audu ,
First of all, thank you for the clear communication about this topic here and elsewhere. Your efforts have not gone unnoticed 
.
I think the following step will be the crux of the problem - probably quite a technical feat to pull off:
allow secure embedding of a single page in such a way that no other parts of the embedded doc are accessible
What I hope this means:
Formulas created in SourceDoc/SharedPage continue to be executed in the ‘namespace’ of SourceDoc even when run from TargetDoc/SharedPaged, but with the User() formula returning the TargetDoc user.
The above extends to filtering formulas, so that I can prepare a filtered view in SourceDoc/SharedPage that returns different rows for different users, and have peace of mind that only the resulting rows will be accessible in TargetDoc, even to the clever users who know how to dig into Chrome’s developer tools and browse the page’s source.
Formulas in TargetDoc/SomeOtherPage can still reference objects in TargetDoc/SharedPage, but only its loaded content.
Can you tell us, without making promises, whether this is your general direction of travel?
Honestly, if you guys can pull this off then I will be one overjoyed customer. I’m no engineer, but I guess that getting it done would almost certainly involve switching to a model where calculations of the shared page are run on your servers instead of the browser…
To help get this over the line, here are some compromises I would be happy to make in TargetDoc/SharedPage:
Happy to discuss this separately if this is not the right venue for this level of detail.
