I have an app that shows incoming orders from online store to multiple employees and they have the option to claim an order. Lately, business has picked up and multiple people try claiming the same order resulting in two of them thinking they have the order but then come to find out the other person does. It’s tough because they get paid per order and I can’t explain to them why one person got it instead of them. Can someone help me understand how/why this may happen please?
Would you tell us more about how your setup is?
There might be a number of things going on here so for us to be able to help you, we need to understand what is going on in your app and what you have done so far.
How are you attaching the employee to the order? How are filtering what each employee sees? How is the order created?
Thanks for trying to help me out @Santiago_Perez1
I have a list of orders on the home screen. These orders come into spreadsheet from BigCommerce through Zapier. The screenshot above is what an employee would see when they open an order. Once they claim it, it disappears from the list of open orders so no one else can claim it. The user who claims it, their email gets put into that row in an owner column. I have the list filtering to only show unclaimed orders.
The problem is two employees might hit the claim button right after each other.
Have you setup visibility conditions for the button to disappear once the offer has been claimed?
I’ve setup visibility for the order itself to disappear when it is claimed. Considering that, I wouldn’t think doing so to the button would make a difference, but I can try that.
Question: If one person taps “Claim” and 1 second later before the button disappears someone else taps it, what would happen? Would it log the first person who tapped it or the last person?
Taking into consideration that the update sometimes takes a few seconds , it is probably that it logs both people. Also, if a user is in that screen when someone else has claimed it, the screen is not going away until the back button is pressed.
I am assuming that in you button you have a custom action setup, try giving a condition to that action that only adds the row of the relation (assuming that’s how you’re doing the visibility conditions/filter) is empty. Else > show notification “This offer has been already claimed”
This sounds like a visibility delay issue. Based on what you’ve said I would imagine that if two users both hit claim within a second or two of each other then the latter will likely get the claim because it’ll overwrite the first one. Perhaps check to see that the email is empty before writing to it.
@V88 that was my assumption as well – that it overrides the former person who first claimed it. I’ll try this and report in a few days if it’s working out as a solution.
Unfortunately, this doesn’t help. I still implemented the visibility conditions and notifs as good practice though. Each time I “claim” an order, it takes exactly 7 seconds before the visibility conditions are activated for another user. During those 7 seconds, if the other user “claims” the order, the app will give it to the latter as I can see it overrides first user in spreadsheet.
When I have two phones “claim” the same order at the exact same time, it shows as “claimed” on both devices and takes approx. 12 seconds (every time) before it disappears from the first users screen.
I guess the time it takes to hit the server isn’t something we could solve for so maybe I just need to tell them wait a few seconds to see if they got the order? At the same time, it’s unfair to the first person who “claimed” it. Not sure what to tell them. Is there a way to say don’t override if something is not already there?
Is this a Pro app? Are you using google formulas?
I just realized tha @Jeff_Hager is typing. He will have a better solution.
Just spit-balling some ideas here, but assuming you have a table with a list of employees…what if you create a column in that employee table that indicates if an employee is on or off duty…then create a relation to that table from whichever table is used when an order is created, so you get a relation of all employees that are currently on duty. Then using that relation, you create a single value column that returns a random employee id. My thought is maybe when an order is created, you write that random employee id to a column in the order, so an employee is assigned an order. The thought is that you could set it up so each employee only gets a subset of orders. If only one employee can see a particular order, then only they can claim it. That of course could get ugly if for some reason an order isn’t claimed and nobody else see’s it. Maybe you could set it up with some timestamps, math, and IF columns to release it after a certain amount of time, but then you are back to your original problem where everybody would then see it.
Another thought is that instead of Claim button, it could be a Queue button. It would function the same and put the employee’s id on the order, but it would also set a timestamp. Then you could have a math column that sets the timestamp plus 20 or 30 seconds. After that time elapses, then you could show who the last person was to claim it, and if the signed in user matches, then show the claim button.
Another thought is to let them however many employees claim an order, but use the same timestamp trick with a math column to add 30 seconds or a minute before the order shows up in a ‘claimed’ list. That way employees can attempt to claim an order, but they still have to see it on a separate ‘claimed’ list before they can begin to fulfill the order. Whoever claims it last will get it, but they can only work with orders that show up in their claimed list.
None of these are great ideas, but hopefully it will give you some other ideas to try. I think you are going to be fighting that few second server delay no matter what, so you either need find a way for an order to be viewable by one employee at a time, or adjust the flow with some delays so they can first confirm that they have successfully claimed the order. I think that’s just the nature of the web. There’s always that slightly disconnected nature between the server and the end user.
Thanks for the robust breakdown of ideas @Jeff_Hager !
I actually do have a column for on-duty and off-duty which I use to determine who can see available orders. I also have a “claimed” list which is where all their claimed orders show.
The idea about individual employees seeing a subset of orders is a bit too tricky in my opinion. Although it will be random, I don’t want there to be a chance of one person getting more opportunities over another by mistake. The “fairness” factor is what I’m trying to find a solution for.
The idea to have a queue experience might be the best way of framing it. “Claim” your order and wait couple seconds to see what happens in your “claimed” list. The only problem it still doesn’t solve is the fact that it’ll override first person who claimed it.
@Santiago_Perez1 it is a pro app and yes, I am using a couple formulas. Are you thinking this would add to the time delay?
I wonder how apps like Instacart and Door Dash handle things like this where multiple delivery drivers accept an order at the same time…
The formulas might be a problem if they are happening on the same sheet where your claim are being housed. Try and see if you can move those calculations to Glide. I do believe tht would improve the delay a tiny bit.
Unless @Jeff_Hager has a better idea.
Apologies if this has already been covered, however are you using a custom action to “claim” the order via “set columns”? If so then are you checking if the email column is empty before updating it? If not, could you?
@V88 Yes I have a custom action set to check if email is empty before setting the columns.
@Santiago_Perez1 I will definitely try to move some functions directly into glide. Was just easier to do functions in sheets than figure them out in Glide.
Ok, I’ve got the same problem. Users are ‘kicked out’ because:
Inline list items visible based on conditions - tmp-email is empty
User 1 clicks - and an action sets them to tmp-email
And the next screen is filter tmp-email is signed in user
So far do good …
But there is a 10 second delay from the user 1 device to the server
During this 10 sec period, user 2 (3…4…) click - the item is visible at that time because the server has not picked up the user 1 set column
User 2 …. OVERWRITES temp-email - they can now see the screen on their device
- meanwhile user 1 is no longer Tmp-email, and cannot see anything on that screen anymore (not even the tab… and so is ‘kicked out’
User 3 then clicks…. Kicking out 2….
There is nothing that can be done with delays and math columns …. As they are resolved individually on each device.
I’ve an idea on how to address the record locking issue. I’ll update soon I hope… with success
Timestamps are not reliable either…. Why time zone are each user in? every user time, and formula to calculate on time, is based on the user device ……
Cunning plans are required