Enhanced Scheduling and Optimization limits: adding a constraint-based engine alongside the Dispatcher Console

What Salesforce documents about scheduling in Salesforce Field Service

Salesforce positions the product around the work order and the service resource. The scheduling vocabulary spans two surfaces:

• Dispatcher Console. The dispatcher cockpit. Drag-and-drop and assisted scheduling against service resources, requirement panels for unscheduled work, map and Gantt views, resource utilization indicators, multi-tab support for different views of the same day.
• Enhanced Scheduling and Optimization (ESO). A licensed AI add-on. Runs scheduling against a configured scope (a set of service resources and a date range) with goals (such as travel time minimization, resource utilization or SLA optimization) and constraints expressed inside the Salesforce model. Fills the board automatically within the scope.
• Auto-schedule. A one-click action on a Service Appointment that finds the best available slot based on the active scheduling policy. Used inline by the dispatcher.
• Service Crew. A group of Service Resources with complementary skills, assigned to an appointment as a unit for multi-resource jobs.
• Salesforce Scheduler. The platform-wide appointment-booking layer, shared across Sales Cloud, Service Cloud and Field Service for outbound and customer-initiated bookings.

What neither the Dispatcher Console nor Enhanced Scheduling and Optimization positions as the lead capability is a constraint-based optimization engine across the full operational problem: an input model that spans every work order, every service resource, every vehicle, every depot, every skill, every time window, every SLA and every recurring cadence in one solver run, with a documented optimization API and operator-visible assignment and load-balancing modes. That decision layer is what eLogii adds, callable over REST.

Where the Dispatcher Console and Enhanced Scheduling and Optimization reach their boundary

The pattern is consistent across operations where this comes up:

• Dispatcher-as-optimizer. The dispatcher spends the morning hand-balancing work orders across resources, territories and skills. The Dispatcher Console makes the placement easy to see; Enhanced Scheduling and Optimization runs on a narrow scope because the full problem is too brittle to configure; the placement itself is the bottleneck.
• Multi-depot rebalancing. A service organization with three or four regional service centers needs the optimizer to treat all depots as part of the same problem. Salesforce Field Service models territory; cross-territory rebalancing as a single optimization input is operator work.
• Maintenance Plan recurring service at scale. Quarterly preventive against contracted SLA terms, monthly inspections across a customer-asset base. Salesforce Field Service generates the work orders from Maintenance Plans; optimization across the generated stops, interacting with reactive break-fix, is its own problem.
• Constraint-heavy commercial service. A two-technician install over three days with a customer-confirmed start window, an asset-specific skill that needs the same technician back on day three, an overnight stop. The constraints are real and there are usually hundreds of work orders to satisfy them across.
• SLA-locked work mixed with flexible. The optimizer needs to protect the SLA-locked bookings, balance the flexible ones, and re-optimize on the fly when a no-access comes in.

At a glance: a 60-engineer commercial HVAC service organization

A commercial HVAC service organization running compliance and break-fix across three regional service centers. Sixty engineers in the field. Two dispatchers. The book splits roughly 50% Maintenance Plan preventive (quarterly compliance against contracted SLA terms) and 50% reactive break-fix on regulated equipment with SLA terms. Salesforce Field Service covers the workflow cleanly: customer asset hierarchy with sub-component visibility, Maintenance Plan and entitlement validation against the work order, Salesforce Field Service mobile app in the engineer’s hands, inventory tied into the service supply chain, Experience Cloud for customer self-service.

The bottleneck shows up in the morning. Two dispatchers spend an hour hand-balancing reactive against preventive, reconciling yesterday’s slots against today’s actual routes, and working around the engineer off sick at center 2 by manual moves across centers 1 and 3. Enhanced Scheduling and Optimization runs on a narrow scope (one territory, one day) because expanding it across three depots and a mix of Maintenance Plan and reactive work makes the configuration brittle. Salesforce Field Service tracks the work order, the customer asset, the Maintenance Plan and the inventory cleanly; the cross-depot, cross-day routing decision is dispatcher-led. Adding eLogii compresses that morning hour into a 10-minute review of a constraint-aware optimization run; Salesforce Field Service continues to own the work order, customer asset, Maintenance Plan and inventory.

The workaround in Salesforce Field Service and where it breaks

The workaround is the dispatcher, with Enhanced Scheduling and Optimization in a supporting role. The Dispatcher Console is good at what it’s built for and an experienced dispatcher can carry a real operation on top of it. ESO works well when its scope, goals and constraints match the operational shape of a single territory or a stable program. The friction shows up at scale: time spent on planning grows non-linearly with the number of resources and depots; the bus-factor of the operation is the one dispatcher who knows the territory; cross-day and cross-depot constraints get carried in heads and spreadsheets, not in the model; expanding ESO scope to cover the full problem turns brittle (the optimizer either over-constrains and finds no solution, or under-constrains and produces a plan the dispatcher has to redo). When the dispatcher takes leave, planning quality drops visibly. When the operation grows past the dispatcher’s capacity, the team adds dispatchers, then more dispatchers, and the coordination tax climbs.

None of this means Salesforce Field Service is the wrong tool. It means there is a constraint-based optimization decision layer the dispatcher today (and ESO partially) is the proxy for, and eLogii owns that layer.

How eLogii’s optimization engine handles this

eLogii’s engine takes a constraint model as input and produces both assignments and routes as output. The dispatcher steers it with rules they can see; the technician executes the plan in Salesforce Field Service mobile app.

