Hi.
You don’t need to access the full table, just the presented data, which is what happens with Cross Doc.
1 Like
Thanks for the detailed response. I appreciate this is a complex upgrade with lots of details. Maybe a video would’ve covered more than just the post.
I might need to test it again but I think a user with access to the source doc can “downgrade” the access which also seems problematic. Only doc owner and maker should mess around with sync settings.
Maybe I am too impatient 
For years I’ve been eagerly expecting and it finally seems to get closer to the day when I would be able hide some data while still benefiting from all coda features.
1 Like
Such an valuable clarification, thanks Ayuba! Delighted to learn that the WYSIWYG approach remains intact, that is, one will not be able to untoggle any and all “hidden column” from within the detail layout, but solely and columns visible in the table view but hidden in the current layout!
4 Likes
Hello David, if you wish to interact with or reference the table data in any way, your only solution is Cross Doc. Sync pages will allow you to visually represent your data within the container doc, and (in case of access to the source doc) take some interactive action on it, but by design you are not able to reference sync page’s data from any other page (which is the realm of Cross Doc).
4 Likes
This is awesome! I was waiting for this feature to build my compagny’s wiki! Thank you @Ayuba_Audu. 
1 Like
First of all, thank you for the release!
I like the responsiveness much more than cross-doc indeed. But I guess the drawback is that with sync pages, the tables can never be referenced in the destination doc.
And yes, I also struggling to find use cases for this release, as there’s not much benefit to just viewing the pages. It only opens the possibility for dashboard-kind of use case, or one-way broadcasting purposes I suppose.
I really hope that the editability function will be completed and released soon, and not necessarily have to wait for the single page share feature in stage 4.
If it is possible now to at least isolate the editable shared pages by syncing them out to a new Doc and control the access of user to said Doc, I guess that will be really helpful.
1 Like
Many thanks for your feedback and regards, @Sathya_Thunger — we do appreciate it!
I’ll respond to a few of your comments below.
Can you say more about the use case you imagine you could do if you could reference tables from the source doc in the container (destination) doc?
That’s exactly our plan and you won’t have to wait for step 4, specifically:
- Work as quickly as we can to enable editing and live updates for sync pages with access control on i.e., “Everyone in this doc”. (step 3)
- After that, we’ll continue on to share a page (step 4).
As I shared above, instead of waiting until we support each and every scenario, we will continue to release major updates periodically that unblock a range of use cases.
We’ll continue working towards all the steps we’ve outlined and continue to come back to the community as soon as we have updates to share.
3 Likes
Can you say more about the use case you imagine you could do if you could reference tables from the source doc in the container (destination) doc?
So, the capability to reference tables from the pages synced from their source doc essentially opens the possibility of some kind of ‘integration’ between part of data between docs. And to some degree, replacing the cross-doc use cases, by actually enabling members of both source and container docs to access and edit (if unlocked and shared for sure) those certain synced pages from different docs), instead of having to rely on cross-doc automation or manual refresh of data.
For example, in my current use case of Coda is that I’m using it to manage more than one business units of mine. And there are several aspects/departments of the businesses (such as finance, HR, payroll, business dev, legal, company profiles, etc) that I want to manage centrally via a ‘Core’ doc that I created. The reason I do not separate these different departments into separate docs, is because there are elements that needed to be interlinked between them. And I don’t want to have multiple cross-docs as ‘endpoints’ within each of those docs just to be able ‘talk’ to each other.
And so, what I’m hoping to be able to do are:
- So I can sync some pages from this Core doc to each respective business’ doc for the team within each of those business docs to access, for their own operational purposes
- So I can sync pages related to each department into separate docs, which suppose to be accessed by different personnels assigned to each department, so they can manage their own portion and work within their own dept doc, using some pre-populated data from the Core doc which synced/referenced/linked to other department’s data, all without them being able to access those other dept’s data directly (For example we don’t want HR/payroll data to be accessed by anyone within the Core doc obviously, yet the data needs to be synced to accounting entries for example.).
In short, the way I see it, these sync pages supposed to be the ‘link’ or ‘wormhole’ or internal ‘API endpoints’ if you would, between docs, and it would be great if the ‘payload’ (data shared within the sync pages) can be referenced and ‘linked’ to the data in container doc just like cross-doc, instead of members of container doc can only see or edit separately from the same doc (might as well just open 2 docs in 2 tabs or windows and work directly in those 2 docs if the data can’t be referenced). After all, the main point of Coda is to work as ‘relational database’ to create robust and deeply integrated information system. Not just ‘combined viewports’ 
.
2 Likes
Yeah, we have a similar need.
Main Database with a listing of around 800 products. Some of that info its confidential, for example:
Clients: Can only see final prices
Internal Users: Can see Prices and internal notes
Admins: Can see Product cost, supplier, etc.
Right now we manage that with crossdoc, but it has several disadvantages:
- No real time!, sometimes there are errors because a certain department has old data (Might be even a few minutes old!!)
- Need to edit the “Visuals” after sharing, as all the formatting is lost (Bunch of time lost)
- Another Process / Procedure to do / control / learn, when all could be solved with regular “Sync”.
And this is just a single case, we have similar needs for a lot of documents in the business.
Ideally we could:
- Reference data in a synced table for other DB’s in the same document. Of course , only access the “Visible” data.
- Copy & Paste data from synced tables! (Right now we cannot use regular “Copy” in Linux, not sure if that’s by design
1 Like
Commenting on a shared read only page 
First of all congratulations and thanks @Ayuba_Audu !
It’s great to see you making such clear and consistent progress on the roadmap 
Unless I’ve missed something it appears one can’t comment on pages shared as read only…
Can you reply when are you sequencing / planning to make commenting possible for people viewing a shared read only page?
If this can be unlocked sooner than editing, it would be very much welcomed. Eg a couple of obvious uses cases:
- in a business setting the ability to get feedback on things like status updates shared as read only. This would be invaluable!
- In an wiki or academic setting it also would allow team members / students to comment and raise questions on materials shared to them.
Does this make sense or do you need more clarity and motivation for making it a point feature release on the way to full editing?
4 Likes
Yes, now that you mention it, we also happen to have similar use case where we setup:
- Main pricelist in main doc with calculation column and updated stock level.
- The pricelist at least needed to be referenced (although not editable, and some columns hidden) by another doc (container) we created for our dealers, for them to create their order list, and then send back the order info to subtract and update the stock level in the main doc.
So far using cross doc, but not real time synced, formatting also lost.
So in overall, I honestly view cross-doc as ‘half-baked’ service and really hope that it can be replaced by sync in most use cases, now that it available.
Sync pages also indeed eliminate all the hassle to reconfigure the tables and data visually. This become extremely tedious when the same table cross-doc’ed to multiple different docs.
2 Likes
Exactly my thinking.
I think with Sync a little more developed, the functionality of both will be too similar, they probably have their reasons… but i don’t see the point of having 2 competing tools in the future.
It was funny discovering that I lost all the formatting after setting up dozens of tables, probably spend a couple of hours reformatting again with CrossDoc 
1 Like
Many thanks indeed for the feedback and congrats, @Michael_Skok1!
Re: commenting on sync page with access control: You haven’t missed anything, the needs are clear and I appreciate the examples you’ve shared. While I don’t have timing to share, I can say it is one of the next big rocks for us to tackle — along with editing and live updates.
As I shared earlier, our general principle is that if there are creative ways to enable some use cases sooner, rather than later such as commenting — we’ll do that and are aligned with your thinking.
3 Likes
Ayuba,
Thank you for the thoughtful response acknowledging the use cases. It’s good to know that it’s on your radar as a potential next step.
Best,
Michael
2 Likes
Many thanks @David_Ibarra and @Sathya_Thunger for sharing your use cases — very much appreciated as it helps inform our future investments!
We continue to invest in improving Cross-doc with recent updates to simplify the authentication and improve referencing behaviours of cross-doc views. You can look forward to future updates to support syncing formatting across source and child tables, and much more.
In general, Cross-doc is useful for cases when the child table has columns unique to that doc that aren’t on the source, cases such as team docs where each team wants to track data specific to their team that is not on the source table.
- Copy & Paste data from synced tables! (Right now we cannot use regular “Copy” in Linux, not sure if that’s by design
@David_Ibarra — this sounds like it could be a bug. If you’re able to share more details on how to reproduce the issue, we’d love to dig in. Alternatively, you can reach out to support@coda.io with those details and we can take it from there.
2 Likes
Nice. Good to know there’s improvement coming for cross-doc.
Yes, you’re right about cross-doc allowing additional column and data to only resides in local (container) doc, as it essentially creates a new table, and link the values of all columns to another table in the source doc. And in that use case, it would never be replaced by Sync pages.
But in terms of ‘sync’ capability in its true sense, which ultimate goal is real-time changes in both sides, sync page still the way to go. Because when people change values in a synced page, they actually change values in the source doc directly, and just ‘viewed’ from another (container) doc (I guess that’s how it works?).
Anyway, if the data in sync page can be referenced in local container doc, that would be great. Because it will open possibilities for whoever assigned to the container doc, to link/reference their work to shared data in another doc, without using cross doc.
1 Like
As far as I see the custom domain is still not working on Docs which has sync page? Is there an ETA to fix this?
Example: https://campleaders.alliance-network.eu/
Did I interpret this update correctly that editability and live updates for access-controlled sync pages should come before step 4?
1 Like
Correct — the current plan will be to enable that before proceeding to step 4.
We’ll keep the community posted and share updates as we have them.
7 Likes
I was excited about this, but it seems like this doesn’t allow for two-way editing of synced docs without both editors having access to the source. Is that right? We want to be able to have a source page that’s only available to a doc maker, sync it to another doc, and let editors who do not have access to the source doc edit the page and have those edits sync back to the source.
Is this on the roadmap, and I’m just misunderstanding?
1 Like