Optimization goals

A goal is what the resource scheduling optimization (RSO) solution aims to optimize. An example of a goal is to maximize working hours or minimize travel time. You define how bookings should be optimized (constraints and objectives). The RSO engine processes a list of resources and a list of resource requirements, along with existing bookings, to create the optimal route or list of bookings for the resources. Bookings are considered optimally scheduled if they:

  • Meet all company constraints.
  • Have the highest possible score for the company’s objectives.

Default optimization goal

When RSO is deployed for the first time, the system automatically creates a default goal with some constraints and objectives enabled. Users can modify as needed or create a new optimization goal and associate it as a default goal.

Screenshot of default goal in scheduling parameters

Engine Effort Level determines how much effort RSO makes finding the best combination of resources, route, and day or time. The higher the effort, the longer RSO takes to complete the execution. For example, the effort might be very light, light, moderate, intense, or very intense. The higher the intensity, the more iterations of possible combinations the RSO engine considers.

Screenshot of default goal deployed with RSO

The default goal is used when single resource optimization is selected from the schedule board.

Screenshot of default goal deployed with RSO

Define constraints

Schedule Within Working Hours

This creates the booking if it can be completed within the resource’s working hours. Verifies the booking is not scheduled out of the resource’s working hours. This includes travel time from the last booking to the resource’s end location, although it’s not visually displayed on the schedule board.

Screenshot of a booked resource

What happens if I remove the Schedule within working hours constraint?

Meets Required Characteristics

This verifies the resource has all the required characteristics and should have minimum required skill level.

Meets Required Roles

As of RSO v3.0.19263.1+, RSO will respect the resource roles added to a requirement. If for example, the requirement calls for a resource with the role "Robotics Engineer", RSO will schedule to a resource who has that role. If the requirement calls for two resource roles, RSO will schedule the requirement to resources that have either of those roles, following "OR" logic.

Scheduling Lock Option

If marked, RSO will respect lock options configured on a bookable resource booking record.

  • Time Range
  • Resource
  • Time
  • Resource + Time

Screenshot of a booked resource

Scheduling Windows

If marked, RSO will schedule work to comply within the time window start and end fields on the resource requirement or booking record.

  • If From Date and To Date on resource requirement or Date Window Start and Date Window End on resource booking are set as shown in the following example, it indicates you want RSO to schedule the booking on 5/24/2018 and time of day doesn’t matter.

Screenshot of the date selectors

  • If Time Window Start and Time Window End are set as shown in the following example, it indicates you want RSO to schedule a booking from 2:00 AM to 6:00 AM and the date doesn’t matter.

Screenshot of the time window start and time window end fields

  • If Time From Promised and Time To Promised are set as shown in the following example, it indicates you want RSO to schedule a booking between 4:00 AM and 8:00 AM on 5/24/2018. It has to be a specific date and specific time range.

Screenshot of the time from promised and time to promised fields


  • If these fields are conflicting, RSO uses Time From Promised and Time To Promised first. Then it will use one or a combination of other fields.
  • RSO will ensure the Estimated Arrival Time falls into the window specified above. It does not guarantee that the booking’s end time will fall within the time window.
  • Empty time values (v3.0+) RSO will respect scenarios when only a start or end time is defined on a requirement.

In the following example, a requirement has only a time window start value; RSO schedules the requirement anytime after 1:00 PM regardless of date.

Screenshot of requirement group with two requirements

This logic applies to the following fields.

On the resource requirement entity: - Time Window Start and Time Window End - Time From Promised and Time To Promised - From Date and To Date

On the resource booking entity: - Time Window Start and Time Window End - Time From Promised and Time To Promised - From Date and To Date

Meets Resource Preferences

Formerly called "Restricted Resources" constraint, the constraint was expanded to include all resource preferences on requirements as of RSO v3.0.19263.1.

If marked, RSO will respect the three different types of resource preferences on a requirement:

  • Preferred - RSO will give scheduling preference to the resource if the resource is available but will not guarantee as RSO may need to balance overall objectives such as minimizing travel time.
  • Restricted - RSO will not schedule to resources who are added to requirements with this resource preference
  • Must choose from - RSO will schedule to this resource given the resource is available during the time range of RSO. You can add multiple resources with a "Must choose from" preference and RSO will schedule to one of them; the first that is available.

Matches Territories

If marked, RSO will respect the Territory field value on the requirement. As a reminder, a requirement can only belong to one territory, but resources can belong to multiple.

Matches Resource Type

As of RSO v2.8+, RSO will match the resource type between requirements and resources to decide which type of resource can fulfill a requirement.

Bookable resources include these types:

  • Generic *
  • Users *
  • Contacts *
  • Accounts *
  • Equipment *
  • Facility *
  • Crew
  • Pool

* Indicates resource types the optimization will consider

In general, resource types define how the resource relates to the organization. For example, resources with the resource type Users are typically employees, whereas the resource type Contacts or Accounts are typically contractors.

Additionally, requirements allow multi-select so you can specify which resource types you need for a given requirement.

Screenshot of multi-select resource type attribute on requirement

Define objectives

