DYNAMICS 365 FIELD SERVICE + MULTI-DEPOT OPTIMIZATION
Salesforce Field Service models territory cleanly in Salesforce. The Dispatcher Console renders bookings against service resources; Enhanced Scheduling and Optimization fills the board within configured scopes. Service organizations with three or four regional service centers, contractors with branch networks, and Maintenance Plan 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 Salesforce Platform REST API.
Service Territories dictate how Service Resources are viewed within the Dispatcher Console, scheduling processes, dispatching processes, optimization processes, and more.
From help.salesforce.com/sf.fs_territory_guidelines. Salesforce Field Service models the territory cleanly via the Service Territory and Service Territory Member objects. Cross-territory rebalancing as a single optimization input is not described as a lead surface for either the Dispatcher Console or Enhanced Scheduling and Optimization. Verified June 2026.
Salesforce documents the territory model clearly. Organizational units group resources and services by location, division or service line. Territories tie work orders and service resources to a geographic catchment. Bookable resources can be associated with specific resource pools and warehouses. The Dispatcher Console shows the day’s assigned work for a territory or filter set; Enhanced Scheduling and 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 Dispatcher Console nor Enhanced Scheduling and 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 Maintenance Plan 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. Salesforce Field Service handles the workflow cleanly: customer asset hierarchy, work orders, Maintenance Plans with incident types, Salesforce Field Service mobile app 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 Enhanced Scheduling and 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 CRM Analytics 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%. Salesforce Field Service continues to own the work order, the customer asset and the Maintenance Plan; 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, skill match, current capacity), then the Dispatcher Console (and Enhanced Scheduling and 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 Enhanced Scheduling and 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, skill 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.
Salesforce Field Service stays in place as the system of record for the work order, customer asset, Maintenance Plan and inventory. The connector is custom-built against both products’ REST APIs; there is no published eLogii to Salesforce Field Service integration on either side. Salesforce Flow and MuleSoft 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, service resources, vehicles and Maintenance Plan programs. Projected savings in drive time, capacity utilization and SLA hit rate.
Salesforce Field Service supports multi-territory operations at the workflow level in Salesforce: service resources can be tied to Service Territories via Service Territory Members, vehicles can be modelled against specific centers, and the Dispatcher Console shows assigned work on the calendar. Enhanced Scheduling and 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 skill 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 Dispatcher Console (and Enhanced Scheduling and 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 skills and SLAs, the dispatcher has to hold the cross-territory picture in their head. Enhanced Scheduling and 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, skill 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 Salesforce Platform REST API and eLogii’s REST API. eLogii reads work orders, service crews, service resources, vehicles, territories and skills from Salesforce. The optimization run treats all depots as a single problem. Bookings and ETAs are written back to Salesforce, mapped to the appropriate depots and resources; The Salesforce Field Service mobile app picks up the assignments unchanged. Completion data flows back to Salesforce Field Service for the work-order record, customer asset history, inventory and reporting. Typical connector build: 3 to 5 weeks.
Last updated: June 2026. Salesforce Field Service scope is drawn from Salesforce Help: Salesforce Field Service overview, Guidelines for creating Service Territories and Enhanced Scheduling and 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.
