You are here:
Resource Schedule Optimization for Workforce Scheduling
In Workforce Scheduling, use Resource Schedule Optimization (RSO) to reoptimize a single service resource’s schedule when a last-minute disruption occurs. RSO reshapes a single resource’s day due to a shift change, a cancellation, or an unexpected block of unavailability — without affecting the rest of the team. RSO is relevant to field work only.
Required Editions
| Available in: Lightning Experience |
| Available in: Enterprise and Unlimited Editions |
Changes to a service resource’s schedule during the day can leave gaps or overlaps in the schedule. RSO is a tactical tool primarily targeted at intraday adjustments. It automatically fixes a resource’s schedule and fills gaps with other work based on two hidden, fundamental objectives:
- Utilization
- The engine prioritizes scheduling as many appointments as possible.
- Appointment Priority
- When capacity is limited, high-priority appointments take precedence over lower-priority work. RSO reads priority from the Scheduling Priority field on the Service Appointment record. See How Workforce Scheduling Optimization Works.
Dispatchers trigger RSO from the Operations Console action menu of the resource whose schedule they want to optimize. Because the RSO run is scoped to one resource and one day, it usually completes in seconds.
RSO respects the resource’s working hours, required skills, and any pinned appointments. Pin criteria configured in your Workforce Scheduling settings, keep appointments on protected statuses from moving. Org-wide RSO behavior is controlled through two settings in Setup:
- Pin Criteria
- The Pin Criteria setting defines which statuses pin service appointments during optimization. Setting Pin Criteria excludes service appointments in those statuses from being changed (scheduled, unscheduled, or rescheduled) during RSO. Scheduled service appointments in a pinned status can’t move to a different service resource or to a different time. Unscheduled service appointments in a pinned status remain unscheduled. Deselect the Dispatched status so dispatched work can move if a previous job runs late or emergency work comes up.
- Commit Mode
- Commit Mode (default: Rollback) determines what happens when a scheduling change is made while an optimization run is in progress.
To configure these org-level settings, see Configure Optimization for Field Work in Workforce Scheduling.
When to Use Resource Schedule Optimization
RSO is the smallest-scope optimization type. It’s best when:
- One resource’s day is disrupted but the rest of the schedule is stable.
- You want a fast reoptimization scoped to a single person and a single day.
- You don’t want the optimizer to move any appointments that belong to other resources.
- You need to handle changes like cancellations, fixing overlaps and filling gaps.
For same-day disruptions that span multiple resources or territories, use In-Day Optimization. For end-of-day rebalancing across the whole plan, use Global Optimization.
RSO fails if more than 50 appointments must remain scheduled during the run. That includes appointments protected by pin criteria and appointments already in progress. When you hit this limit:
- Split the day into shorter time horizons and run each separately.
- Move a subset of appointments to an unscheduled state and rerun.
- Confirm your pin criteria aren’t broader than necessary — narrower pin criteria let more appointments move.
Handling Complex Resource Schedule Optimization Scenarios
- 24/7 Shifts
- 24/7 shifts have no extended horizon of about 7 days. You can only optimize the horizon of the request — optimization can’t pull work forward from the future. If an appointment is part of a shift that crosses beyond your horizon (for example, it spans past midnight), the engine treats the entire appointment as unmovable. To fix this, set your optimization horizon to cover the entire shift.
- Max Runtime
- RSO’s default runtime is 60-seconds. This only covers the optimization engine runtime and doesn’t include data fetching or committing results to the Gantt. For example, if a dispatcher sees the Gantt as disabled for 2 minutes during an RSO run, the system hasn’t crashed. The data loading and saving happens on either side of the 60-second calculation window.
- Data Volume
- For the best optimization quality, use the filtering criteria to limit the volume of loaded data (candidate pool) to approximately 1,000 service appointments per run. The engine begins by selecting a random service appointment as a starting point, and then schedules others that are close to it. With very large data sets (for example, 4,000 service appointments), the engine can settle on a schedule before it fully explores the candidates or uses the available runtime, producing a suboptimal result. To stay within this range, narrow your candidates by using the Consider only these appointments as candidates filter, by refining the work rules in your scheduling policy, or by shortening your optimization horizon.
