I’m in the planning phase of creating a reporting app for my company. Our company has several sites across the US and each site is somewhat unique in their own ways so they have their own requirements. Therefore the forms on the app can’t all be the exact same because each site will be looking to collect different data. The intention for this app is to allow managers the ability to customize forms to collect whatever data they need from users which would mean allowing them, as users themselves, to create new data types.
In searching the forums, I ran across this post from adamhholmes stating this isn’t possible, but there is a work around. I didn’t completely understand this because there needs to be a dedicated table (data type) to place data and work with it. Others asked for follow up and there was no response.
I was wondering if others could expand on this? Point me to a tutorial (video if at all possible) for doing this? Discuss my particular use case?
User’s cant make their own data types and fields, but what you can do is make a Form data type, then a Question data type. And your users can create new forms and create new questions and add them to the forms.
What I said is grossly oversimplified but it’s the general idea.
I have had to do something like this many moons ago, when PowerBuilder was “the cool thing” (so you can guess how long ago THAT was).
But anyway…
I think what you can do is give your users the ability to “rename” additional data fields, then enter in whatever relevant info they have for that field.
For example, YOU would know the data field as “textField1”, but the USER would enter in his/her own name, such as “Carrier Name”.
- You’ll need to alter your data table to have additional “spare” fields:
fields:
textField1 (datatype text)
textField2 (datatype text)
.
.
.
numField1 (datatype number)
numField2 (datatype number)
.
.
.
and repeat for date datatypes and/or whatever fields you want the users to have).
- Your new table:
Name:
UserFieldNames
fields:
fieldName (datatype text)
user (datatype User)
userFieldName (datatype text)
- Give the user the ability to update the UserFieldNames table. So when they are done, the contents of the table would be something like:
fieldName - User - userFieldName
textField1 - Bob Smith - Carrier Name
textField2 - Bob Smith - Carrier Phone
textField3 - Bob Smith - Carrier Terms
textField1 - Mary Jones - Company ID
textField2 - Mary Jones - Company Address
- Alter your data entry page to show the “spare” fields you added in step 1, BUT instead of showing the label “textField1”, you do a search in UserFieldNames where the fieldName = the name of the field the user is on and User = the user who’s logged in. And you display the userFieldName.
So instead of showing an entry field like:
Bob Smith would see:
And Mary Jones would see:
So the USER thinks they have a customized field only they have, but YOU are actually updating the exact same data field in the same table they both are updating. You’re just customizing it a little bit by replacing the label with the label the user wants to use.
Yes, this is probably confusing, but I think it pretty much covers a way to do what you want.
Hello and thank you for the response! I had to read and look this over a few times before I could get my mind wrapped around this. I’ve developed one app in Bubble and was brand new to development before then, but it’s been about seven months since I’ve done any real development work. So I turn the lights back on so to speak…
OK, I think I get what you’re saying. A lot of this can be achieved through conditionals. They are quite powerful. Certainly an interesting way to go about this.
My only concern is this seems like it can be messy. I know I didn’t mention this in the initial post, but we do hope to achieve being able to do analytics with the data submitted through these reports. So my concern would be two fold:
- Generic names with different labels all over the place would end up being a nightmare to keep track of for generating reports for analytics. At least that’s my fear.
- There would really be no way to know how many spare fields there would need to be. From a usability standpoint, how are we going to make sure all major fields are filled out if we don’t know what may or may not be needed? I could be misunderstanding, but my understanding is that we’re building like a template for the user and they just relabel want it to say and collect. Again, I don’t have a ton of experience with Bubble and what’s possible.
In the end, I’m just trying to decide if Bubble is the right tool to develop this app or if I should be looking for something else. From the sounds of it, it may be a bit limited.
Hello! Thank you for your response! How would users go about creating forms? Does this require a plugin for Bubble?
All you need is a datatype for the Form Questions and a datatype for the Form Answers…
I’d also have an Option Set for Question Type
Then, your Users can create new Form Questions (with fields for the various possible input types - such as text, number, image, date, yes/no etc.), and a field to denote that Type of question, relating to the Option Set.
You can create forms to complete on your pages using Repeating Groups to show the Form Questions, with input elements set to show conditionally based on the Question Type (i.e. text input, date pickers, image uploaders, etc.).
Then, your Users can create responses to the various Questions, by creating new Form Answer entries, each relating to a specific Form Question.
1 Like
Oh, cool! That seems pretty straight forward and makes sense. Thank you for spelling it out for me. The forms were just messing with my head. Now that I know how to attack it, I can move forward with planning. I just had to wrap my head around it. Thank you! I will give it a whirl once I’m done planning and see how it goes.
1 Like
Here’s a simple example of how I would approach this kind of thing using what I already outlined above, whether for creating custom forms, custom fields for a CRM, or anything that requires user/created data fields…
Dynamic Form Test (bubbleapps.io)
(note: as this demo is on free plan, I’m using front-end loops to create and update the fields, which isn’t ideal - I’d usually use a recursive backend workflow for that)
…but it should give you an idea of how to approach the basic data structure, and how to go about creating and updating the relevant database entries…
1 Like
Wow, that’s pretty neat! Thank you for taking the time to put this together for me so I can poke and prod at it to kind of see how it works. I like that I can see a little bit in the editor to get an idea of what’s going on and start planning how pages should likely function. Very appreciative! Thank you so much!
1 Like
