What this is:
Many apps serve more than one type of user - for example, an education-centered app might accommodate Teachers, Students, Parents, and even Administrators. This concept is important for two reasons:
A Teacher will probably need to see different stuff in your app than a Student, and might be allowed to do different things or go into different areas of your app (a Student shouldn’t be allowed to see EVERYONE’s grades, right?). You probably want to know different information about these different types of users. For example, for a Student, you’ll probably want to know what grade level they’re in. A Teacher may have a grade level (the one he teaches), but a Parent won’t have a grade level at all, and neither will an Administrator. The wrong way:
Putting all potential fields for all user types on the user record.
Why this doesn’t work:
Having fields on a data type that are unnecessary for most of your app’s users can lead to confusion when developing, and potentially duplicate fields because the user record becomes overwhelming. More on overloading the user data type here: How I do it:
Create a separate “Profile [User Type]” data type - one for each user type. So in our Education app, we’ll have four:
(I put the word “Profile” first in the naming (rather than “Teacher Profile” “Student Profile”) so that in your data types, all of the Profile data types sit together (because data types are alphabetized).
Each of those data types will have one field for the User, and then fields for anything specific to that User Type. As an example, the Profile Student data type might have these fields:
What you put on the actual User data type:
Very little! The user record should only have the most essential information on it - info that’s shared across ALL user types. Often my User data type has only 4-5 fields on it.
Absolutely essential is to have a “User Type” field, which will allow you to...
apply conditionals throughout the app (example: Show this table only to users where “User Type” is “Teacher”) block access to things they shouldn’t see (example: a page load workflow that redirects anyone who doesn’t have the “Teacher” option in their “User Type” to some other page) If your users might have multiple user types:
Let’s say, for example a user is both a Teacher on the platform is also a Parent, you’ll need two fields
User Types - this holds all user types that user falls into Current User Type - this holds the one user type that user is acting as at the current moment, and dictates what that user sees in the UI and what they’re allowed to do while acting in that role. You’ll need some UI built for them to be able to switch between their different user types.