Booker25 can detect various conflicts that arise when Reservations are entered into the system. Furthermore, you can configure what happens when these conflicts are detected. This article explains the type of conflicts that can be detected, and all the configuration options for handling them.
Remove Double Booking permission from System Administrator profile
If you have enabled conflict checking but it does not seem to work, double-check if you have removed the Allow Double Booking permission from your profile, as described here: Booker25 Clean Install
Shared or Single Conflict checking?
Booker25 can handle conflict checking in two different ways.
Consider every dimension field/junctions as separate for conflict checking
Consider all dimension fields/junctions inside a dimension as a single dimension (Default)
You can switch between the behaviours using the Use Shared Conflict Checking checkbox on the Dimension object.
In a clean Booker25 installation a dimension field B25__Contact__c and a dimension junction B25__ReservationContact__c exist. The two distinguish themselves by having two different contact relations to the reservation. For example, you are using this system to create reservations with a primary contact from a customer (dimension field) and a list of guests (dimension junction).
When you use option 1, considering every dimension field and junction separately, a person can be the guest and the primary contact at the same time. The two reservations will not conflict.
Option 2, enabling shared conflict checker, is for most scenarios the more intuitive approach. In this case, no matter how the contact is added to the reservation, either as a guest or as an organiser, it would block the contact being booked in another way.
Things to look out for in the shared conflict checker.
When shared conflict checking is enabled, all fields and junctions under that dimension need to use the same conflict checking type. You can’t mix a field that uses hard double booking checking with a junction that uses soft double booking checking. You will get a warning when you try to enable shared conflict checking but not all the conflict checking types are the same. In other words, if you say that a contact cannot be double book this should be true for both the primary contact and the guests in a reservation.
All fields that use capacity checking also need to use the same capacity field for both the dimension field and the dimension junction.
There are currently three types of conflicts that Booker25 can detect:
These happen when creating a Reservation outside of the defined Availabilities for a related record. For example, creating a reservation on a Friday for a staff member who only works Mondays through Thursdays. See this article for information on how to set up Availabilities for your Resources, Staff or other objects
Double Booking Conflicts
These happen when creating a Reservation for a record that is already occupied by another Reservation. For example, creating a Reservation from 8-11 and a Reservation from 9-12 in the same room
These happen when creating a Reservation that causes the related record's capacity to be exceeded. For example, creating a Reservation with 10 attendees in a room with a capacity of 6
There are three ways Booker25 can handle a detected conflict when creating (or editing) a Reservation
Ignore the conflict, and don't notify the user. The Reservation will be saved normally
Warn the user, but still allow them to save the Reservation into the system. A Conflict record will be created in the database so these problems can be solved at a later time
Give the user an error, and do not allow the Reservation to be saved until the problem is solved
You can configure Booker25 to handle different types of conflicts in different ways. For example if you have Resources and Staff, you can configure the following scenario:
Staff can't be double booked
Staff can't be booked outside of their working hours
Resources however can be booked outside of their opening times, without a warning to the user
Exceeding a Resource's capacity will give the user a warning, but still allows the user to save the Reservation
In configuration, the above scenario can be achieved in the following way:
On the Staff Dimension Field, set 'Double Booking Checking' to Hard
On the Staff Dimension Field, set 'Availability Checking' to Hard (note: this is only possible if you have already entered a value in 'Availability Lookup' on the Dimension)
On the Resource Dimension Field, set 'Availability Checking' to None
On the Resource Dimension Field, set 'Capacity Checking' to Soft
For this last step (4.), you will also need to enter the API names of the two fields telling Booker25 which fields to compare with each other to detect if the capacity is exceeded.
For 'Reservation Quantity Field', enter the API name of a number field on Reservation, such as 'B25__Quantity__c'
For 'Dimension Capacity Field', enter the API name of a number field on Resource, such as 'B25__Capacity__c'
Exceptions (bypass conflict checking)
For Double Bookings and Capacity checking (so not for Availability checking), you can configure exceptions to let some Reservations pass through validation that would otherwise result in a Soft or Hard conflict. Let's say you have a few Reservation Statuses that do not count towards Double Booking or Capacity checking. A Canceled reservation for example may have the capacity filled in, which should not be taken into account during Capacity checking. You can create an exception as follows:
Create a checkbox named Canceled__c on the Reservation Status object.
Set this to TRUE on the Canceled Reservation Status record
On the Dimension Field of the Dimension you are working with, set the following fields:
For 'Reservation Allow Double Booking Field' enter the following value: B25__Reservation_Status__r.Canceled__c
For 'Reservation Skip Capacity Check Field' enter the following value: B25__Reservation_Status__r.Canceled__c
Now, all the reservations with a Reservation Status that has the Canceled checkbox set to TRUE will no longer trigger these checks and can be saved normally.
Finally, for Double Bookings, you can also reference a checkbox on a related record, to indicate that the related record always allows Double Bookings. Let's say you have Resources with a checkbox Can_Be_Double_Booked__c set to TRUE, then you can configure the following on the Resource Dimension Field:
For 'Dimension Allow Double Booking' enter the following value: Can_Be_Double_Booked__c
Double Booking will now be allowed only for this Resource, even when the overall checking has been set to 'Hard'