Building on recent updates to sync pages and the Cross-doc Pack, I’m excited to share a powerful update to Cross-doc tables. You can now create dynamic sync filters when setting up a Cross-doc table that pre-filter the rows and columns before they are synced into a doc.
What changes will you see?
When selecting a table to Cross-doc into a doc, you will now only see base tables, not views. You can then choose to sync all rows, apply sync filters, or use the advanced tab to choose an existing view from the source that has filters already configured.
These added capabilities make it even easier to adopt “hub and spoke” architectures for your team’s docs. Singular mega-docs can become sluggish or difficult to navigate, but by using a series of connected docs, everyone across the org can access and update the specific information that’s relevant to them while still having a space customized to their team.
By pre-selecting the data to sync, you can:
- Ensure syncs happen faster.
- Keep sensitive information secure.
- Prevent issues where users in the source doc can inadvertently modify views and unknowingly impact downstream sync tables.
What are some situations that benefit from filtered syncs?
When doc performance and data security are paramount, pre-filtering your Cross-doc data can be the perfect solution. For example:
- Need to share a subset of your team’s private work with the entire company? Securely do so using a filtered cross-doc sync or an access-controlled sync page.
- Instead of setting up OKRs in a single mega-doc and creating individual views for every team, each team can sync just the rows relevant to them into their team hubs.
- When working with multiple customers and needing to share data that is unique to each, you can now elect to just sync a set of relevant rows into a shared doc. Only those with access to edit the source doc can make changes, so you can be sure that other clients’ information isn’t being accidentally disclosed.
Try it out in your docs and let us know what you think!
40 Likes
Hi Shaonan,
Would love to understand more about the permissioning in the Cross-doc tables. Is it possible to protect information with a dynamically filtering table based on the .CurrentUser function? Would this create a filtered sync table that only includes the data that the current user is eligible to view?
Chris
4 Likes
I told my client this afternoon that she couldn’t securely filter out relevant data. It looks like she can potentially do that now.
Same question as Chris @Shaonan_Zhang. I tried filtering out by current user based on a ‘created by’ field. When the table synced, however, my row did not turn up. Is this supported? I would expect so and hope so.
3 Likes
Hi Chris,
Great question. Unfortunately it’s still a limitation to cross doc for dynamic formulas such as User.
Shaonan
3 Likes
Can you explain how this will affect cross syncing tables that include relation columns?
4 Likes
This is so great!
Question: we all have cross-docs done the previous way. What are the pros and cons of migrating them to the new approach?
A big pro is having less views since you don’t need cross-doc views.
But are there any cons that I can’t think of?
Thanks in advance.
5 Likes
What an unexpected and most welcome surprise to start off this day! Thanks for letting us know, @Shaonan_Zhang , and please give the team a huge “KUDOS!” from me! Such a great feature launch, and I’m convinced that tons of hard work went into making it happen!
The UI is impeccable - the ability to preview the entire table, and then to adjust filters to the rows, and select the columns do display is intuitive, clean and super-easy to understand! Wonderfully done!
I especially love the fact that you kept the original functionality - when opening up the advanced pane, one can still select a specific view (in case one does wish to create a view within the source table), which will then be kept in sync via Cross-Doc.
The messaging displayed in the side bar to clarify who can adjust these sync settings (ie which filters to apply and which columns to display), is concise and to the point.
All in all, a fantastic implementation!
5 Likes
This is EXACTLY what my biggest client has been asking for!
Well done to the team.
A major advance in sharing data across docs and teams.
Max
3 Likes
wonderful detailed explanation @Nina_Ledid, I was wondering about the columns and you showed it 
1 Like
I literally needed this today! Perfect!
1 Like
Ha, sounds like the end of Sync Tables Pro 
Need to look into it!
3 Likes
Thanks for sharing this update! The new dynamic sync filters for Cross-doc tables look like a great way to streamline workflows and improve efficiency across teams. By allowing pre-filtering of rows and columns before syncing, it simplifies the “hub and spoke” architecture and helps address key concerns like doc performance, data security, and customization for specific teams.
The ability to ensure faster syncs, protect sensitive information, and prevent unintended modifications is huge for teams managing complex data across multiple docs. I can see how this would be especially beneficial for organizations working with OKRs, customer-specific data, or any scenario where filtering and access control are critical.
Looking forward to trying it out and seeing the impact on our doc management process!
is there any plan for buttons to be included in cross-doc? or do we need to reconstruct them?
3 Likes
I Guess it might be tricky to sync button if you have data not available in one of the filtered view.
I don’t think they will do it.
Even buttons with simple actions like open row or copy link (with link synced too) don’t work.
Can you only sync one view per base?
Hi! Can users edit data in the filtered subset? I’m looking at a hub and spoke solution for asset registers.
Not until the following filter is supported:
email=user().email
When setting up a filter like that, it looks like that is going to work, but when you return to the sync table, the sync does not happen.
If I remember your pack correctly, you can build dynamic filters with Sync Tables Pro
Yes, you can turn 2-way edit on in the sync settings.
Great update - opens many possibilities.
What is particularly great is that the 10K sync limitation now applies to the synced table, not the source. That makes a huge difference. Thank you for that.
If you can somehow manage to make the filter dynamic (either something like user().email or using a Text- or Select-control (set as Personal) it would be the icing on the cake. I realize that would mean full syncing of the table on each new doc load, but that is a small price to pay for the added flexibility.
I am also really happy that relational fields still work. You can’t click on the items in the synced relational rows until you sync-in the related table, but I actually see that as an advantage for many use cases.
6 Likes