• Two engines. The Default engine optimizes 100 tasks in under 10 seconds for high-throughput daily planning. The Advanced engine takes more factors into account and is the choice for multi-depot, multi-day, long-haul and constraint-heavy operations.
• Three assignment modes. Optimize Everything (creates fresh routes including all assignments), Add to Routes, Keep Existing Assignments (incorporates new work orders while preserving resource assignments), and Add to Routes, Keep Existing Assignments and ETAs (inserts new work orders into available slots without modifying existing stop sequences or ETAs).
• Three load-balancing modes. Most Efficient Routes (fewest vehicles), Balance the Minimum Number of Routes (across load, time, distance or work-order count), and Use All Vehicles / Finish as Soon as Possible (maximize speed).
• REST-callable. All six modes are programmatic. Dispatchers can lock specific routes, manually reorder stops, or re-run with new constraints. The optimizer is not a black box.
• Rule-based re-optimization. Re-route a no-access visit to the nearest engineer with the right skill, without moving any customer-confirmed bookings in the next 90 minutes. Visible to the dispatcher.

How the integration sits with Salesforce Field Service

Salesforce Field Service stays in place as the system of record for the work order, customer asset, Maintenance Plan and inventory. The connector between the two products is custom-built; there is no published eLogii to Salesforce Field Service integration on either side. Salesforce exposes the Salesforce Platform REST API for every Field Service table, with Salesforce Flow, Platform Events and the Pub/Sub API for downstream subscribers. eLogii’s REST API has 70+ endpoints including the optimization endpoints. The flow:

1. Read from Salesforce. eLogii reads work orders, service crews, service resources, vehicles, territories, skills and Maintenance Plans and Maintenance Work Rules from the Salesforce Platform REST API. Maintenance Plan preventive work flows in alongside the daily work-order queue.
2. Optimize in eLogii. The run produces routes with assignments, start times, end times, overnight stops, depot start/end, SLA respect and recurring-cadence respect. Dispatcher reviews in eLogii’s dispatch desk or accepts an Auto run.
3. Write back to Salesforce. Bookings and ETAs are written back to the Salesforce work-order and booking model. Completion data flows back to Salesforce Field Service for the work-order record, customer asset history, inventory and reporting.
4. Technician experience unchanged. The technician opens the Salesforce Field Service mobile app on site. The routing they follow is the one eLogii planned.

Most teams complete the connector build in 3 to 5 weeks. Typical first wave: the multi-depot regional book, a large Maintenance Plan program, or the business unit where the dispatch surface is leaking the most.

Frequently asked questions

Does Salesforce Field Service have an optimization engine?

Yes. The Dispatcher Console is the dispatcher cockpit on top of Salesforce, and Enhanced Scheduling and Optimization (ESO) is the licensed AI add-on that runs against configured scopes, goals and constraints to fill the board. Both are valid for the Salesforce work-order model. What neither positions as the lead surface is constraint-based optimization across multi-day, multi-depot operations in one solver run, operator-visible rule-based re-optimization, or a public REST surface for the optimizer itself with named assignment and load-balancing modes. That decision layer is what eLogii adds.

What is the difference between Enhanced Scheduling and Optimization and a constraint-based routing engine?

Enhanced Scheduling and Optimization (ESO): runs scheduling against a configured scope, with goals (such as travel time minimization or resource utilization) and constraints expressed inside the Salesforce model; ideal for filling the Dispatcher Console within a scope where the model is stable. Constraint-based routing engine: given a constraint model (skills, capacity, time windows, SLAs, depots, recurring cadences, cross-day dependencies), produce the assignments themselves against an objective, with operator-visible modes and rule-based re-optimization, callable as REST endpoints. Salesforce Field Service plus ESO does the first cleanly within a scope. eLogii does both for the operations where the assignment problem spans depots, days and recurring programs. The two combine: Salesforce Field Service keeps the work order, customer asset, Maintenance Plan, inventory and Salesforce Field Service mobile app; eLogii owns the constraint-based decision layer.

When is the Dispatcher Console with Enhanced Scheduling and Optimization enough?

When dispatchers can comfortably make assignments by hand against Salesforce’s territory and resource models, with Enhanced Scheduling and Optimization filling the rest within a defined scope. This covers a wide band of Salesforce-anchored field-service operations across utilities, manufacturing, medical, telecom and facilities. Outgrowth: when assignment becomes a constraint-satisfaction problem across multi-depot, Maintenance Plan recurring service and reactive work that doesn’t fit neatly into a single ESO scope rather than a dispatcher judgement call.

How does eLogii’s optimization engine integrate with Salesforce Field Service?

Custom integration against the Salesforce Platform REST API. Salesforce exposes the Salesforce Platform REST API for every Field Service table, with Salesforce Flow, Platform Events and the Pub/Sub API for downstream subscribers. eLogii’s REST API has 70+ endpoints including the optimization endpoints, ApiKey auth and a full-parity sandbox. Once the connector is built: eLogii reads work orders, service crews, service resources, vehicles, territories and Maintenance Plans and Maintenance Work Rules from Salesforce, runs the optimization, writes optimized bookings and ETAs back. The technician opens the Salesforce Field Service mobile app on site; the routing they follow is the one eLogii planned.

What does eLogii’s optimization engine look like in product terms?

Two engines and six configurable modes, all REST-callable. The Default engine optimizes 100 tasks in under 10 seconds for high-throughput daily planning. The Advanced engine handles multi-depot, multi-day, long-haul and constraint-heavy operations. Three assignment modes: Optimize Everything, Add to Routes Keep Existing Assignments, Add to Routes Keep Existing Assignments and ETAs. Three load-balancing modes: Most Efficient Routes, Balance the Minimum Number of Routes, Use All Vehicles / Finish as Soon as Possible. Each is callable programmatically and visible to the dispatcher as a control they can see and steer.