That configuration option, Starting view, is intended to choose the view that the user sees the very first time the user ever uses the app on the device, not every time the user opens the app. There is no way to force the user to a specific view each time they open the app.
I had to use AI to clearly describe my intentions…
Access Control Strategy in AppSheet
The goal of my approach was to enforce the app to always open to a specific “Starting View” each time it launches. This ensures that if a user’s permission level changes, they do not retain access to views they previously could see. By redirecting them to a controlled starting view, the app checks their current permission level and only displays the appropriate views.
However, the current behaviour of the app restores the last view a user accessed. This creates a loophole: if a user’s permission level changes while they are on a specific view, they can still interact with it until they navigate away. This undermines the intention of dynamically restricting access based on permission changes.
Given this limitation, it seems necessary to properly configure table view permissions to prevent unauthorized access, regardless of the user’s last accessed view.
While it is not advisable to control access solely through app views, relying on table security alone does not always reflect the intended access configurations for all views. Therefore, I was hoping to control access through views. In normal circumstances, a person attempting to break into the app would definitely not be on the app, especially when only personnel assigned by the developer have access to the secured app. Thus, it is much easier to control app access through views rather than table security.
Additional Considerations
Also, it would be beneficial for app developers to enforce user settings if any of the required fields are empty. In my app, to streamline and speed things up, users need to provide their full name so that forms have fewer fields to fill in. This approach is neglected in my opinion, or perhaps I have missed something in the documentation.
With AppSheet, if the data reaches the device, you must assume the user can access it. Maybe not easily, but it will be accessible. AppSheet is not well designed to secure data loaded into the app. For this reason, security filters are essential. Data design is also crucial to keep from mixing sensitive and non-sensitive data.
But if you must load sensitive data and want it hidden, be aware that hiding views does not prevent the user from accessing them. Hiding a view merely removes it from the primary display positions, the main menu, and in dashboard views. It does not hide inline views, nor does it prevent the user from navigating to the view by other means.
The best way to hide sensitive information that must be present in the app is to hide the column values directly using the Show? option of each column. This isn’t close to perfect, but is the single biggest step.