Do you still need RSO?

On every D365 Field Service project I have worked on since 2019 there has been a moment, usually in a workshop with management, when someone asks: can the system not just plan this for us? For years my honest answer was yes, partly, if you were willing to pay for Resource Scheduling Optimization, feed it clean data, and accept that once in a while it would do something no planner would defend on the phone with a customer.

That answer is changing. Microsoft is building a Scheduling Operations Agent into Dynamics 365 Field Service, and although it is still in public preview, the direction is hard to miss. This is my read on what the agent does today, what it does not do yet, and what I would change about scheduling architecture because of it.

What the agent actually does, today

As I write this in August 2026, the agent works in two modes. From the schedule board a dispatcher selects up to five resources, the agent proposes a better schedule, and the dispatcher reviews it before anything is applied. For bigger jobs there are optimization plans: batch runs across a defined scope of resources, requirements and bookings, currently up to thirty resources, with goals you can weight. It respects Do Not Move bookings, working hours and breaks, and nothing moves until a person approves it. Microsoft's documentation is explicit that this is a preview: not meant for production, and the limits can shift between release waves.

The interactive mode matters more than it sounds. The biggest enemy of automated scheduling on my projects was never the algorithm; it was trust. An overnight run that silently rearranges two hundred bookings is hard to love at 7:30 in the morning, when the phone is already ringing. A suggestion a dispatcher can see, question and apply personally is a different conversation entirely.

Where that leaves RSO

Let me be precise here, because "RSO is dead" makes a nice LinkedIn headline and is not true. Resource Scheduling Optimization is actively maintained, its documentation was updated this spring, and there is no deprecation notice anywhere. If you need to optimize hundreds of resources overnight across a multi-day horizon, RSO is still the only real answer in the product, and I would not tell anyone running it successfully to rip it out.

But look at the trajectory instead of the snapshot. The agent started with a single resource. It now handles five from the board and thirty through a plan, and the 2026 release wave 1 adds custom goals and custom scopes on top. That is where the product team's energy is visibly going, and it is going there fast.

So my conclusion for new designs is simple: RSO has moved from default to exception. When I architect a new implementation I no longer start from "we will need RSO". I start from a well-configured schedule board plus the agent, and RSO has to earn its place with a concrete scale argument, because it also has to earn its licensing.

The consequence nobody puts on a slide

If the agent keeps growing the way it has, the honest business consequence is that you will need fewer people doing pure planning. I want to say that carefully. I would not put a headcount reduction in a business case today; the feature is in preview, and previews change. But I would absolutely design the operating model for it.

In a rollout I led for a Dutch housing organization, dozens of field professionals, the scheduling team worked with two screens and an Excel sheet. The spreadsheet held everything the board did not know: which technician dislikes high-rise work, which one is quietly brilliant with difficult tenants, who should not be sent to that one address again. And it was good, impressively good, because the team had spent three years refining it and keeping it accurate. That is the detail most people miss. The discipline was never the problem: an organization that keeps a spreadsheet accurate for three years can keep a system accurate too. The effort was simply pointed at the wrong place. Almost everything in that sheet has a home in D365 Field Service. Skills and certifications are characteristics on the resource, with a rating model behind them. Preferred and restricted technicians are resource preferences on the account, and they flow to the work order automatically. Point those same three years of discipline at the system, and the board beats the spreadsheet every day of the week. Agents raise the stakes further, because dispatchers correct suggestions inside the tool instead of around it. The role that remains is exception handling: escalations, emergencies, judgment calls. That is fewer people than solving the whole puzzle by hand, and the planners I know are, frankly, better at the exceptions than at the puzzle anyway.

What I would do on a new implementation

Get the schedule board, booking rules and territories right first; that work keeps its value whatever the optimizer turns out to be. Pilot the agent in a sandbox against a real week of your own bookings rather than demo data, and let your most skeptical dispatcher run that pilot, not your most enthusiastic one. Postpone the RSO decision until someone puts an actual number of resources on the table. And before any of this, fix the data the optimizer reads: skills, certifications, asset information, locations. Every scheduling engine I have watched fail failed on its inputs, not on its math. That failure mode deserves an article of its own, and it will get one.

If you are weighing RSO against the agent on a running project, or architecting scheduling for a new one, this trade-off is my daily work. More about my D365 Field Service practice, or about the integrations that feed a schedule.