Hello. So I am writing logic to match “App: Sales” entry as it happens (row inserted) event to what the user was trying to buy. In my case, a user can purchase multiple instances of a service I am offering via my App. User can try multiple instances of my service in trial mode and then decide to pay for the one (or more) they like. Since the “App: Sales” sheet only contains email, name, SKU and item name, how can I map the sales row to exactly one instance of service the user was intending to buy?
So to narrow it down further, I introduced a checkbox (terms and agreement) before the user went on to compare plans and buy one. The checkbox would give me another value to narrow it down from a set of trial records the user is building. This is kind of a work around because the user may check the box and then decide not to proceed with payment then go to another instance, check the box and pay for that one.
However, this is still not full proof. Can there be another unique ID that I can pass in the checkout process that allows me to identify the exact instance the user was intending to buy?
On the same topic, will the row inserted event be triggered if multiple people made transactions at the same time? It would be very bad if row added event is missed due to concurrency limitations.
Thanks for help.
If a user trialed 3 instances of your service, I imagine they would have the same SKU? Could you concatenate since sort unique number to the SKU? For example, if your SKU was 12345 and the user purchased the second instance, you could maybe send the SKU to Stripe like 12345-2. That way it will be written to the App:Sales sheet as 12345-2 and you will be able to split the value into separate SKU (12345) and Instance (2) values.
As for concurrency, I think Glide is pretty capable of handling multiple row inputs at once. I’ve never heard of others having issues with data being lost.
Your solution makes sense but I am thinking how to make it work. Here is my flow.
- User is on the event details page (custom event she designed)
- Checks agree check box
- Clicks compare plans and pay button
- Lands on compare plans page
- Goes to plan details page (each plan has unique SKU)
- Clicks purchase button which is glide buy button
Where and how can I concatenate my unique identifier to sku?
I think the problem you have is that you are too many levels deep choosing plans to have access to the event details. I think to make this work you would have to place a list of the different plans on the event detail page for the user to look through (or a link to screen button that would show all of the plans). Once the user has learned about all of the plan options, then they would have to come back to the event details page. There you could have a choice component where the user can choose the plan they want to go with. Now that you have the chosen plan saved to the event sheet from the choice component, you can use a Relation and Lookup to pull in the SKU of the chosen plan into the the Event sheet. Now you can create a template column that will join the Event ID and the SKU into one column. Place the Buy Button on the event detail page and pass the concatenated SKU into the Buy Button.
Thanks Jeff. It all checks out other than a couple of things.
-
For Buy button, “Product Info” section, Product ID and price are not allowed to be lookup columns. Why? Name, description and image are allowed to be lookup. However, I implemented product ID and price in event sheet with formula (arrayformula and vlookup). So I can still use them.
-
This is much cleaner workflow to finish a purchase as it is not too deep but it has some issues.
-
Say I selected plan A from the choice which is 19$. I go to checkout screen (pay button), it looks good. I go back with cancel.
-
I select plan B and immediately click the pay button. I see price from plan A (19$) on it. When data gets refreshed (automatically - 3 seconds), it updates to the right price (49$). This behavior is buggy. My hunch is, the price and product ID columns, which glide doesn’t allow to be lookup columns are taking longer to get to the App.
-
I can do the joining logic with sheet like I did the two columns but the delay problem will still persist.
Please suggest.
1 . Is your lookup based on a Multiple relation? If it is, then I would change the relation to a single relation. I would think the lookup would then work, but I have no experience with the Buy button, so I’ve never tested it out.
4 . Hopefully if we get the lookup to work, then there would be no delay. I would suggest maybe you could do some sort of IF-THEN-ELSE logic to compare the selected SKU to the lookup SKU, but Glide doesn’t allow us to compare 2 columns. We can only compare to static text in an IF-THEN-ELSE.
5 . Same here, if we get the lookup to work, then you can use a template column instead of joining in the sheet, which would eliminate any delay.
Try checking if your relation is multiple or not. I’m hoping that’s all we need to change to make everything else work.
The relation is not multiple. So product id and price do not support “derived” columns at this point. Is this intentional?
hmm, that surprises me, but like I said, I haven’t really played with the buy button. I did give it a try in staging and now I see what you are talking about. I wonder if that’s something Glide could change since this is a good use case. I was thinking you could use the template column to encode the SKU and event Id into description, then split it apart later once the purchase is made, but it doesn’t look like that information comes into the App:Sales sheet.
* Disclaimer, I started with the following idea, but the IF-THEN-ELSE column doesn’t allow me to compare to column values, so the following won’t work, but I’ll post it anyway in case it gives you ideas.
One last idea is to have the choice component for the plan choice.
Create a lookup in the data tab to get the SKU for the selected plan
Create a template to join the event id and the SKU.
In the sheet use the formulas to join the event id and SKU and get all of the other details you need (price etc.)
Back in the data tab, create an IF-THEN-ELSE column that will compare the template Event/SKU to the Event/SKU that’s set in the sheet. (This is where I realized this idea wouldn’t work. We really need the ability to compare 2 columns. The intent was to create a true/false value to hide the buy button until the template id/sku equaled the sheet id/sku)
Thanks Jeff. I keep exploring this. But if those two attributes of the buy button start acting like the first three, it would be really great.
1 Like
Jeff, Thanks for narrating everything. Finally, I was able to create a formula field in my event sheet with SKU + separator + EventID. I assigned this column to “Product ID” of buy button. So it comes back when transaction is posted. I then split it and I am able to uniquely identify the instance user paid for.
This even works when email ID is changed at the checkout screen for some reason.
Thanks again.
1 Like
Hello together,
regarding “I wonder if that’s something Glide could change since this is a good use case.”
How can we push Glide to change it, so that it also possible to use LookUp Columns to retrieve data for the Buy Button? Do they have a formular or Email address to send these kind of requests?
I have a similar problem and also need to use that column to get the Price for the Buy Button.
Thanks!
1 Like
These forums are quite good. Things definitely get picked up if filed in the right category.
1 Like
Hello, can you please explain how did you create the formula field? Thanks
Nevermind, I’ve found it. Thanks
So, I am here again because now the Stripe receipt to my customer shows funny description because of all the contact I am doing to implement this workaround.
I am passing SKU~~~ID as ProductID to my buy button.
I asked Stripe if they can do something. They said it is what you pass.
What are you expecting to see in the description? How does this compare to the app: sales sheet?
In Stripe description, I want to see something that makes sense to end-users. Like “Plan C”.
The string you see above is what I get in SKU in my App:Sales sheet. I use it after breaking it down to extract SKU and ID. So it is useful.
For now, I removed ~~~ with a slash to make it less intimidating to the user.
