Troubleshooting tips
When an organization is first getting started with Resource Scheduling Optimization (RSO), it might not perceive the anticipated desired results when the optimization job was run. The reasons why you might not see the intended results vary, such as items being edited while an optimization job is running, or not finding the appropriate records to optimize.
In most instances, the reasons often amount to configuration issues. The issues could represent improperly configured resources that are resulting in them not being included in a scope or not being available for optimization. Alternatively, the issue could be that requirements and bookings aren't reflecting correct statuses or dates that would ensure that the resources are included in the optimization job.
While each scenario is different, the following sections explain some of the most common issues that you can encounter when starting with RSO.
Cancel a long-running schedule or blocked schedule
If a schedule has been running for a long time and seems to be stuck or blocked, you can use the Reset Resource Scheduling Optimization button to clear the blocked job and reset the schedules into a good state.
Optimization request failed with the message, "System failed to modify some bookings."
This message can be encountered for several reasons. However, you mostly see this message for the following scenarios:
If a booking is being manually updated while an RSO job is running on the same booking, RSO doesn't overwrite the changes and fails the request.
If you have a workflow or plug-in that updates the same bookings during an RSO run, RSO doesn't overwrite the changes that your other system logic made and fails the request.
If you have multiple RSO schedules that share the same resources and run at the same time, RSO might show this message. To better understand the situation and further troubleshoot, consider the following suggestions:
Scroll through the optimization request booking grid and inspect the operation details column for each individual requirement and booking.
Determine if you have multiple schedules that share the same resources, requirements, and bookings that are running at the same time.
If you have only one schedule, check if any other user or workflow is trying to update a booking during the run.
Optimization request failed with the message, "The start time of a time window must be less than or equal to the end time."
This message indicates that some invalid booking data was included in the optimization scope. For example, the user can query a booking entity to see if any booking record has an invalid estimated travel duration.
You can define the following expressions for the view that is being used:
Estimated travel duration > Booking.EndTime - Booking.StartTimeEstimated travel duration > Booking.Duration
Requirement items aren't being scheduled
Reasons vary why requirements might not be booked. First, review the optimization results from the schedule board and corresponding Optimization request > Booking view to look for reasons why they're not being scheduled.
One way that you can quickly validate is to select one of the resource requirements that doesn't schedule and then use the Schedule Assistant to see if it finds results. Even though the Schedule Assistant and the RSO aren't the same, they do evaluate based on similar criteria. If the Schedule Assistant finds results, RSO generally does, too. If the Schedule Assistant can't find any results, it's likely that RSO can't either. However, some scenarios occur where the Schedule Assistant might find results and the RSO won't:
If your resources found as potential matches don't have Optimize Schedule set to Yes (meaning RSO wouldn't consider them)
If your date windows on the requirement are outside of the scope of your RSO run
If your territory for the requirement doesn't match the resources' territory
The following details can help you further analyze the issue:
Scheduling method - Check to see if the requirement's Scheduling Method is set to Optimize. This field is set to Do Not Optimize by default. You either need to set it manually or configure Optimize on work order metadata setup.
Territories - The RSO scope doesn't necessarily depend on territory, but the RSO run still does a territory match between requirement and resource:
If a requirement is assigned to a territory, then the resource must also be assigned to that territory for the requirement to be scheduled.
If a requirement isn't assigned to a territory, then only resources that don't belong to any territory are eligible for that requirement.
Characteristics - Determine whether your requirement requires a characteristic that any of your resources have, and then ask yourself the following questions:
Do those resources have available working hours that are part of the scope of the run?
Based on those resources, are there other jobs that were/should be scheduled first based on the goals of your run?
Restricted resources - Determine if the requirement is excluded from being assigned to a resource because that resource is marked as restricted. This check is only applicable if the Restricted Resources constraint is enabled.
Date/time parameters - Ask yourself the following questions to help determine the issue:
Does your requirement have a From Date and To Date window that falls inside the scope of the optimization run's scope?
Does your requirement have a Time From Promised and Time To Promised window that falls inside of the scope?
Do any of your date fields create an impossible scenario? For example:
Your From Date is after your Time To Promised.
Your To Date is before your Time From Promised.
Capacity - Verify that you have sufficient capacity to pick up all of the work in your scope.
If not, check if there's a valid reason that this requirement wasn't selected based on your goals over other possible requirements.
Determine if you have sufficient capacity based on the required characteristics and resource preferences within the scope of the run (with all other contributing factors).
Geolocation - If the Work Location for the requirement is set to Onsite, the resource requirement needs to have a valid latitude and longitude.
Additionally, check to see if the resource has time to get to and from the job.
Duration - Check to see if the resource requirement has a duration greater than zero (0), and if the fulfilled duration equals zero (0).
Also, verify whether the requirement has a duration that would fit within a resource's shift. RSO doesn't currently support splitting a requirement into multiple bookings.
Status - Verify if the status of the resource requirement is set to Active.
Related bookings - Determine whether the requirement already has a related booking record. If so, confirm whether the related booking record has a related booking status with a Scheduling Method field with a value other than Ignore.
Optimization engine effort level - Larger optimization requests might require more time to optimize. Consider increasing the engine's effort level to give it more time to find a suitable assignment.
Some past bookings are being removed
A booking from the past might be moved if its booking status indicates that it should be optimized and if this booking is included in the optimization scope's booking view. So, it might appear, especially in a testing scenario where no one is actually completing work, that all bookings from the past are rescheduled if no one changed the booking to a booking status that would keep the record from being moved.
A few ways that you can block RSO from moving past bookings include:
Pick a booking status of Do Not Move.
Remove the booking from the booking view.
Lock the booking to a time or time range in the past.
Set a promised date from/to or date from/to while enabling the time window constraint.
Several bookings are in simulation status
If any exception or error happens when an optimization schedule is still running, you might see some overlap on the schedule board. Because some bookings are created or updated from the latest run, while other bookings from the previous run failed to be deleted due to an exception. To avoid this scenario, the optimization process was made automatic and transactional by introducing a Simulation status.
During the optimization process, the create, update, and deleted operations are now visible. All new, updated, and to-be-deleted bookings are in a Simulation staging area. If the whole optimization request is completed and correct, these simulation bookings are flipped into real bookings. Before the optimization request is complete, you can see some simulation status (transparent) bookings move around the schedule board until the run is complete. Then, all simulation bookings are flipped into real bookings (solid blue). If an exception occurs and the optimization request fails, these simulation bookings remain in simulation status for troubleshooting purposes unless you manually delete them. Otherwise, a system job deletes them automatically every two weeks.
You can hide simulation bookings by changing the schedule board settings. Select the gear icon on the top right and select the Hide Canceled option.