Add and rank the objectives of RSO scheduling by using the Move Up and Move Down buttons, as seen in the following screenshot.

Screenshot of requirement group with two requirements

Maximize total working hours: The combination of the engine results

Iteration with the total highest aggregate work time will best meet this objective.

Minimize total travel time: The version of the engine results

Iteration with the total lowest aggregate travel time will best meet this objective.


This cannot be the first objective in the list. RSO might not schedule anything with the travel time as 0 minutes in order to meet the first objective.

Locked bookings

Once a booking is created, a lock can be set on the scheduling lock options field in the RSO section of the booking. The options are Time Range, Resource, Time, and Resource and Time. When the locked bookings objective is selected, RSO will try to include locked bookings into the optimal route. For example, the following screenshot shows that Norbert has a booking that starts at 2:30 AM, and this booking is locked toTime. When RSO runs, the system detects a 30-minute idle time for Norbert in the morning, but none of the other requirement durations fit into that slot with the locked booking next to it, even though RSO tries to move it to other resources’ time.

Screenshot of the schedule board

If locked booking is a high-ranking objective, RSO will keep the locked booking there with 30 minutes of idle time before it by sacrificing the other objectives. The following screenshot shows the result.

Screenshot of the schedule board

If locked booking is not a selected objective or is ranked lower in the order of importance for objectives, RSO might ignore this locked booking (exclude this locked booking from the optimal route) and schedule other bookings for Matthew at 2:30 AM in order to achieve the highest score for top-ranking objectives, with the result shown in the following screenshot. It looks as if a booking overlaps, but actually the locked booking was ignored in this case. RSO would not delete the locked booking because it would lose the lock information defined on the booking record, which can’t be retrieved from the backing requirement.

Screenshot of the schedule board optimization

High priority requirements

RSO will evaluate this objective and give priority to the resource/booking combination with the highest score for priority. The priority is set on the resource requirement record and is an option set with weighted values. RSO checks Level of Importance on priority to determine how important that priority is—for example, set Level of Importance = 10 for urgent priority and set Level of Importance = 1 for low priority and RSO will score 1 urgent requirement the same as 10 low-priority requirements because both scores are 10.

Maximize Preferred Resources (v3.0+):

RSO will consider the list of preferred resources noted on related requirements. The optimizer will try to assign bookings to preferred resources first while meeting other constraints and objectives.

This is achieved by adding the "Maximize Preferred Resources" objective to your RSO goal and adding a preferred resource(s) on the requirement that will be optimized.

Screenshot of maximize preferred resource objective in a goal

The following screenshot shows an example of adding a resource to a requirement (for example: Jorge Gault) as a preferred resource.

Screenshot of requirement with preferred resource

After running an optimization schedule, the requirement is scheduled to the preferred resource. In the following example, work order 00100 is scheduled to Jorge Gault.

Screenshot of requirement group with two requirements


The Maximize Preferred Resources objective only applies to preferred resources.

Best Matching Skill Level (v3.0+)

RSO will consider the proficiency rating when matching characteristics required by requirements and the resources who possess those characteristics. This is dependent on the Meets Required Characteristic constraint within the optimization goal.

If the "Meets Required Characteristics" constraint is checked:

  • Resources without the characteristic (skill) or lower-than-required proficiency ratings are not eligible at all
  • Resources with the exact skill level (best matching) get the highest score
  • The more overqualified a resource is, the lower score their score will be

If the "Meets Required Characteristics" constraint is unchecked:

  • Less qualified resources and resources without the skill can still be booked
  • Overqualified resources get a higher score than less qualified resources
  • The more overqualified a resource is, the lower their score will be
  • The less qualified a resource is, the lower their score will be
  • Resources without the skill get the lowest score

For example, if a characteristic (skill) rating model ranges from 1 to 10, and the requirement asks for a skill level of 4, the following example shows the score distribution based on skill level of the resource.

Screenshot of requirement group with two requirements

Screenshot of requirement group with two requirements


In the 2020 release wave 2 update, the Best matching skill level objective was enhanced to prioritize assigning jobs to resources with fewer skills first. This is valuable for organizations that have a workforce with varying skillsets. Assigning jobs to resources with fewer skills or more common skills first when there is more capacity than demand allows RSO to reserve capacity for resources with multiple and unique skills for higher priority emergency situations. For example, imagine one resource has installation skills and another resource has installation and repair skills. RSO will initially schedule installation jobs to the first resource who only has installation skills. This is advantageous because if a repair job needs to be scheduled later, the second resource will have capacity; if all the installation jobs were scheduled to the second resource, then no one would be available for the repair job since the first resource does not have the skills for repairs. This improvement to the Best Matching Skill level objective requires no additional configuration and is an update to the background algorithm.

Schedule as soon as possible

Occasionally, there may be more resource capacity than there is demand for resources (for example, total time of work orders is less than total available time of resources). In these circumstances, there is a business decision about whether to fully book some resources or leave resources with some capacity as a contingency for emergency or unplanned work.

In order to effectively front load optimized bookings, add the Schedule As Soon As Possible objective into your Optimization Goal in the corresponding order:

Screenshot of schedule as soon as possible constraint in correct order