Adding an optimization engine alongside ServiceMax

What ServiceMax documents about routing and scheduling

ServiceMax positions the three products around the asset and the work order. The scheduling vocabulary is dispatcher-led:

• Service Board (Asset 360). Drag-and-drop and assisted scheduling against the asset and work-order record, rendered in the Salesforce Field Service Service Board. The optimization engine that powers it is Salesforce’s, descended from the ClickSoftware technology Salesforce acquired in 2019.
• Dispatch Console (Core). ServiceMax Core ships its own native scheduler and Dispatch Console for territory-based dispatch against the asset record.
• FieldFX surface. ServiceMax FieldFX ships its own field-ticketing and scheduling surface for the energy-services workflow (originally LiquidFrameworks, acquired 2021).
• Multi-resource crews, territories, maintenance plans. All three products support crew composition, skills, certifications, territory-based routing and maintenance plans against assets and entitlements.

What no ServiceMax product positions as the lead capability is a constraint-based optimization engine: an input model of work orders, technicians, vehicles, depots, skills, time windows, SLAs and recurring cadences, and a documented optimization API that produces assignments under an objective. That decision layer is what eLogii adds, callable over REST.

Where dispatcher-led scheduling reaches its boundary

The pattern is consistent across operations where this comes up:

• Dispatcher-as-optimizer. The dispatcher spends the morning hand-balancing work orders across technicians, territories and skill sets. The Service Board or Dispatch Console makes the placement easy to see; 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. ServiceMax models territory; cross-territory rebalancing as a single optimization input is operator work.
• Recurring maintenance plans at scale. Quarterly preventive against contracted entitlements, monthly inspections across an installed base. ServiceMax generates the work orders against assets and SLA terms; 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 certification 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 entitlement-locked stops, balance the flexible ones, and re-optimize on the fly when a no-access comes in.

At a glance: a 60-technician medical-device service organization

A medical-device OEM running diagnostic-equipment service across three regional service centers. Sixty service engineers in the field. Two dispatchers. The book splits roughly 50% contract maintenance (quarterly preventive against contracted entitlements) and 50% reactive break-fix on regulated equipment with SLA terms. ServiceMax Asset 360 covers the asset-centric workflow cleanly: asset hierarchy with sub-component visibility, warranty and contract validation against the work order, Salesforce Field Service mobile in the technician’s hands, parts tied into the service supply chain.

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 technician off sick at center 2 by manual moves across centers 1 and 3. ServiceMax tracks the asset, the work order, the warranty and the parts cleanly; the routing decision is dispatcher-led. Adding eLogii compresses that morning hour into a 10-minute review of a constraint-aware optimization run; ServiceMax continues to own the asset, the work order, warranty, contracts and parts.

The workaround in ServiceMax and where it breaks

The workaround is the dispatcher. The Service Board, the Dispatch Console and the FieldFX surface are good at what they’re built for, and an experienced dispatcher can carry a real operation on top of them. The friction shows up at scale: time spent on planning grows non-linearly with the number of technicians 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 system. 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 ServiceMax is the wrong tool. It means there is a constraint-based optimization decision layer the dispatcher today 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 the field app they already use (Salesforce Field Service in Asset 360, ServiceMax Go in Core, FieldFX mobile in FieldFX).

• 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 technician 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 technician with the right certification, without moving any customer-confirmed slots in the next 90 minutes. Visible to the dispatcher.

How the integration sits with ServiceMax

ServiceMax stays in place as the system of record for the asset, the work order, warranty, contracts and parts. The connector between the two products is custom-built; there is no published eLogii-ServiceMax integration on either side. ServiceMax exposes REST APIs across Core, Asset 360 and FieldFX; Asset 360 is also reachable via the Salesforce Platform APIs (MuleSoft is a common middleware). eLogii’s REST API has 70+ endpoints including the optimization endpoints. The flow:

1. Read from ServiceMax. eLogii reads work orders, assets, technicians, vehicles, depots and skill sets from the ServiceMax REST surface (directly in Core, via Salesforce Platform APIs in Asset 360, via the FieldFX REST surface for energy-services tickets). Recurring maintenance plans flow 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 ServiceMax. Routes and ETAs are written back. Completion data flows back to ServiceMax for asset history, warranty, parts and reporting.
4. Technician experience unchanged. The technician opens the Salesforce Field Service app, ServiceMax Go or the FieldFX 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 recurring maintenance program, or the business unit where the dispatch surface is leaking the most.

Frequently asked questions

Does ServiceMax have an optimization engine?

Yes, through different surfaces in each product. ServiceMax Asset 360 for Salesforce inherits Salesforce Field Service’s optimization engine, descended from the ClickSoftware technology Salesforce acquired in 2019. ServiceMax Core uses the native Dispatch Console scheduler. ServiceMax FieldFX has its own field-ticketing and scheduling surface for energy services. Those are valid for asset-centric service. What no ServiceMax product documents as the lead surface is constraint-based optimization across multi-day, multi-depot operations in one solver run, programmatic re-optimization with operator-visible rules, or a public REST surface for the optimizer itself. That decision layer is what eLogii adds.

What is the difference between ServiceMax’s scheduling and a routing optimization engine?

ServiceMax scheduling: the dispatcher places work orders against technicians and territories; the underlying engine (Salesforce Field Service in Asset 360, native Dispatch Console in Core, FieldFX surface in FieldFX) handles route-level optimization between assigned stops. Optimization engine: given a constraint model (skills, capacity, time windows, SLAs, depots, recurring cadences, cross-day dependencies), produce the assignments themselves against an objective. ServiceMax does the first cleanly. eLogii does both, exposed as a REST API. The two combine: ServiceMax keeps the asset, the work order, warranty, contracts, parts and mobile execution; eLogii owns the constraint-based decision layer the dispatcher today is the proxy for.

When is ServiceMax’s built-in scheduling enough?

When dispatchers can comfortably make assignments by hand against ServiceMax’s territory and asset models, and the underlying engine handles the route-level work cleanly. This covers a wide band of OEM service across medical devices, lab instruments, industrial equipment, semiconductor equipment, elevators, power and utilities. Outgrowth: when assignment becomes a constraint-satisfaction problem across multi-depot, recurring maintenance and reactive work rather than a dispatcher judgement call.

How does eLogii’s optimization engine integrate with ServiceMax?

Custom integration against the ServiceMax REST API on whichever product is in use. ServiceMax exposes REST APIs across Core, Asset 360 and FieldFX; Asset 360 is also reachable via Salesforce Platform APIs (MuleSoft is a common middleware). 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, assets, technicians, vehicles, depots and recurring maintenance templates from ServiceMax, runs the optimization, writes optimized routes and ETAs back. The technician opens the Salesforce Field Service app, ServiceMax Go or the FieldFX 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.