My question is, is it better to create a custom event to handle the workflows and direct the outcomes there…
or keep it with 4 workflows?
I’m trying to understand the most efficient way that would handle a lot of users, and also question if there’s a work unit cost that differs with each one?
Maybe I’ve been working on this too long today…and maybe it’s the huge snowstorm going on right now.
Hopefully I’m making sense here. Maybe either way doesn’t matter.
Added: I’m also trying to consider long-term best practices. I.E. is one way better for future growth?
Added more: I had originally gone with the custom event route, but ended up with 3 custom events…then had 2 workflows that called those custom events. Which led me to believe (from what limited experience I know about Bubble, this would be more intensive. However, AI told me it wouldn’t, but I think my AI is unhinged today and may be drinking. So, I’m wondering if 4 workflows is actually costing more than the custom even route?
A backend workflow would probably be better. The discounts are not high dollar…
example, someone goes into the pet groomer and gets 25% off their bill. The way the whole process is set up once they’re at the merchant, makes it useless for someone to sit at home and hack things and get all the codes. There are some more automatic steps I didn’t mention that matter once the correct code is entered at checkout at the merchant.
But yes, you’re probably correct that I should have made it a backend workflow . I’m still learning a lot of things about Bubble and the best practices.
Also, the QR Code isn’t actually a link. I understand what you mean by it being a link if you look at the url source. It opens the phone with some number that I’m not sure is even anything. The text is actually the merchant’s ID. I’m going to look into why their merchant id shows as a link. Not that it really matters in this case, since I have a built-in scanner that is specially designed to do tasks specifically for this app.
I have a JavaScript to bubble that runs when the scanner scans the QR code and verifies it as belonging to that merchant, which then goes through the process of redeeming the discount. Then of course, there’s the error workflow if someone denies camera access, etc.
Added: So the merchant’s ID doesn’t show as a link, I added TC to the dynamic expression so the output would be rendered as text and not show as a link…just in case someone somewhere decides to use another scanner. It would show as an error and give an error message telling them to use the built-in scanner.
True, but most of the people who like to cause havoc, just to create chaos are not necessarily doing so in order to save a few dollars. It is better to ensure security, not because you believe your end User will be attempting to hack your system to save a penny, but to avoid actual nefarious users from doing something that can at the very least, cause your business serious reputational harm.
If a pet groomer viewed your platform as not caring enough about their small dollar figures to secure the transaction coupon code, they might extrapolate that as not caring enough to secure their financial data, and the reputational harm is done.
After all, the jerks who spray paint the side of a building are not the ones who enter that building to conduct business…same concept applies to online businesses.
It is a general best practice for programming that extends beyond Bubble when dealing with money and sensitive data, which is ‘do not trust the client’ so any values entered on device, should be, if dealing with high or low dollar figures or sensitive information, be verified on server before proceeding.
If using a general QR scanner, most of what they do is read the visual representation of text, and in most situations that text is a URL (link) for which the QR code is meant to direct a user to. If you have a custom scanner built purposefully for your app, you likely have set it up to just read the visual representation of the discount code, and not necessarily the merchant’s ID as in my perspective, what you are doing here is making it so a user can scan a QR code to avoid having to manually enter the discount code, but I could be mistaken of what the purpose is of the QR code in your app.
Sounds like you are needing the QR code to hold two values, one the merchant unique ID and two the discount coupon code, as I’d imagine you are not setting up a system to only allow a merchant to every have just one single discount code and instead have a system where a merchant can manage discounts in a more robust way by setting their own percentage or dollar off value, dates of validity etc. In that scenario you’d need to know the merchant ID and discount code ID.
If however, it is a more simple setup of one discount code for one merchant, maybe I’m missing the overall point of this feature and it is more inline with a POS system for redeeming codes at a physical location and not a checkout on a webapp.
the code though, isn’t secret info. It’s more along the lines of a company posting use ‘SAVENOW’ at checkout for a discount. So if someone knew every code, there really is only so much they could even do without being at the merchant. I mean, yes, they could maybe go crazy and try to redeem every offer, but it really wouldn’t get them anywhere other than feeling something about being smarter than the average person. But, thanks for bringing up backend workflows…I think that is the best approach. There is a privacy rule on the code.
TC is just the merchant company’s initials. Adding TC to the dynamic expression prevents the code from being interpreted as numbers and considers it text.
Yes, the QR code is just the merchant id and doesn’t contain the code. The user has that discount open on their phone when they scan the code, so it automatically knows which discount is being redeemed, even if a merchant has, say, 100 different offers
I’m so confused. What are you building? Is it a system to allow a user while at a physical location to have a discount applied to their checkout? Or is it a system for digital use only?
Questions:
If there are 100 different offers and the offers are properly setup in the database, which would have the offer unique ID and related ‘merchant’, why do you need to lookup the merchant ID from the QR scan and not the Discount ID?
How does the addition of TC come into play? Originally it was added so ‘the output would be rendered as text and not show as a link’, but links are just text, but now it is ‘to prevent the code from being interpreted as numbers and considers it text’…this sounds to me like there may just be an issue with the javascript used in the scanner or the data field of the discount or the input element. Input elements can be set to ‘numbers only text’ so as to know it is not an integer, fields set to text can have either a string of numbers like 123 or words like one,two,three and be acceptable and the output via javascript should be capable of being coded to expect and only accept “strings” (so text).
What are the workflows even doing?
To be honest, what I have come to believe is there is no need for any workflows other than the running of javascript for the scanner.
In normal situations, without a scanner involved, that is simply a code to apply a discount, and you do not care about ensuring best practices around not trusting client device data, and will just process the payment or at minimum display total checkout value, you can simply have an input to accept a code, that input will be used in a ‘do a search for code’ in which the known merchant is already a constraint and the ID from the input value is a constraint (even with privacy rules on the discount code you can set those to still find in searches and keep the value visible). That do a search is the data source of a group on the page, and is used as a value in an equation to find the total of the checkout. There would be no need for any workflows to find the value of the discount and apply it to the checkout total.
If the issue is as a suspect, a question about how to run workflows for javascript to process the scanner, there should be one workflow that runs javascript and an event that is triggered which will run an action to send the value found from the javascript action to a group on the page so the scanned discount code value is used in a ‘do a search’ the same way an input value would have been.
Ultimately, all you need is to fetch the discount from a code, either via an input element or a scanning of a QR code that is a visual representation of a code (text).
Well, I know it probably sounds confusing. In my defense, yesterday the U.S. got hit with a massive snowstorm…the biggest in decades, and everything is shut down…it went through where I live. So the power was on and off. It’s on now.
Anyway, I’ll try to answer your questions. And when the app is live, I’ll give you a link, and you can understand better.
100 offers might be from 100 different merchants. Each merchant may have multiple offers with multiple codes.
The qr code is scanned to identify that the user is at the correct merchant who has the offer they want to use…and then when it verifies that, it goes on and redeems the offer.
Each offer can also be redeemed with a 3-digit code. Some older people, or whoever may not be into QR codes, or they’re so tech behind that it makes them uneasy.
So, the QR code identifies the merchant, and then that offer is redeemed. A QR code cannot have the code, or a merchant would have to have multiple QR codes. The way I have it set up now is they only need 1 QR code regardless of how many offers they have…and that 1 QR code does the heavy work of verifying, etc., and redeeming the offer.
The dynamic expression is fine. Adding TC first causes the merchant id to be output as text. It is then stripped on scanning.
Just running the JavaScript does not store everything in the database I need to store…and that is necessary because of all the other things that happen with the offer…thus the workflows.
I appreciate your feedback. I did figure out my original question and solved it. I had tried to delete the post, but it said I wasn’t allowed to…
but, I still appreciate your feedback because it causes me to consider other ideas, which can lead to different ideas
. I’m still learning a lot of things about Bubble and the best practices.