We have already seen that an app can show different data or presentation to users based on their identity or settings. In some situations, you may also want the app to provide different or restricted functionality to certain classes of users. There are three distinct cases to consider:
- There are a small number of user classes (typically just two, for example, such as regular users and admins). One user class needs a few extra features exposed.
- There are a small number of user classes but they need very different capabilities.
- 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, as described in Control add, update, and delete operations. 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 functionality per user class. At the app level, there are at least two ways to differentiate user classes
- Controlling the update mode of a table or a slice. Instead of statically defining the update mode (Add/Edit/Delete/ReadOnly) in the Table definition, use an expression to compute the update mode dynamically.
- Controlling which views are shown to the user. Use the
Show_Ifconstraint expression as part of the view definition.
In these expressions, the email of the current user (
USEREMAIL()) or options defined in the user settings (
USERSETTINGS()) should be used to differentiate users into appropriate user classes. For example, to dynamically control the update mode of the table, here is a sample expression:
At the app level, there are at least two ways to differentiate user classes
- Controlling what fields a user can see or update. Use the
Editable_Ifconstraint as part of the column definition.
- Controlling which actions a user can invoke. Use the Action condition as part of the action definition.