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 different ways to differentiate user classes. For example:
- Control what fields a user can view or update in a table or a slice. Instead of statically defining whether someone can view or update (Add/Edit/Delete/ReadOnly) a column in the table definition, use the
Show_IfandEditable_Ifexpressions as part of the column definition. - Control which views are shown to the user. Use the
Show_Ifconstraint expression as part of the view definition. - Control which actions a user can invoke. Use the Action condition as part of the action 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:
SWITCH(USEREMAIL(),
"admin@mycompany.com", "ALL_CHANGES",
"manager@mycompany.com", "UPDATES_ONLY",
"READ_ONLY")