The community frequently receives questions about how to provide different data, functionality, or design to different users within a single app. There's lots of great guidance already available, including an in-depth tutorial from @QREW_Apps. Since it's documented in different places, uses varying terminology, and ranges from simpler to more complex implementations, I'm summarizing here in an effort to provide app creators--especially new ones--with an annotated jumping-off point to various aspects of this broad topic.
Contents
- Data access permission
- Data editing permission
- App feature permission
- App personalization
- Default user metadata
- Custom user metadata
- Custom role permissions management
- Multi-tenancy
To be clear: This is all the (great!) work of others--I'm just indexing it into a centralized reference.
Data access permission
To Limit users to their own data, configure a table's Security filter property. (It's also possible to literally segregate each user's data into Private tables, but this technique is not applicable to most scenarios.)
Importantly, also be aware that slices control only what data subsets are referenced within an app's various contexts (e.g., what data is displayed in a specific view)--slices do not control what data is downloaded to (and, therefore, is accessible within) the device where the app is being used.
Data editing permission
To Control add, update, and delete operations configure a table's Are updates allowed? property. In specific contexts within an app, it's also possible to define data editing permissions that are stricter (although not more lenient) than what is configured for the table overall--see the next section.
App feature permission
To Limit users to particular tables, views, and actions there is lots of relevant app editing functionality, including:
- Slice properties--e.g., Slice Actions and Update mode
- Column properties--e.g., Show? and Editable?
- View properties--e.g., Show if
- Action properties--e.g., Prominence and Only if this condition is true
App personalization
The techniques referenced throughout this tip can be used not just to govern a user's permissions, but also to personalize the app for each user. In this case, a particularly relevant technique is to utilize AppSheet's User Settings functionality, which allows the app creator to define custom settings for which users can set (device-specific) values that are then available for reference within an app. The most notable example of app personalization is localization, which allows the app creator to tailor an app's terminology to each user's preferred language. See a Multilingual Starter App w/ support for 106 Languages.
Default user metadata
Various informational and other functions provide access to generic categories of information about an app user, their device (including location, locale, and timezone), and even the user's current context within the app (e.g., current view). For apps that require sign-in, these categories include the user's email and app role. These functions frequently play a role in defining user permissions within an app. That's especially the case for USEREMAIL, which is often a link to custom user metadata--see the next section.
Custom user metadata
In expressions that govern user permissions, it's common to need to reference user metadata beyond what's generically available. Examples include a user's department, custom role, or currently selected preferences (e.g., values selected to filter a dashboard or other view). To accomplish this, implement a Users table (with columns for the necessary metadata) along with the rest of the techniques detailed in @MultiTech's extremely popular tip about Current User (Slice) | How to conform your app around WHO is using the app. Consider also @SkrOYC's innovative modification, Handy tip for pulling data from UsersTable/CurrentUsersSlice.
Custom role permissions management
AppSheet's rudimentary hierarchy of system-defined roles comprising just Admin and User is often insufficient. If your app needs custom roles, there is a spectrum of approaches:
- Hard-code (hard-no-code?) logic throughout an app by referencing explicit user metadata values. For example:
IFS(
[User_Custom_Role] = "Role 1", "ALL_CHANGES",
[User_Custom_Role] = "Role 2", "ADDS_AND_UPDATES",
[User_Custom_Role] = "Role 3", "READ_ONLY"
)
- Create a custom Roles table with a column for each permission you need to reference in expressions throughout an app. For example:
| Role |
Products_Table_Permission |
Show_Admin_View |
| Role 1 |
ALL_CHANGES |
true |
| Role 2 |
ADDS_AND_UPDATES |
false |
| Role 3 |
READ_ONLY |
false |
[User_Custom_Role].[Products_Table_Permission]
- It may be sufficient to manage the values in a custom Roles table directly in the data source. It's also possible to use @graham_howe's elegant tip for implementing a Flexible user role management system directly within an app.
Multi-tenancy
If an app is used by multiple organizations (aka, tenants) each with its own user base, a user's organization is essentially one more piece of metadata about the user. Beyond governing user permissions as described in the previous section, this type of information can be used to partition data into literally separate files.
If each organization needs to manage its own users' access to your app or if a single user can have access to your app via multiple organizations, app design gets pretty complex pretty quickly. For instance, imagine a user assigned Role 2 via Organization A and Role 3 via Organization B. To get started with designing a multi-tenant app, see @Jonathon's description of a robust approach, as well as his other succinct explanation accompanied by a diagram (which is nicely compatible with useful techniques for the often related need to control app access using mechanisms more robust than what AppSheet provides natively). There's also a slightly more detailed description of a clunkier approach that I implemented.
LinkedIn
Twitter
