Provide an APPSETTINGS[] list similar to USERSETTINGS[]

I would like to request to add a list of settings that are user updated but apply to the application across the board to all users. This would be similar to USERSETTINGS. In fact, I would recommend changing the “User Settings” tab in the editor to simply “Settings” and then have a “_PER USER SETTINGS” list of values and then a “_PER APP SETTINGS” list of values.

I do understand that the same thing can be achieved by adding a sheet with these values. But the difference is how we reference them. It would much easier and more efficient for the developers to access these application level settings like APPSETTINGS[“Name”] rather than using ANY(SELECT()) statements all over the app - even cutting and pasting becomes tedious.

Nice suggestion!

So these would really be some application-level “global” constants that could be readily used. Correct?

4 Likes

Actually this could be a good idea. I normally create apps with a variable table where I have all app settings and the Admins can change them as they wish… like texts in a Workflow rule, Enum options, language options etc. It would be easier for the user to type Appsettings(Option) than writing like LOOKUPs. And no extra table is needed for this purpose.

4 Likes

@praveen Yes, that would be correct. For example, in a scheduling app, you may want to set “travel time” and “minimum appointment” time values that are included in logic to establish appointments and other logic preventing appointment overlaps during assignment, etc. But these values may differ from client to client (i.e. app to app). If I am signing up 50 clients to the app (each with their own copy), it would be much more efficient and less risky to simply change these values if they were accessible at some “global” level.

@Aleksi LOOKUP() !!! I should have thought of that.

1 Like

@WillowMobileSystems I normally add all options (for Enum etc.) into this variable table. Then you can read values with SPLIT(LOOKUP(“VariableName”,Variables,Variable,Value)," , ") with your Valid If.

3 Likes

@Aleksi Yes, I can see the power of having such a table for the app to hold all such values and lists. Especially, when needing to provide copies of an app to multiple clients. It provides a way to easily customize certain aspects of the app for each client but more importantly keeps that customization within the client data itself and not in the app.

2 Likes

Yes, Yes, and Yes! Ive felt the need for an AppSettings for some time. Im using a regular table for this, but the settings are so different from one another that I find it a little unwieldy to use appsheet to manage these settings. Google Sheets have a preferences setting, Excel has a preferences/options setting, it only makes sense for an App created through AppSheet have a AppSettings

2 Likes

Just voted. Could be so extremely useful

1 Like

I spent the last hour seeking a such functionality in Appsheet, until I landed in this topic. I could not imagine it doesn’t exist in Appsheet. So I up-vote too. it would be extremely helpful

1 Like

I have no votes so I will bump this feature request the only way I can by replying and liking everyones post. Great idea would love this, I already do a similar thing with the usersetting table when users start the app to get around using multiple extreme expensive lookups.

Wait I already voted for this, I need to be able to vote for this twice

3 Likes

I’d also like to cast my vote on this! Caching regularly used values that are globally used (especially per user) could provide phenomenal time savings not only in development, but also in sync times. Currently, I’m having to perform a LOOKUP() to constantly associate a users email to a provided userID which is more more used across all datasets than the users email that could potentially be more volatile in the future. Being able to just perform that LOOKUP() once at “sync-time”, and then refer to a User-Scoped variable could greatly lighten the load.

4 Likes

@Marc_Dillon, thanks for the share! Seems like a really great workflow, however, I’m having a lot of issues with Slice Row Filtering right now. See the following thread; maybe you have some input: