Limiting users to particular tables, views, and actions


We have already seen that an app can show different data to different users. In some situations, you may want the app to provide different functionality to different users. There are three distinct cases to consider:

  1. There are a small number of user classes (typically just two, for example, such as regular users and admins) and one user class has a few extra features exposed. 
  2. There are a small number of user classes and they need very different capabilities.
  3. There are a large number of user classes, each requiring very different capabilities.

For cases 2 and 3, the answer in AppSheet is to build a different apps for each class of users. It is easy to build multiple apps which use the same underlying data. You can control data change permissions via the update permissions instructions found in this article. However, you will need to manage these different apps.

Case 1 is pretty common and in this case, you may wish to have different types of control per user class. This includes:

  1. Controlling which views are shown to the user. Use the Show_If constraint as part of the view definition.
  2. Controlling what fields a user can see or update. Use the Show_If and Editable_If constraint as part of the column definition.
  3. Controlling which actions a user can invoke. Use the Action condition as part of the action definition.

In all of these conditions, the email of the current user (USEREMAIL()) or options defined in the user settings (USERSETTINGS(<option>)) can be used to differentiate users.


Have more questions? Submit a request


Article is closed for comments.