What it does

Resource Scheduling Optimization (RSO) is a paid add-in that bulk-schedules requirements to resources and sequences their day to cut travel. It runs as a separate application installed into the environment, reads Universal Resource Scheduling data, and writes bookings back. Getting it installed is a distinct project step from getting it to produce sensible schedules.

Key facts

• RSO is licensed as an add-in and priced on the number of resources whose schedules are optimised, not on users. It is available in most regions where Field Service is sold.
• Deployment is done from the Power Platform admin centre under Manage > Dynamics 365 apps: find Resource Scheduling Optimization, install into the target environment, accept the terms. Installation can take up to an hour, and the subscription can take several hours to appear in the admin centre after it shows in Microsoft 365 admin.
• Field Service must already be installed, and maps must be configured for the environment before RSO will do anything useful.
• Security is split. The RSO application user needs the Field Service - Administrator role and the Resource Scheduling Optimization – Administrator column security profile. Dispatchers need adding to the Resource Scheduling Optimization - Dispatcher column security profile.
• Turn it on at Resource Scheduling Optimization > Administration > Scheduling Parameters > Resource Scheduling Optimization tab: set Enable Resource Scheduling Optimization to Yes and pick a Default Goal. A default goal is created at deployment.
• Resources only participate if Optimize Schedule is Yes on the bookable resource, and they need an address — their own or their organisational unit's. Setting the flag doesn't schedule anything by itself.
• Requirements only participate if their Scheduling Method is Optimize. Set Default Scheduling Method to Optimize in Booking Setup Metadata for the entity so new records inherit it.
• Every booking status maps to a scheduling method: Optimize (RSO may move it freely), Do Not Move (keeps the resource, may shift time if a location changes), or Ignore (RSO disregards it entirely — used for proposed and cancelled). A status with nothing set behaves as Do Not Move.
• Two daily system jobs delete optimisation request records and simulation bookings older than two weeks. They exist to stop the tables growing without bound.
• RSO sends schedule configuration and work order details, including addresses, to the mapping service for geolocation and travel time.

When to use / skip

RSO is worth it when the schedule is genuinely a routing problem: dozens of technicians, hundreds of jobs a day, travel that's a material cost, and a dispatch team that spends its morning shuffling bookings rather than handling exceptions. Below roughly that scale, the schedule assistant plus disciplined territories gets you most of the benefit for none of the licence cost or configuration effort. Be blunt with clients who want RSO because it sounds like the mature option: if their data is thin — no reliable durations, missing skills, half the addresses ungeocoded — RSO will produce confidently wrong schedules faster than a human can produce right ones. Fix the data first, run manual for a quarter, then buy the add-in.

Configuration decisions

• Which resources are in scope for optimisation, and therefore what you're paying for. This is a commercial decision as much as a technical one.
• Booking status to scheduling-method mapping across the whole status model, including any custom statuses. Get this wrong and RSO either shreds committed work or refuses to move anything.
• Whether Optimize becomes the default scheduling method for new requirements, or whether dispatchers opt jobs in.
• The partitioning strategy — by territory, by shift, by work type — because that shapes scopes, schedules and how you'll troubleshoot.
• Where the resource day starts and ends: personal address, organisational unit address, or a depot, and whether return travel counts.
• How much of the day RSO owns versus the dispatch team. A common landing point is overnight optimisation of tomorrow, with humans owning today.

Gotchas

• Custom booking statuses added after RSO configuration default to Do Not Move. Jobs quietly stop being optimised and nobody connects the two.
• Resources without a valid geocoded address are skipped. The optimisation request record tells you why a resource was excluded, but only if someone reads it.
• Requirements outside the scope's time range are neither created nor updated — an empty result is far more often a scope range problem than an engine problem.
• The retention jobs delete request records after two weeks, so post-incident analysis has a fortnight's window. Export what you need before it goes.
• Modifying or disabling those retention jobs to keep history leads to table bloat and degraded performance later.
• Licence counting is by optimised resource, so leaving Optimize Schedule set to Yes on leavers and test resources has a cost.

Consultant notes

• Install RSO into a sandbox first and run it against a copy of production data. The first honest read on whether RSO helps this client comes from comparing its output to what dispatchers actually did that week.
• Start with a very light engine effort level and few constraints. Fast, slightly worse answers build confidence; slow runs that time out build none.
• Tell the client plainly that RSO does not replace dispatchers. It replaces the first two hours of their day and turns them into exception handlers, which is a change-management conversation, not a technical one.
• Check the application user's roles and column security profiles after every environment refresh — this is the single most common cause of "RSO stopped working".
• Agree a rollback: which booking statuses lock work, who can pin a job, and how the team runs a day if optimisation fails overnight.

---

Worth another look if the add-in's licensing model changes, or after any environment copy or refresh.