Should i split my data into multiple data types?


so i am building a CRM to manage our clients who have been involve in an accident. We have a data type called “Client Record” and within this we have “hire vehicle booking info” “general client info” “info on Vehicle repair claim” and some other elements of the claim process.

I currently have all of this lumped under 1 data type so lots of fields within the “client record” data type.

My question is do you think i should split each of the main elements into its own data type, so a new data type for “vehicle booking” new data type for “repair claim info”.

My thought process is it may be simpler to manage when building the workflow if i split the data up but then could it be more difficult to bring all of the data back together again on the front end. So when i click into a client file it should display info for each of the above sections. if i split these sections up then i will need to search for each section to display, eg. do a search for - Vehicle booking that “client Name” = current page client name. so i would have to do a search for each of the separate data types to bring it all together.

Whereas i could just have 1 data type but with all of the potential fields i would not need to do the search as all of the data will be present on the page. however could i then have issues if i want to use the information in a certain way.

Shall i split this data up or not.

any help appreciated

If “hire vehicle booking info”, “client info”, and “info on Vehicle repair claim” are their own data tyoe with fields and each one of them is saved to “Client Record” then they can be accessed without doing a search. It would simply be for example “This Page’s Client Record’s Hire Vehicle Booking Info” to reference. So yes, if they are complex structures which need fields themselves then it would probably be best to make them their own data type. Then still keep a field on “Client Record” for each, match the types, and save them to the Client Record.

1 Like

Ahhh, didnt even know this was possible. So i have now split the first part of the data so i have “Client record” and “vehicle booking” one of the fields in the vehicle booking is “booking owner” and the input for this is set to “client record”.

How do i now reference this in the group OR how do i save one data type to another?

just to give some more context. so this is the client file page, each of the blue bars ins a drop with various info. currently every one of these fields is all saved to “client record” so its allot. my plan was to break each of those bars into a separate data type

Hi Tom,

Sam here, with Bubble support! @williamtisdale is correct - the most straightforward way to do this is to make sure that your additional data types are ALSO connected to the main client record data type. So given your example from your follow up post, it sounds like you have a “client record” field on the “vehicle booking” datatype, but you’ll also want to make sure that you have a “vehicle booking” field on the “client record” data type. This way, in your dynamic expression, you can successfully enter “Parent Group’s Client Record’s Vehicle Booking” rather than having to do a search of the vehicle booking tables. You’ll also want to make sure to update the “type of content” of the group you are storing data in, as you are no longer storing “Client Record” data, but instead you are storing “Vehicle Booking” data.

Data can be very flexible in Bubble - you can connect things 1 way (only attaching the client record field to the vehicle booking data type) or 2 ways (attach a client record field to the vehicle booking data type as well as attaching a vehicle booking field to the client record data type.). Which choice you make largely depends on context, and how you plan to access the data.

I hope this helps!


ok thanks, makes sense but kind of scratching my head now wonder which comes first, the chicken or the egg.



In most circumstances, there really are no right or wrong answers.

For any given feature, there are numerous ways to structure and access the related data - most of the choice comes down to personal preference and how you prefer to write your dynamic expressions. Some of it can come down to performance at scale, but for the most part, as long as you’re avoiding advanced filters on large lists of things you’ll be okay :slight_smile:

1 Like