Currently, the list of users defined under Editor > Security > Users (who is allowed to sign in to the app) cannot be read from any app formula (Valid_If, Security Filter, App formula, etc.). This creates an artificial separation between two pieces of information: (1) who can sign in at the platform level, and (2) the user/role table maintained inside the app’s own data. As a result, developers are forced to manually keep the same user list synchronized in two separate places. If one is forgotten (for example, a user added to the Editor allow list but never added to the data table), the inconsistency happens silently and is hard to detect.
Use case (from our project):
In a cooperative management app, when an admin invites a new employee or shareholder, they must add that person’s email both to the Editor allow list and to the app’s own UserAccount table. There is no way to validate one against the other. A user who is added only to the Editor allow list can open the app but never gets linked to a role or any data, and there is no mechanism to catch this.
Requested feature:
A USERSLIST() (or similarly named) expression function that returns the Editor’s allow list as a list of emails, usable inside app formulas. This would let developers write a Valid_If or Security Filter such as IN(USEREMAIL(), USERSLIST()), or conversely validate on row creation that a new user’s email actually exists in the Editor allow list.
If your app is designed properly, it should assume that any user of the app is implicitly allowed to use it. If that’s not the case, your editor-based allow list is misconfigured.
The app-side user-specific configuration is (a) app-specific, not something the editor should have awareness of; and (b) something your app admins would have to configure in the app even if something akin to USERLIST() existed.
When I considered the challenge you’ve proposed, my approach was like this:
Allow access from any email within the company’s domain.
By default, access by a company email gets only basic access, determined and enforced by the app, using security filters and other in-app configuration.
Anything greater than basic access requires the user to be configured in the app itself by an admin.
Admin access in the app itself requires the user be marked as an admin within the app, and have the Admin role assigned within the app editor. This prevents an app admin from giving the privilege to others unless they also have access to the app configuration.
To clarify what I’m actually asking: I’m not trying to build a dynamic permission system. Authorization can stay fully in-app via Security Filters, as you suggest.
What I need is simpler: when an admin adds an email to our own UserAccount table, there’s no way to check if that email actually exists in the Editor allow list. People sometimes give us an email they don’t use, or we mistype it, and no expression can catch that mismatch since the allow list isn’t readable from formulas.
A read-only USERSLIST() type function, just for validation (Valid_If or a warning column), would solve this without touching security design at all.
I suspect the white-listed set of users is unaccessible programmatically BY DESIGN to keep that list as secure as possible.
Users will let you know if they cannot access the app.
That white list should be considered the source of email addresses and any entry made into the UserAccount table validated against the white list - manually of course.
I have two suggestions:
Using your current implementation add a feature that when any new row is added to the UserAccount table, a notice is sent to the person(s) that can validate the email against the whitelist and APPROVE the entry.
Alternatively, if you can afford a slightly less secured app, you can build the app WITHOUT a whitelist of users. There is a configuration for allowing ANY user to access to the app. The app can then use permissioning from the UserAccount table to determine WHAT the user sees. No entry in the UserAccount with the email, the user see NO information and maybe just a default view that they need to sign up. If the entry matches in the UserAccount table, then the user can see whatever views their permissions allow.