Why is there Buy Button limitations?

We need the ability to map a math field to the buy button. Looking to simply multiply the quantity by the cost to come up with the total and map it to the buy button. But that is not an option.

Anyone know any solutions? What am I missing?

@david is this a bug or designed this way? Trying to have my “total” field link to my Pay button.

Buy Button columns must be basic data columns for security reasons for now. We want to allow computed columns but we must make it possible for the server that verifies the purchases to run the calculations—right now our servers cannot run calculations, only your running app on a device can.

2 Likes

@david thank you for the response. Do you know how I could accomplish this in the meantime or when that feature would be live? My use case would be to calculate total hours and then map that to the pay now. For example, if I worked 5 hours at X amount, that total would map to the pay button.

You would have to write the calculated value to the sheet. Most likely by passing the calculated value through the Column Value components in the form. Then view the form details in the app and set up the buy button to use the form response values.

I think that’s what I did but the buy button only allows “text” values. So how can I get my math column with the total to transition over to a text column? I am using glide sheets not a google sheet.

You have to calculate the math value before submitting the form. You can’t do the math after the form has been submitted. That’s why I say to pass the calculated math value through the Column Value components. The result in the sheet, after the form is submitted, is just a basic column value. Not a math column.

@Jeff_Hager I am not sure I am following.

On my form, I have the new Event Picker component. The user selects a time frame. From there the duration is calculated using a math field. I have the duration multiplied by the users rate (which is a column value included on the form).

From my understanding the calculation happens “after” the submission takes place. Therefore I cannot bring over the value as a column from the previous screen because the calculation has not taken place yet. Unless I am missing a step.

That’s where you have to fill in the blank and probably restructure your app flow. If you want the buy button to work, the value needs to be calculated before even opening the form. This could be a details view screen where you fill in your values and have them write to user specific columns in whichever sheet is being used for your current view that contains the form button. Once the values are entered and the calculations are done on that sheet, only then do you open the form and pass in those calculated values through column value components. I’m not saying it’s a good flow, but it’s the only option right now. Basically calculate the value, then submit that calculated value through the form to a basic column.

@Jeff_Hager I understand what you are saying. I will try to rig something up. Thanks for your feedback.

Do you know of any ways to clear the user specific value from the previous screen once the form is submitted? I would only need it so that the value pushes to the form column but wouldn’t want it to live on the page for that user indefinitely.

1 Like

That, I don’t know. That’s were it starts to get a little ugly

@david I did find a solution but it does come at a cost. Basically in order for me to use the pay button with quantity calculation it requires 4 tabs to make this work. So basically a single transaction comes at the expense of 4 rows. It’s going to chew through my row limits.

The first is where the item is stored. The second does the calculation to be mapped to the pay button and the third is the payment record. The last is a copy of the payment record to create the relation between the payment and the user.

If we could have quantity calculate and also the ability to relate payments to users, this could be avoided.

Just wanted to give you my feedback for when you work on the solution.

This is so complicated… changing quantity should be one of the easiest things.
Are there any good examples in a template or something that can be shared? I’ve read through this three times and can’t replicate it.

I can get to the point where you can add a quantity through a number entry, but then it keeps that value. So if two users are doing it at the same time, they mess each other up.

How do you get the buy button to look at different tabs? I only see that you can point it at one tab, and so all of the calculations along with product data, descriptions, etc are in one place. Is that right?

@frenat

Yes, it’s not easy. So here is what I did:

Tab 1: product, price, info etc.

Tab 2: quantity, product info from tab 1 and the calculated totals

Tab 3: review order, basically bringing over “text” values from tab 1 and 2. This is so the pay button can work and where your pay button lives.

Tab 4 is the payment

Tab 5 is the a copy of the payment (optional)

The pay button only lives on the review order tab because by then all the values are in text format and can actually be mapped to the pay button.

I cannot share the exact build because it’s for a client but I can help you build yours out. I know it’s hard to follow and I am not explaining it that well.

Yeah, this is nuts! But thanks for your help!!!

So I guess I’m not following where a user puts in that they want 2 items.
Currently, the “landing” page is the product page. And that seems like the Buy button is only able to use that page.

Would you be able to copy (with dummy data) a google sheet and share it?

Okay so on your landing page the “buy” button is actually a form button connected to the second tab. I would call this button like “add to cart” This tab brings over your product info but allows the user to put in the quantity.

Then your second tab, let’s call it the cart. This creates a whole new record that lives in your tab 2. From here the user will see the product with the total price. So you need another button that says like “check out”. From here it is taking your values from your product page, your totaled price and creating a third record. Because this is the form that brings over all your values as text.

Once that last checkout is complete, this is where you can finally place your buy button mapped to the “text” total.

The whole thing is smoke and mirrors. The challenge is making this process feel seem less and fluid for the end user. But in the backend it’s actually a hot mess with tons of work arounds.

I was able to do it in a way that felt natural so though I am mentioning all these tabs, from the user perspective they are oblivious to it.

Ok, I think we’re getting closer!

So the first screen, they enter a quantity, and that carries over to the second. But, if another user is on that first screen, they can overwrite that first quantity.

What am I missing?!

That won’t happen within a form, but if you are using entry components on a details style view, then you can create User Specific columns, which will hold unique values for each user.

How do you do something like this within a form then?