OSB Conflict Checking
Refer to Product Ideas
I am having issues configuring the conflict check status in OSB. I believe that in a previous version the system allowed for two separate values in the Booking Conflict Check and Resulting Booking status.
Currently, the system is applying the conflict check logic to both existing bookings and the new booking being created. This creates a conflict scenario when a client’s Conflict Check Status is set to the same level as their resulting booking status.
Here’s the real-world example I’m working with right now:
The client wants their conflict check to occur at Final Payment and also wants the resulting booking status to be Final Payment so that the system locks down future reservations once that status is reached. However, OSB is blocking this because it’s checking the new booking’s status against the Conflict Check threshold — preventing the booking from being created in the first place. So the work around to get the resulting booking status to be correct, is that we have to set the Conflict check to a higher status which allows negates the conflict checking altogether.
I believe, functionally, the Conflict Check Status should only evaluate existing bookings that already occupy that space/time, not the new booking being created. Applying the threshold to the new booking defeats the purpose and blocks legitimate workflows.
Expected behavior:
- The system should only evaluate existing bookings whose status is equal to or greater than the Conflict Check threshold.
- The new (incoming) booking’s status should not be part of that logic.
This behavior would allow clients to use the same status for both conflict checking and booking assignment, which aligns with their operational needs and avoids unnecessary blocking.
-
Jeremy - this is the same discussion we had been having with GWU. Is this post on their behalf?
@... has written up a ticket to adjust the conflict check to only consider existing bookings.
The ticket has been sized and its not a small amount of work, so trying to figure out where we can fit it in on the roadmap.
-
This is not for GWU. This is for Kino Sports Complex.
-
Thanks for confirming. I assume you agree its the same request as GWU.
This is something we're considering for the roadmap, but not yet confirmed. Do you have a workaround?
-
For reference here is all of their status codes:
Space Booked 05
Confirmation Letter Created 10
Confirmation Letter Sent 20
Quote Created 22
Quote Sent 24
Quote Negotiation 26
Quote Approved 28
Use Agreement Created 30
Use Agreement Sent 32
Use Agreement Approved 34
Down Payment Collected 36
1st Installment Payment 38
2nd Installment Payment 40
Final Payment 46
Admin Booking 50
Reconciliation Created 60
Reconciliation Sent 62
Vendor Charged Overage 64
Vendor Reimbursed 66
Account Settled 68
Event Cancelled (KSC) 80
Event Cancelled (Vendor) 82
Event Archived 90
Following up on this. I do not currently have a work around. Kino Sports Complex is trying to reserve their pickleballs courts. They want it to be self service so when someone books it they want that court to no longer be available for others to reserve. They will not have anyone manually managing the statuses on these bookings as they are supposed to be self managed. So the issue that I am having is when I set the Booking Conflict Status to “Final Payment” and the Resulting Booking Status to Final Payment - the system lock everything down.
Booking Conflict Status to “Final Payment” and the Resulting Booking Status to Final Payment
When I set the Booking Conflict Status to “Admin Booking” and the Resulting Booking Status to “Final Payment”, the system allows for it to go through but then doesn't block out any reservations with Final Payment as the status until someone manually moves the status in back office to a status of Admin Booking or higher.
Booking Conflict Status to “Admin Booking” and the Resulting Booking Status to “Final Payment”
So the only option to is to have the resulting booking set to less than the conflict booking status which then requires someone to manually manage the booking in back office to put it into a status that would be conflicting. This is a basic functionality that all clients need for OSB. I typically see two scenarios: requestable vs reservable.
Requestable: requires a person to review and approve. Will move to a higher status if approved. Until then as many requests can come in for the same space. Booking Conflict Status: Firm, Resulting Booking Status: Request
Reservable: does not require a person to review and approve. End user should be able to book the space if there is no conflict and when it is booked it removes the ability for anyone else to reserve that space. Booking Conflict Status: Firm, Resulting Booking Status: Firm
-
@... can you schedule an internal call with Ben to see if there are any workarounds here. The only option may be to wait until ME-7026 can be completed.
-
We will meet on 12/9 to discuss. I'll update with our findings shortly after.
-
Overview from the OSB Conflict call with Ben and Jeremy:
Issue Identified: OSB's conflict checking logic prevents customers from setting firm/public bookings at the same status as the conflict check threshold, forcing manual admin intervention to move bookings up and remove them from availability.
Root Cause: Historical design decisions - a previous attempt to change this behavior was reverted due to negative customer feedback from long-time users. (We can't find the feedback that led to the change being reverted)
Proposed Solution: Configuration-based approach allowing opt-in to new behavior, possibly with status exclusion options to give customers granular control.
Next Steps:
- Updating opt-in requirements for ME-7026 and sizing with Ben
Short-term workaround: Remove admin holds from spaces offered online to avoid conflicts
Please sign in to leave a comment.
Comments
7 comments
Date Votes