DYNAMICS 365 FIELD SERVICE + MULTI-DEPOT OPTIMIZATION
Dynamics 365 Field Service models territory cleanly in Dynamics 365. The Schedule Board renders bookings against bookable resources; Resource Scheduling Optimization fills the board within configured scopes. Service organizations with three or four regional service centers, contractors with branch networks, and agreement-driven service programs across regions need something different: an optimizer that treats all depots as one problem and rebalances work between them under skill, capacity, time-window and SLA constraints, as a single solver input. eLogii owns that decision, custom-integrated against the Dataverse Web API.
Organizational units and territories let you group resources to reflect how your organization is structured by location, division, or service line.
From learn.microsoft.com/dynamics365/field-service/set-up-organizational-units. Dynamics 365 Field Service models the depot and the territory cleanly. Cross-territory rebalancing as a single optimization input is not described as a lead surface for either the Schedule Board or Resource Scheduling Optimization. Verified June 2026.
Microsoft documents the territory model clearly. Organizational units group resources and services by location, division or service line. Territories tie work orders and bookable resources to a geographic catchment. Bookable resources can be associated with specific resource pools and warehouses. The Schedule Board shows the day’s assigned work for a territory or filter set; Resource Scheduling Optimization can be scoped to a territory and date range and will respect travel time, working hours and configured constraints when filling the board.
What neither the Schedule Board nor Resource Scheduling Optimization positions as a lead surface is cross-territory optimization as a first-class input: a single run that takes all depots as inputs, rebalances work orders across them under shared constraints, and outputs assignments that may move work between depots. That decision layer is a different shape of product.
Three concrete patterns make the case for multi-depot as a single optimization input:
In each case, the right answer is decided by the optimizer, not the dispatcher. The dispatcher steers the rules and signs off on the run.
An industrial-services operation running four regional service centers. Eighty engineers in the field. Daily routes for agreement-driven maintenance against customer-asset records; reactive break-fix for SLA-locked equipment; parts pickup between centers when a route needs a part from elsewhere in the network. Dynamics 365 Field Service handles the workflow cleanly: customer asset hierarchy, work orders, agreements with incident types, Field Service Mobile in the engineer’s hands.
The friction sits at the depot interface. Center A runs hot most weeks while center D runs underused; capacity drift accumulates because no one has time to look across centers in real time, and Resource Scheduling Optimization is configured per-territory so it can’t see the imbalance. Routes that should start at center A, pick up at center B, then continue to customers run as two separate trips because the dispatcher can only see one territory view at a time. Drive time creeps. The operations director can see the problem on the Power BI dashboard at end-of-week, but no one is solving it on Tuesday morning. A cross-depot optimization run takes all four centers as one input, drops drive time around 15–20% across the network, and rebalances capacity within roughly +/- 5%. Dynamics 365 Field Service continues to own the work order, the customer asset and the agreement; what changes is which center does which work order.
The workaround is the dispatcher. The dispatcher assigns work to centers based on rules of thumb (closest, characteristic match, current capacity), then the Schedule Board (and Resource Scheduling Optimization within its scope) routes within each center. At small numbers of centers and stable work mix, this is fine. The friction shows up at scale: capacity at one center stays underused while another runs hot; drive time grows because work isn’t reassigned to the center that should actually do it; SLA hits depend on the dispatcher spotting the constraint in time; expanding Resource Scheduling Optimization scope to cover multiple territories at once makes the configuration brittle. The longer the operation runs without a cross-depot optimization step, the more drift accumulates.
Multi-depot is a first-class input. Each depot has a location, opening hours, vehicle pool, characteristic mix, capacity and (where it matters) shift patterns. Bookable resources are associated with home depots but the optimizer can reassign work between depots when constraints allow. A single run produces one consistent plan.
Dynamics 365 Field Service stays in place as the system of record for the work order, customer asset, agreement and inventory. The connector is custom-built against both products’ REST APIs; there is no published eLogii to Dynamics 365 Field Service integration on either side. Power Automate and Azure Logic Apps are common middleware choices.
Most teams complete the connector build in 3 to 5 weeks. Typical first wave: the regional book where cross-depot rebalancing is the dominant planning task, or the service arm running parallel to the contract-maintenance business.
30-minute custom simulation with your actual service centers, bookable resources, vehicles and agreement-driven programs. Projected savings in drive time, capacity utilization and SLA hit rate.
Dynamics 365 Field Service supports multi-territory operations at the workflow level in Dynamics 365: bookable resources can be tied to organizational units and territories, vehicles can be modelled against specific centers, and the Schedule Board shows assigned work on the calendar. Resource Scheduling Optimization can be configured to consider travel time and territory-aware constraints within a defined scope. What neither positions as a lead surface is cross-territory optimization as a first-class input: a single optimization run that considers all depots together, rebalances work orders across depots under skill and capacity constraints, and produces assignments that may move work orders between depots when the math says they should move. That is the decision layer eLogii adds.
Three concrete patterns. First, regional service organizations with three or four service centers: the optimizer needs to decide which center a work order goes to based on characteristic availability, drive time, current capacity and SLA, not just which center is closest. Second, service arms with branch networks: routes start and end at different centers in the same plan, and consolidation across branches drops drive time materially. Third, hub-and-spoke programs where technicians can start from one center, pick up parts from another, then continue to customer sites. None of these are solvable as the sum of single-center optimizations.
The workaround is dispatcher-driven: the dispatcher assigns work to each center based on rules of thumb, then the Schedule Board (and Resource Scheduling Optimization within its scope) routes within each center. At small numbers of centers and stable work mix, this is fine. At more centers, fluctuating work mix, or interacting characteristics and SLAs, the dispatcher has to hold the cross-territory picture in their head. Resource Scheduling Optimization is hard to configure cleanly across multiple territories at once because the scope expands the model and turns brittle. Capacity at one center stays underused while another runs hot. Drive time grows because work isn’t reassigned to the center that should actually do it. The longer the operation runs, the more this drift accumulates.
Multi-depot is a first-class input to the optimizer. Each depot has a location, opening hours, vehicle pool, characteristic mix and capacity. Bookable resources are associated with home depots but the optimizer can reassign work between depots when constraints allow. A single optimization run produces routes that may start at one depot, end at another, or pick up at a third. The output is one consistent plan, not the sum of per-depot plans. Both the Default engine and the Advanced engine handle multi-depot inputs.
Custom integration against the Dataverse Web API (OData v4) and eLogii’s REST API. eLogii reads work orders, requirement groups, bookable resources, vehicles, territories and characteristics from Dynamics 365. The optimization run treats all depots as a single problem. Bookings and ETAs are written back to Dynamics 365, mapped to the appropriate depots and resources; Field Service Mobile picks up the assignments unchanged. Completion data flows back to Dynamics 365 Field Service for the work-order record, customer asset history, inventory and reporting. Typical connector build: 3 to 5 weeks.
Last updated: June 2026. Dynamics 365 Field Service scope is drawn from Microsoft Learn: Dynamics 365 Field Service overview, organizational units and territories and Resource Scheduling Optimization overview. eLogii capabilities documented at elogiiapidocs.apidog.io.
Custom simulation
A 30-minute working session with our solutions team. We take a sample of your real jobs, depots, vehicles and SLAs, run them through the eLogii engine, and show you the projected delta against how you plan today. No slides, no generic benchmarks.
