I’ll have at least 4 different categories of users. I may end up with 10 pieces of data I need to collect from all of them regardless of which category they’re in, and then an additional 10 pieces of data that will be different for each user category.
My question: Should I just stick with the ‘User’ data type or make 4 custom data types?
Thanks!
Phil
This is always a great question that I think is very dependent on app goals. Sometimes the separation is a better idea if managing the data that way makes it easier to build the app. However, keep in mind that if all users need to log in, they’ll all need to be a User no matter what as that’s the built-in data type that creates unique user entries (saves the password, email address identifies them).
One way to keep it all under User and distinguish is with fields. Either a yes/no field for each category (e.g. admin = yes, manager = no, member = no, etc. ) or a single text field where the categories are just text values (e.g. category = Admin or category = Manager, etc.). Fields that aren’t used for a category that doesn’t apply would just be blank.
Gaby | Coaching Bubble
I would keep the core functionality relating to all users under the main User type. If you have extended data that only applies to some users, then move this data only into a separate type and link this data back to the primary User type.
It clearly depends on the circumstances however a couple of things to ponder.
What are you going to call this new “custom data type” ? If it is something nice and concrete like “Seller Application Details” then it seems sensible as the fields are related to the thing itself which is turn is related to the user. If it is a random splodge of unrelated user data that just needs a home and the fields are really related to the User then I would think if I really needed it.
Secondly, and related to the above, do I have a function in mind that will interact with this thing. So we could well imagine a “Update Seller Application Details” screen that doesn’t need to worry about other user types. It knows that this user is a seller, so can simply show the data without having to do an extra condition all the time.
However, if the data is unrelated to a some concrete concept, and it is likely to be a generic function if a load of “if this is a seller then show this otherwise show this or maybe this” I think it will quickly become annoying and I would stick it on the User.
tl;dr
Keep it on the User if it is a “is a type of” style relationship. Have a new data type if it is a “has a” or “is made up of” relationship.
Thanks to everyone for chiming in - all very helpful answers. I’ll stick with just the user type as much as possible and then go custom when it really makes sense.
Thanks Gaby, do you know of any advantage using a yes/no field vs. a text field for categorizing users?
Edit: I went with multiple yes/no’s in the off chance that some day a user could be in multiple categories - seems that’s the more flexible way to go.
Here’s a twist on this topic. What if I have a list of prospects. I have their names and email addresses and I’m trying to get them to sign up. When they do, they’ll be users. Until then, they’re just prospects.
Is it sensible to stuff them into the user data type already? (Using some field to indicate that they are members or not.) If I keep them in a separate “prospects” type, I guess I could build a workflow to 1) create a new “user” record, 2) transfer their data over, field by field, 3) fill in any new fields necessary for members, like a member number and the join date, and 4) delete the original prospect record.
Maybe my confusion here is with the word “user”, which implies it’s people who have logged on to my system. It should really be “people”.
Anyway, what’s best practice here?
Maybe not “people” but “person”.
It doesn’t really matter, User, People, Person they are all just entities, you can do with them what you choose, you build it!
If they are registered on your system, then I would have them under User, and you can have a field that holds their status. Depending on what service levels you might offer, you ‘might’ have Prospect, Free, Basic, Bronze, Silver, Gold, Platinum, Rhodium, or whatever!
Why go to the hassle of transferring one user from one type to another, when you can have them all in one place and manage them through a feature set dependant on level.
If your prospect doesn’t come to much, and you want to automatically purge them after a while e.g. stale accounts, you can simply run a periodic scheduled API to wipe them out to keep the db clean.
The only way you can create a User (other than by the user themselves signing up) is by Signing them up as a workflow action and all that entails (such as setting a password but not emailing them). Or using the “Create an Account for Someone Else” action.
You then need to think about what the User Journey looks like when they do finally want to sign up. Because they can’t just “sign up” anymore … as their email already exists. So you probably have to mess around with password reset emails.
We used the “Prospect” data type method as we want to restrict signups to known email addresses, we then do exactly as you described and copy over the data when they sign up for real. And I remember struggling with the “Create an account for someone else” action in the past.
