I’m experiencing an issue with CSV exports that I believe was working correctly before.
The Problem: When I apply filters to a table view and then export to CSV, the export includes ALL records from the table instead of just the filtered records that are displayed in the view.
Expected Behavior: The CSV export should only include the records that match the current view filter - i.e., what I’m actually seeing on screen.
Current Behavior: Every record in the table is exported regardless of any filters applied to the view.
Even when using a Slice to view data filtered by specific rows and columns, it is still possible to download the entire underlying table’s data, completely bypassing the filtering conditions.
This critical flaw enables highly confidential data—even data that users are explicitly unauthorized to access—to be easily downloaded to their local devices.
On any standard business application platform, an issue of this magnitude would immediately raise a “red flag” and necessitate the formation of a special countermeasures or incident response team.
It appears that, once again, Google is underestimating the severity of this problem.
Yes, this is one of the tradeoffs with slices vs security filters - slices are evaluated locally and not intended for use as a security mechanism. In the docs we try to emphasize that security filters should be used to protect confidential data.
In the scenario that was reported here of filtering in the app UI not being respected by CSV export, I don’t think there is a security impact since the filters are applied by the user, so the unfiltered CSV would still only contain data that the user already had access to.
I agree that security filters is for protection of the data, however also agree that a CSV export should be able to retain its sliced data as a way of filtering out columns and rows for ease of use, exactly what it was intended for. Alot of small things are overlooked as I have heard many say here on forums before, I don’t beleive the developers are actually using Appsheet to its fullest extent to see where pain points are.
It cannot be that hard to have the team spend a few updates on tackling serious pain points for users/creators and also knocking off a list of small feature requests.
Agreed, we intended for CSV export to respect slice row and column filters as well as user-applied filters. The latter was affected by a recent regression, we did make it a priority to fix once it came to our attention.
I hear you, we do allocate time to this, but despite being part of Google we are still a small team, so it’s largely a matter of picking our battles. We do rely a lot on customer feedback to understand where the pain points are. Some things are easier or less risky to fix than others, and that does factor in along with other considerations. There is some inherent tension between trying to prioritize feature requests and bug fixes vs maintaining product stability, as every new feature or attempted bug fix carries some risk of introducing regressions like this one. New features also expand the surface area we need to support and introduce new combinatorial complexity. This probably just sounds like making excuses, but I wanted to acknowledge that we do see these requests and take them seriously.
@Adam-google Thank you for your response and tending to the CSV slice matter, I do hear your team’s point of view and partially understand, the fear of introducing new bugs is real but can also stunt the apps growth.
May i ask if the Appsheet team is perhaps looking at allowing embedding looker studio in iframes, finish off charts and perhaps using the existing Google calendar system to replace the current limited calendar views. These would greatly improve the users experience and falls within your own Google ecosystem.
I do beleive alot of users would rejoice in these improvements after so many years.
I myself do value the teams work however struggle to understand the quiet approach to things and/or limited view of the platforms roadmap for us end users.
I do ask that you hear and consider escalating some things internally, this is not a disgruntled message but more of a plea due to the love of this great platform..
Thank you and your team for all or your efforts within the red tape that may exist…
Yes, I understand that when using Slice, all the data already exists in the device’s memory. Therefore, from a fundamental security point of view, we should probably use a user security feature to prevent data from being downloaded to the device, even at the memory level.
However, this is something that a specialized developer can understand through their experience.
For the general citizen developer, there is a big difference between extracting data from memory and simply being able to download it with a CSV export action.
AppSheet is advertised as a platform for citizen developers, but I feel that Google’s developers are too smart and may not have the same understanding as the average citizen developer.
It’s a fair point. I did check whether exporting CSV from a view based on a slice is returning filtered data (respecting filtered rows and columns), and it seems to
be working at least in my own apps. I don’t think the recent regression with user-specified filters would have affected this aspect either. But if you are seeing cases where slice filters are not being reflected in the CSV export, please let me know and I can look into it.
The current data export is only filtered by the rows and columns of the Slice. Thanks!
But, I need the export to use only the columns shown in the View.
Current state is: App: export this dataset (table or slice) to a CSV file (not a row-level action)
Our request is: App: export this view to a CSV file (not a row-level action)
Why this is urgent: If a user tries to export a View that only displays names and emails, they might accidentally get the full salary data in the CSV! This is a big problem.
I know the full data might be saved on the user’s device memory already. We must try to avoid this specific export behavior.
However, Citizen developers expect the “export this view” action to truly export only what is in the view. Please fix this behavior.
