Work with locked bookings and resolve conflicts
Frequently, customers might have preferences on what time an item should be scheduled, and they might also prefer a specific resource. After that item is scheduled and a booking record is created for it, organizations can ensure that it isn't adjusted when an optimization job runs. Alternatively, perhaps the customer does have some flexibility in the time that the booking is scheduled for but not the resource that is assigned to it.
Work with booking lock options
When optimization jobs run, the job needs to know if a booking has the flexibility to be moved or if it needs to be locked to a specific time period or resource. You can complete this task by defining the scheduling lock options, which are located on the Resource Scheduling Optimization tab on the booking record.
The four types of scheduling lock options that Resource Scheduling Optimization (RSO) supports are:
Resource - When RSO runs, it can move the booking to other times, but the booking must stay assigned to the same resource.
Time - RSO can assign the booking to other resources, but the booking must keep the same estimated arrival time.
Resource and Time - RSO can't move bookings to any other resource or any other time, but it can make some changes.
RSO preserves the estimated arrival time and assigned resource.
The booking's start time and estimated travel duration might be changed if RSO schedules a booking in a new location before this is a locked booking.
Time Range - RSO can move a booking with this lock option within certain time ranges (ensure that the Estimated Arrival Time falls into this time range).
RSO is also able to reassign bookings to other resources by respecting this time range and the following time-related fields.
Time Range option
Most of the scheduling lock options are straight forward. RSO can't move the booking to a different resource or time depending on what options are defined. The Time Range option is a little more complex. When you choose to use a time range, RSO looks at the values that are assigned to fields, such as the values in the Time From Promised, Time To Promised, Date Window Start, Date Window End, Time Window Start, and Time Window End fields to determine how the booking can be moved.
The following sections look more closely at how this scenario works based on different combinations of values that are assigned to different fields.
Date Window Start and Date Window End fields
When the Date Window Start and Date Window End fields contain dates, RSO attempts to reoptimize the booking within that date range. This occurrence indicates to RSO that it should be concerned about scheduling the booking within the dates specified and that the time of day doesn't matter. The booking can be assigned to another resource if it occurs within the defined date range.
For example, if the Date Window Start and Date Window End fields are both set as 11/1/2019, then RSO knows to reoptimize this booking to any resource for any time on 11/1/2019.
Time Window Start and Time Window End fields
When the Time Window Start and Time Window End fields contain times, RSO attempts to reoptimize the booking within that time frame. This situation indicates to RSO that it should be more concerned about scheduling the booking during the time window that is defined. It also indicates that the day that the booking is placed doesn't matter. The booking can be assigned to another resource if it occurs within the defined date range.
For example, if the Time Window Start field is set to 1:00 PM, and the Time Window End field is set to 4:00 PM, then RSO reoptimizes this booking to any resource and place on any day if the booking's estimated start time falls sometime between 1:00 PM and 4:00 PM.
Date Window Start/End and Time Window Start/End fields
In scenarios when the Date Window Start and Date Window End fields and the Time Window Start and Time Window End fields are all defined, RSO reoptimize the booking to occur within both the date and time windows that are specified. Like the previously mentioned scenarios, the booking can be assigned to another resource if it falls within the data and time windows.
For example, assume that the Date Window Start field is set to 10/30/2019, the Date Window End field is set to 11/1/2019, the Time Window Start field is set to 1:00 PM, and the Time Window End field is set to 4:00 PM. In this scenario, RSO can reoptimize this booking to any resource and then schedule it to take place on either October 30, 2019, October 31, 2019, or November 1, 2019. The booking's estimated start time falls somewhere between 1:00 PM and 4:00 PM on whichever day it's assigned to.
Time From Promised and Time To Promised fields
When the Time From Promised and Time To Promised fields have data, it indicates that a specific date and time window was promised to the customer. This indication typically means that the customer has a specific date and time that they want the item to occur on.
For example, if the Time From Promised field is set to 10/31/2019 at 9:00 AM and the Time To Promised field is set to 10/31/2019 at 11:00 AM, then you want RSO to schedule a booking between 9:00 AM and 11:00 AM on October 31, 2019, and it must be within that specific date and specific time range.
Certain scenarios occur when the Time From Promised and Time To Promised fields and the Date Window Start/End and Time Window Start/End fields are defined. Depending on the defined values, this scenario can result in a conflict. In these scenarios, RSO uses the Time From Promised and Time To Promised fields first. Then, it either uses one or a combination of the other fields to schedule the item.
Important
When you are working with time ranges, RSO will ensure that the estimated arrival time falls into the window that was specified previously. It does not guarantee that the booking's end time will fall within the time window.
For more information, see Booking lock option.
Deal with and resolve booking conflicts
Depending on the specific needs of an organization, optimization jobs could run at various points through any given day. Optimization jobs can be set to run hourly or at specific time intervals. Occasionally, optimization jobs are triggered based on events that occur such as a cancellation or an item being created. At the same time, dispatchers, technicians, and other members of the organization might be editing individual bookings or requirements. This situation can result in conflicts. Conflicts arise when a related resource, requirement, or booking is edited during optimization. Members of the organization shouldn't only be able to identify these conflicts, but also resolve them to ensure that everyone can continue to work on items.
The Resource Scheduling Optimization solution lets you understand these conflicts and the options for resolving them. When an optimization request encounters conflicts, the status of the job displays Completed with Conflicts. (In previous versions of the application, the status would show as Failed).
When the Optimization Request is opened, the individual optimization request bookings can be reviewed by selecting Related and then selecting Optimization Request Bookings. From the Optimization Request Bookings view, you can see all the bookings that were in scope. The bookings that resulted in the conflict have a status of Simulation and a conflicted icon. The conflicted booking is treated as a simulation. You can determine if you want to go with the optimized result or continue with the item that was modified manually.
Also, the Operation Details column provides more details around the record such as what specific data was modified during optimization.
To resolve the conflict, you need to let the optimization request know which option to use. This task can be completed by selecting the bookings with a status of Simulation and then choosing either of the following options:
Apply with Overwrite - Commits the simulation booking for the select record(s) as real bookings. Any conflicting bookings are overwritten.
Discard - Removes the simulation booking, favoring the manual booking edits that were made by a dispatcher or field technician.
After each of the conflicted items is resolved by either selecting Apply with Overwrite or Discard, the Optimization Status changes to Completed.
For more information, see Resolving booking conflicts.