Here are some common and appropriate use cases for User Settings:

  • Your app has data analytics for ten different countries. Ask the user to select a country via the User Settings, and filter the data (via a Security Filter or Slice) to show just the appropriate information for that country.
  • Your app supports more than one language. Ask the user to choose a preferred language via the User Settings, then modify the user interface using DisplayName expressions based on the chosen language.
  • Your app is for members of a soccer league to see the upcoming matches for their team. Ask the user to choose their team via the User Settings, and filter the data appropriately.
  • Just as in the Display Jobs sample, your app is for members of a team to pick up tasks to work on. Each team member provides an identifier or name via the User Settings, and the app filters the data appropriately.

User Settings should not be used as a security mechanism. In particular, do not create a "homegrown" username/password mechanism via User Settings.

Any capture of a user password needs especially secure implementations for data capture, transport, and storage. Users tend to reuse passwords across systems, and their data is only as secure as the weakest link across all these systems. In other words, if a password is compromised in one system, it typically compromises many other systems used by the user. For this reason, any such use within AppSheet violates the terms of use of the platform.

Did this answer your question?