I’m building a form where users can select the number of existing loans they have from a dropdown, with options ranging from 0 to 6.
For example, if the user selects “4” from the dropdown, then the repeating group will show 4 cells. Each cell contains 3 input fields:
An input for the ‘type of loan’,
An input for the ‘monthly repayment amount’
An input for the ‘first repayment date’ of the loan.
When the user fills out the 3 inputs in all 4 cells and wants to proceed to the next page by clicking the Next button, I want to create 4 entries in the database (of the Loan datatype), each corresponding to the data entered in the 4 cells of the repeating group.
I’m having trouble implementing this functionality. How can I achieve it? Any guidance would be greatly appreciated!
Pretty much the only way to do this is using the Orchestra plugin. It’s going to feel a bit odd at first but after a while you will be able to use it easily!
If you are good with JSON and API’s you could do this using just text but it would take longer and be harder to maintain in my opinion.
Hey @samir.elkaddouri79, as mentioned above, to run workflows on each individual cell in a repeating group, you gotta use the Orchestra plugin.
However, you can get the same end result if you modify your build.
Rather than relying on the Next button to be the trigger to create the database entries, create them before hand in your database, and have the Next button be the validation step.
Add a draft field (boolean or date) for your Loan datatype
– if you go with boolean (yes/no), make it yes by default
Enable auto binding for type of loan, monthly repayment amount, and first repayment date (both under privacy settings and each respective input field)
When the user lands on your form, run a backend workflow to auto create all 6 possible values for the user, where draft = yes
When the user selects a value from your dropdown (0-6), display the appropriate # of loans that were created above
Because you enabled auto binding, as the user makes changes for each cell, it will get updated in the backend
Finally, use the Next button as the trigger to flip draft = no for each of the cells in the repeating group (this way, if the user selected 4, then only those 4 Loans would get moved to draft = no).
Cool! This is similar to how I would do it, but I wouldn’t use a repeating group.
Since it’s a fixed 0-6 choice, I would use 6 groups and show/hide based on number of loan selection and create them in bulk as steps in the workflow when user clicks next, this may be less scalable but I think for a fixed number it is easier, does not backend workflows or plugins and it saves space by not creating 6 drafts for each user. literally takes minutes:
That’ll cost a pretty penny with all those unused records created in the DB. Another penny for every deletion of those records to.
OP, @hanan1 posted a solution that does not use RGs hence making it easier to grab answers. You can store them in states first without meddling with RG states.
Before the WU based model this was a viable option. In fact, I still use it when I’m absolutely guaranteed those records will be used. However, when we have 100 users each do this 10x per day, you get a cost that most would consider material. Now apply the same coding method in 20-50 other places in your app and it very quickly becomes unprofitable. We should never touch the DB unless we absolutely have to.
I’d suggest that there’s a better solution from both a user perspective and simplifying the WF needed.
As a user it’s more intuitive to add one loan at a time.
User clicks on “Add Loans”
One loan data type is created (can be “draft” as described by @bek )
Loan data type is added to users “Loan List”
First line of RG is then visible (RG dynamically loads all loans in “Loan list”)
Fields in RG autobind on Loan data (or when confirmed by button click)
Then user clicks “add another loan” or “finish”
Add another loan creates a new “loan” and adds loan to “loan list”
When all loans are added, clicking finish changes all loans “draft field” to “no” - using “make changes to a list of things”
Best way to do this is to take the values from the RG cells and translate them into JSON. Can use a paid plugin called JSON assistant to do this (maybe others but I use that one)…then need to setup the API connector to work with bulk update for your data type of Loans…once the user is ready, can send the JSON through the API call to bulk create as many loans as the user created. Costs less than any other method mentioned, and you can allow a user play around with the RG and loans as much as they want without touching the database, and when they are ready, they press submit button and you run the API call.
Just on observation from a non-tech no-coder. I don’t see the point in using JSON and API when there’s a genuinely no-code option. Surely the whole point of Bubble is to only use code-based tools as a last resort? I get that for code-savvy builders there are often easier solutions (for them) using some code. But the downside is that the built in error checker can’t check the code based pieces. For me the robustness of Bubble’s error checking (and prevention) is why I use it.
JSON is text, not code. It’s just simply formatted in a particular way. API is not code it’s using Bubble built in API functionality of every bubble app and the api connector by bubble. Bubble manual explains how to use it very well.
I don’t code. I’m nontechnical also. But ultimately the point of using the text in JSON format and API connector is to build a better, more efficient and lower cost to run application.
Kind of a meta ramble, and beating a dead horse here…but its really concerning to see the mental gymnastics made in the sake of saving a few WU (even at scale).
Obviously a side effect of WU introduction and devs wanting to min/max WU usage, but where do we draw the line in building spaghetti code (that takes longer to build and longer to debug later) for the sake of WU?
At what point do we ask “is what I am building profitable via bubble?”
I think you posted in wrong thread. There is an active thread where people are discussing saving WUs and the pricing structure. This thread is about optimal way to get data from RG cells into DB
Code is also just text formatted in a particular way I don’t doubt that JSON and API creates other perhaps more efficient ways to do things. I do this myself (but I’m four years into Bubbling). The big reason not to do that, until you really have the skill to do so, is Bubble’s error checker won’t pick up any resulting bugs. And that is a big issue for people who aren’t long at Bubble.
And for this particular problem I’d humbly suggest that JSON, API and Bulk Data Upload is a sledgehammer to crack a nut.
IMO the reason for this is the fundamental design of Bubble. It’s an existential aspect of the system. The DB is live, in the sense that changes to the data are immediately visible to the user. There’s no getting data from the backend to display in the frontend. So why would you ever want to store data locally when you can immediately save it and have access to that saved data? And run WFs based on changes to the data. For things that don’t need to be saved we have states. Also states for capturing data at a point in time and passing data between elements.
I don’t doubt that JSON and API creates other perhaps more efficient ways to do things. I do this myself (but I’m four years into Bubbling). The big reason not to do that, until you really have the skill to do so, is Bubble’s error checker won’t pick up any resulting bugs. And that is a big issue for people who aren’t long at Bubble.