Provide an APPSETTINGS[] list similar to USERSETTINGS[]

[WillowMobileSys]

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.

[pravse]

Nice suggestion!

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

[Aleksi]

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.

[WillowMobileSys]

@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.

[Aleksi]

@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.

[WillowMobileSys]

@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.

[David_Joyce]

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

[Jonathan_S]

Just voted. Could be so extremely useful

[ANJ_dev]

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

[Austin]

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

[_redline]

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.

[Marc_Dillon]

_redline:

Being able to just perform that LOOKUP() once at “sync-time”, and then refer to a User-Scoped variable could greatly lighten the load.

Current_User (Slice) - How to conform your app around WHO is using the app Tips & Tricks 💡

One of the core basic functions, included in just about EVERY app I make, is the ability for the app to know WHO is using the app. If the app knows who’s using it, then I can easily control many different aspects of the app: Add/edit/delete permissions How data should be filtered What views are shown What buttons, or Actions, are visible Which workflows should fire off Which columns should be shown or editable etc. Requirements To accomplish this functionality in your app, you need the follo…

[_redline]

@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:

Creating List of Numbers from delimited values Questions

@Steve, sorry to bump this thread again, but along the same vein of our conversation above, I keep coming across a problem using these EnumLists (and potentially other datatypes) in “Row filter conditions” for table slices. For some reason or another, using certain expressions seems to not visibly show the same result as it does in the “test” view of the expression. See this comment I added the other day on a similar thread here: "Row filter condition" displaying incorrectly After further inve…

[stuggijo]

Hey everyone,
as this request is colored grey now, does it mean, the feature has been released? If yes, does anybody know the feature announcement herefor?
Thank you much!

[Jamie_Laing]

Yes, pretty please, this is very much needed.