I’m in a similar situation right now, and would like to post how I’m structuring my data to A) get feedback and B) potentially help others.
I am creating an app that will have a back end “Salesperson” user type, and a front end “Client” type. There are fields specific to Salesperson and specific to Client, and except for a few generic fields like Name they don’t overlap. Lastly, within the Salesperson type there are admins and standard users.
I’m structuring the data this way:
Salesperson will be a Thing with fields for all data specific to Salesperson, and a User field
Client with be Thing with fields for all data specific to Client, and a User field
User will have a field for Salesperson, and a field for Client. The relevant one will be set to and instance of the Thing, with its fields filled out. e.g. A client registering will trigger creation of a Client with fields filled, User set to current user, and the User Client field set to the Client that just got created.
Seems like there should be a better way of explaining that, but I think you get the picture.
I considered the idea of just having one Roles Thing and an Attribute Thing for easy extension of roles and fields, but decided against it for my application.
@austinhughes703 I’m curious what you ended up going with and how it worked out for you.