Licensing the Resource Scheduling Optimization add-on

What it does

Resource Scheduling Optimization is a separately paid add-on that runs bulk optimisation over bookings and requirements on top of Universal Resource Scheduling. It is not part of the Field Service licence, and it is not priced per dispatcher — it's priced by how many resources you optimise.

Key facts

A Field Service licence is a prerequisite. If the client already has a bundle that includes Field Service, they don't buy it again; if not, Field Service comes first and RSO afterwards.
The add-on is bought in the Microsoft 365 admin center under Marketplace, as "Resource Scheduling Optimization add-on for Dynamics 365 Field Service". Learn points at the pricing page rather than stating a rate.
Pricing is based on the number of resources whose schedules are optimised. That is the only meter Learn commits to — everything else about the commercial shape is in the licensing guide.
Optimisation runs themselves are unlimited: scheduled cadence and ad hoc runs are both covered by the same entitlement, so there is no reason to ration executions.
One active instance of RSO per tenant. Multi-environment programmes need to plan around that rather than assuming dev, test and production each get their own.
Installation is from the Power Platform admin centre, under Manage > Products - Dynamics 365 apps, selecting Install on Resource Scheduling Optimization. Field Service must already be in the target environment. Install can take up to an hour and the subscription itself can take several hours to appear.
The billable population maps directly to a field: Bookable Resource > Resource Scheduling Optimization tab > Optimize Schedule. Set to Yes, the resource is in scope for optimisation runs.
Work is opted in separately. Resource Requirement > Scheduling Method = Optimize puts a requirement in scope; Booking Setup Metadata > Default Scheduling Method applies it to new records for an entity; Booking Status > Scheduling Method chooses Optimize, Do Not Move or Ignore per status.
The master switch is Scheduling Parameters > Resource Scheduling Optimization tab > Enable Resource Scheduling Optimization.
RSO is GA in most regions where Field Service is sold. It sends address data to Bing Maps to geocode and to work out travel time and distance, and an administrator can turn RSO off to stop that.
Two built-in daily jobs purge RSO requests and simulation bookings older than two weeks, so the optimisation history is not a long-term audit trail.

When to use / skip

RSO earns its place when the schedule is too large or too constrained for a dispatcher to do well by hand — hundreds of bookings a day, tight travel geography, overnight rescheduling, or a genuine cost of poor utilisation that the client can put a number on. Long-cycle, low-volume work with a dispatcher who knows every engineer by name will not repay the licence or the configuration effort.

Most Field Service projects do not need it at go-live and should not buy it at go-live. The schedule assistant and the schedule board handle manual and semi-automated scheduling perfectly well, and you need several months of real bookings, real travel times and real working-hours data before optimisation produces schedules anyone trusts. Buying RSO in phase one usually means paying for a year of an add-on that gets switched on in month fourteen.

Where it does go in, treat it as a second project with its own discovery, not a checkbox at the end of the first one.

Configuration decisions

Which resources actually get Optimize Schedule = Yes. This is a commercial decision as much as a functional one, because it is the meter.
Whether requirements default to Optimize via Booking Setup Metadata, or whether dispatchers opt work in case by case. Defaulting everything to Optimize is the fastest way to lose dispatcher trust.
Which booking statuses are Optimize, Do Not Move or Ignore — in particular, whether anything a technician has already travelled to is protected.
The optimisation scope, goal and schedule: what window is re-optimised, what the run is trying to minimise, and how often it fires overnight versus intraday.
Whether you run simulations before committing, and who reviews the results.
Which environment holds the single RSO instance, and how you plan to test changes without one.

Gotchas

One RSO instance per tenant is the constraint people find late. If you need to prove a configuration change before it hits production, work out that story during design, not during UAT.
The per-resource meter is set by a field on Bookable Resource. Bulk data loads and eager admins flipping Optimize Schedule to Yes across the whole resource table is a billing event, not just a config change.
Purchasing and installing are separate steps in separate portals, and the subscription can lag hours behind the purchase. Don't book an install day the morning after the PO.
Requirements that were created before Booking Setup Metadata defaults changed keep their old Scheduling Method. Retrofit them deliberately or the first optimisation run covers less work than expected.
RSO geocodes addresses through Bing Maps. On projects with data residency sensitivities, that needs raising early rather than being discovered in a security review.
Optimisation requests and simulation bookings are purged after two weeks, so "why did it schedule that job there in March" is not a question anyone can answer in May.

Consultant notes

Push back on buying RSO in the initial licence order. Get the client's own utilisation and travel-time baseline out of the first few months of live data, then make the case with numbers.
Demo a simulation, not a live optimisation run. Dispatchers accept optimisation far more readily when they've seen a proposed schedule they can compare against their own.
Tell the client the meter is resources optimised, and that it's controlled by a field their admins can change. Put a control around that field.
Before go-live on RSO, check working hours, time-off, territories, travel-time settings and resource start/end locations are all real. Optimisation exposes bad reference data mercilessly.

Worth revisiting if Microsoft changes the resource-based pricing model, or lifts the one-instance-per-tenant limit.