I am new to Bubble coming from Claris FileMaker Pro. Trying to create a SAAS app for real estate brokerqges.
Here is my situation: I am a real estate brokerage that deals with many types of “PEOPLE” in unque ways such as:
Clients
Real Estate Agents
Title Company Employees
Loan Officers
Home Inspectors
Warranty Representatives
My company staff (which would also bring in related data from the “Real Estate Agents” above
My intuition is to set up one Data Type called “PEOPLE” that is the comprehensive list of all human beings. Within that table would be a field called “Person Role” that would be a list of one or more possible roles from the list above.
For best practice should I also have separate Data Types (tables) for each of the people subsets? The reason is that each person subset has unque field requrements that don’t belong to other subsets.
Example: a real estate agent has an MLS number - but that is unique to real estate agents.
I’m just beginning this app and want to have the best (lightest and fastest) structure to be able to scale.
Yep, You can have separate data types for all the user types and link the user the to that data type. Keep the common fields under user and the other fields to the respective role - data type.
and every time, a new person is added, they are assigned a new role accordingly
You can either add field Role of type option set “Roles” to the User database or create a separate database “PEOPLE” where you can add field Role of type option set “Roles”
If a person can be have more than one type of role like a person can be a loan officer as well as home inspector then check “This field is a list”
For all the people subsets, you could create a separate database with fields belonging to that person like a field “MLS number” of type number for data type “Real Estate Agent”
If you’re just getting started with your Bubble app and want to make sure your data structure is scalable and efficient, I’d be happy to collaborate and support you further as I am also a beginner in Bubble and looking to work on projects. Feel free to reach out to me.
That sounds good. I will go that way. The only thing is that all these PEOPLE entities will not be “users” of my app. They are simply entities that should be viewed within the app.
The way I see this… Basically everyone is a Contact of some type, whether an individual or company.
If you need to store vastly different types of information per Contact type (Inspector VS RE Agent), then you can create a Datatype per “Profile” which can be saved to the Contact
For example if I am a Client AND a Broker you may need 3 data types
Contact for storing info on a person or company (name, email, phone)
Broker_Profile (information specific to a Broker)
Client_Profile (information specific to a Client)
CONTACT
Contact_Type (option set) = set the value to “Client, Broker”
Entity_Type (option set) = like individual or business
Client_Profile = create a new client profile and save it here
Broker_Profile = create a new Broker profile and save it here
Name
Phone
Email etc
NOW, you don’t HAVE TO use all these DTs, you could just have one mega one if they are similar, but you’ll need to document what fields are relevant, required, not relevant etc per Type. This might be more troublesome.
One note on option sets… sometimes it’s actually harder to search for things using an option set, so using a set of boolean fields may be easier for searching, sorting, and filtering all your contacts.
Using this method you would need to set a YES/NO field for each possible Contact Type like “Is_Broker = yes/no”.
