Hi @joost_mineur and @Christiaan_Huizer
Joost, thanks for the question and apologies for a late response. I was clearly a little vague in my original verbiage so wanted to take the time to be more precise in my clarification.
To be clear, the pack pre-filtering table rows before they hit Coda is definitely not a universally applicable solution for securely restricting content.
Lets address both of your questions first Joost:
QUESTION 1
Say, you want to retrieve (like for a dashboard) the sales data (from a Xano table) for the last 100 days. I understand how you would setup the filter. Next week, the filter would skip the first 7 days from the previous batch and add the last 7 days. So far, so good. But the first 7 days ars still in the Coda synced table. Obviously you can set a filter on the synced table in Coda, but the data is still there. Eventually, you are going to have data from many years in your Coda table, getting to a point where your doc slows down to a halt.
Sync tables, aka packs, aka the integration we have built for Xano always follows the same dynamic filtering principles. So if you say to Xano: āHey, can you give me just the most recent records from the last 7 daysā, Those records will continue to change as each day progresses.
You will always get the most recent 7 days based on the current days date. So thereās no fear of, as you put it, āYou are going to have data from many years in your Coda tableā
The brilliance of the Coda<>Xano pairing is that you can always maintain data from many many years, growing into the millions of records. But In Coda, via your sync tableās filters, you can choose which relevant rows you want to see/interact with at any given point
QUESTION 2
Say you filter the sync data based on the logged in userās name. When another user logs in, the sync data is filtered based on the other userās name. At that point, even if you filter your Coda table based on the same criteria, both userās will have access to the data of the other person (with search or by any of the other means discussed previously in this community).
First off, let me state clearly that we did not create this pack to deal with or address issues of security, access, and permissions. To deal faithfully with large datasets around security, permissions, etc its honestly best not to use Coda at all. Coda wasnāt developed to be a true webApp development platform where the data is filtered at the API level.
We built this pack to enable users to continue using Coda as the collaborative platform of choice even when datasizes grow well beyond Codas limits.
Sync tables can never sync in different data based on the logged in user. Personal controls donāt work as valid inputs to a sync table filter.
Therefore, the same data that is loaded from Xano for JOHN DOE will always be the same data available for JANE DOE.
So then what did we build this pack for? Whatās its ideal use?
Example 1: Social Media Company
Say a larger influencer marketing company has 50 clients. And for each client, they are keeping track of high level metrics on the success of a social media campaign they are running for that client.
Lets say for each client, there are 30,000 relevant records in relation to their campaign metrics. Thatās a total of 1.5 million records. These sizes are too larger for Coda.
What this enables for the client is that they are able to have one unified source of truth database for all their campaigns in Xano, and then they can use our Xano pack to create unique portals (separate Coda docs) for their clients where they sync in only the clients related records / views.
Example 2: Hereās another cool, and slightly different example
Letās say my global e-commerce business stores all its data in Xano, and I need to provide a subset of this data to a subcontractor who manages distribution and support for a specific region without sharing sensitive info about global operations. Here we can do that safely. Rows for orders or customers from other regions just never make their way into the doc.
Whatās also cool is that you can setup Xano API tokens with fine-grained permissions for who can do what. Combine this with private accounts for pack writes, and we have a doc that only syncs in rows we predetermine (and never anything else) and also constrain individual users of the doc to only perform specific write operations within their job function. Distribution can only modify the orders table, customer support can only reset passwords on the users table, and the accounts team can only modify payment information. And each user class can perform these intuitively directly on the sync table, without us having to build fragile workflows to try control their behavior. Iām sure weāve all launched docs with a āusersā table that maps users to specific roles, then implement those role permissions with a mess of Switch() statements, complex layouts, āread-onlyā formula columns. Those docs are a nightmare to inherit, and i think our pack solves this difficult problem really easily.
Example 3: Customer Research / Reports
Lets say there is a large organization that operates / sells 20 different products (We actually have a client just like this!) - and for each product they do extensive customer research, cataloging things such as:
- Customer reviews
- Bug reports
- Feature requests
- Customer interviews, etc
For each product i there are 50,000 records over a couple years, thats around 2 million records. Once again, too large for Coda.
But maybe the teams workflow requires that during a certain day, they are only looking at bug reports for product x. Or during another day they are only looking at open features requests in the last year for product y.
They can declare those filters and sync the relevant data in from Xano and then utilize all the wonderful building blocks of Coda that we know all too well!
I hope that answers the questions raised, and better clarifies our goals for this pack build. Please let me know if anythingās still unclear and if you give the pack a test, let me know how you get along! 
A Xano Pack for Coda: Store Millions of rows 
Some sweet photos 
