eLogii vs Salesforce Field Service: Comparison

Where each platform leads

Salesforce Field Service and eLogii do different jobs in the same field-service stack. Salesforce Field Service is the FSM: the system of record for the work order, the customer asset, the Maintenance Plan, the inventory transaction and the booking. eLogii is the routing engine for operations where the optimizer needs to do the heavy lifting across multi-day, multi-depot and constraint-heavy plans, and where the dispatcher needs the engine to decide assignments rather than steer them on the Dispatcher Console.

The combined deployment pattern: Salesforce Field Service stays the system of record for the work order, customer asset, Maintenance Plan, inventory and the booking itself. eLogii reads work orders, service crews, service resources, vehicles, territories, customer assets and Maintenance Plans and Maintenance Work Rules from Salesforce via the Web API, runs the optimization across the routing horizons the Dispatcher Console and Enhanced Scheduling and Optimization are not designed to lead on, and writes optimized bookings and ETAs back. The technician opens the Salesforce Field Service mobile app on site; the route they take is the one eLogii planned. Salesforce Field Service keeps the work-order lifecycle, asset record and inventory flow it owns end to end; eLogii owns the optimization decision layer.

What eLogii adds on top of Salesforce Field Service

Salesforce Field Service is the Salesforce FSM. eLogii is the routing engine for the optimization-driven side of the problem. The table below isolates where each side leads.

Sources: Salesforce Help: Salesforce Field Service overview, Enhanced Scheduling and Optimization overview, Dispatcher Console reference; eLogii optimization engines. Verified June 2026.

API surface and developer experience

Sources: eLogii API documentation; Salesforce Platform REST API overview; Salesforce Field Service developer guide. Verified June 2026.

Scale, security and commercial

Sources: Salesforce Field Service product page, Salesforce pricing, Enhanced Scheduling and Optimization overview, Salesforce Customer Stories, G2 reviews, TrustRadius reviews. Verified June 2026.

Route optimization, in detail

Salesforce Field Service’s scheduling is built around the work order and the service resource, surfaced on the Dispatcher Console, with Enhanced Scheduling and Optimization as the licensed AI layer on top. What neither the Dispatcher Console nor Enhanced Scheduling and Optimization positions as the lead capability is constraint-heavy optimization across multi-day, multi-technician and multi-depot operations in one solver run, recurring service programs at thousands of stops as a single optimization input, or a public REST surface for the optimizer itself with named assignment and load-balancing modes. eLogii’s optimizer covers exactly that side, callable over REST.

eLogii’s routing scope

eLogii’s optimizer is built around two engines and six configurable modes, all callable via REST and exposed to the dispatcher as controls they can see and adjust.

• 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 tasks into existing routes while preserving driver assignments), and Add to Routes, Keep Existing Assignments and ETAs (inserts new tasks 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 job count), and Use All Vehicles / Finish as Soon as Possible (maximize speed).

Beyond the modes, eLogii ships the operational surface the Dispatcher Console isn’t designed to lead on: multi-day and long-haul routing (“plan a single day or an entire month in one run”), multi-depot (“route across multiple depots, branches, or home start locations in a single run”), recurring service patterns via task and route template groups (weekly, monthly, quarterly, bespoke cadences modeled as inputs to the optimizer, not as Maintenance Plan-generated work orders to be hand-rebalanced), multi-technician crew jobs with skills, capacity and SLA constraints, and rule-based re-optimization the operator can see and steer.

What this means in practice

If the dispatcher’s morning routine is “open the Dispatcher Console, confirm the booking, drag the work order to the resource in the right territory, let Enhanced Scheduling and Optimization clean up the rest”, Salesforce Field Service is the right tool and adding eLogii would be over-engineering. If the dispatcher’s morning routine is “run the optimizer against today’s open work orders across three depots, balance against next week’s Maintenance Plan-generated maintenance book, protect the SLA-locked priority bookings, route around the resource who’s off Tuesday”, the Dispatcher Console is being asked to do a job it wasn’t built for and Enhanced Scheduling and Optimization is being stretched past its sweet spot. eLogii covers that side via REST API; Salesforce Field Service stays in place for the work order, the customer asset, the Maintenance Plan and the inventory.

When eLogii’s depth starts to matter

Salesforce Field Service covers the Salesforce-anchored field-service workflow well across utilities, manufacturing, medical, telecom and facilities. The signal that the routing problem has grown past what the Dispatcher Console and Enhanced Scheduling and Optimization were designed for tends to be operational rather than headcount-based. Three patterns show up:

• Optimizer-driven assignment under heavy constraint. When the dispatcher is spending the morning hand-balancing work orders across resources, territories and skill sets, the optimizer should be making those calls. The Dispatcher Console is designed for an experienced dispatcher steering work against the Salesforce work-order model; once the placement itself is the bottleneck and Enhanced Scheduling and Optimization isn’t closing the gap, a dedicated routing engine needs to step in.
• Multi-depot rebalancing as a daily input. A regional service organization with three or four depots, or a distribution arm running parallel to the field-service business, needs the optimizer to see all depots as part of the same problem. Salesforce Field Service models territory; cross-territory rebalancing as a single optimization input is not the Dispatcher Console’s strength.
• Recurring service programs at thousands of stops. Quarterly Maintenance Plans, monthly preventive cadences, contract-driven inspection programs across a large customer-asset base. Salesforce Field Service generates the work orders from Maintenance Plans against Assets; the optimization across the generated stops, interacting with reactive break-fix work, is the part that needs the engine.

Where any of these is the dominant shape of the work, eLogii is the routing layer. Where none of them is, the Dispatcher Console with or without Enhanced Scheduling and Optimization is the right tool and adding eLogii is over-engineering. The honest answer for many Salesforce Field Service customers is “you don’t need eLogii.” The honest answer for the operations where the optimizer is the bottleneck is that eLogii is built for exactly that.

What changes once eLogii is in place

Salesforce Field Service continues to do the Salesforce FSM work it’s built for. The difference shows up where the routing problem used to dominate. Brymec lifted productivity 30% and routing efficiency 20% on eLogii. ATS Building Products improved deliveries per route by ~98%. Porcelanosa runs eLogii with 95%+ ETA accuracy on daily distribution. Unimasters runs eLogii across a multi-country operation and achieved 50% less planning time and 49% fewer service calls. These are operational outcomes that come from moving the assignment problem from the dispatcher’s morning into the optimizer:

• Slot booking co-pilot. When a customer is offered a time window, eLogii’s slot availability returns only slots that already fit the current optimized plan. Cuts failed visits ~35%. Plugs into whichever booking layer is in use, including Experience Cloud and the Salesforce customer self-service portal over REST.
• Customer-driven rescheduling. Around 70% of reschedule requests handled without coordinator involvement. The customer picks a slot that already fits the plan and the route re-optimizes.
• Embedded tracking content. NPS surveys, safety briefings, access codes, treatment instructions, pushed onto the tracking page itself rather than handed off to a separate channel.
• Multi-brand tracking. Three brands run from one dispatch desk, each with its own logo, colors and layout.
• Map-native dispatch ops. Drag-and-drop reassignment with automatic ETA recalc on both routes; polygon, freehand and rectangle map selection; bulk actions on hundreds of stops; Gantt-style route timeline alongside the map; 13 historical segments refreshed overnight.
• Rule-based exception handling. Reroute a no-access visit to the nearest engineer with the right skill, but don’t move any customer-confirmed bookings in the next 90 minutes. Visible to the planner, not buried in a black-box optimizer.
• Workflow analytics. Average time per step, skip rates, error patterns, completion data. Where engineer hours actually went, not just where the routes went.

Running eLogii alongside Salesforce Field Service and the wider stack

The typical Salesforce-anchored field service stack: a Salesforce FSM for the work order, customer asset, Maintenance Plan and inventory (Salesforce Field Service), an ERP for finance and customer master data (Microsoft Dynamics 365 Business Central, Microsoft Dynamics 365 Finance & Operations, SAP, NetSuite), telematics for the vehicles (Samsara, Geotab, TomTom), an IoT layer for condition-based service (Einstein for Field Service), Slack on top, and a routing decision layer alongside the Dispatcher Console for operations where the optimizer is the bottleneck.

eLogii is built for that shape. It plugs into Salesforce Field Service, leaving the work-order lifecycle, customer asset record, Maintenance Plans, inventory and Salesforce Field Service mobile app where they already are. The technician opens the Salesforce Field Service mobile app on site; eLogii plans the route they take to get there, surfaces the live ETAs, picks up GPS, and pushes completion back into Salesforce. The common patterns:

• Salesforce Field Service + Dispatcher Console + eLogii. Salesforce Field Service owns the work order, customer asset, Maintenance Plan, inventory and Salesforce Field Service mobile app. eLogii owns the optimization layer where dispatch is dominated by multi-depot regional teams, recurring service programs at scale, or constraint-driven assignment across multi-day plans. Integration runs over the Salesforce Platform REST API and eLogii’s REST API; Salesforce Flow and MuleSoft are common middleware choices.
• Salesforce Field Service + Enhanced Scheduling and Optimization + eLogii. Enhanced Scheduling and Optimization handles the booking-level AI optimization within configured scopes. eLogii sits outside that scope as the routing engine for the multi-depot, multi-day, recurring-program horizons, called via REST and writing back the bookings Enhanced Scheduling and Optimization then enforces.
• Salesforce Field Service + Einstein for Field Service + eLogii. Einstein for Field Service ingests IoT telemetry and generates work orders against customer assets. eLogii routes the resulting service stops alongside the planned maintenance program in one optimization run.
• Salesforce Field Service + ERP + eLogii. When the financial system of record sits in Business Central, Finance & Operations, SAP or NetSuite, eLogii reads operational data from Salesforce and runs the optimization, writing bookings back for execution. The ERP integration stays where it is.

What makes the stack pattern straightforward:

• 70+ REST endpoints across Tasks, Routes, Drivers, Vehicles, Depots, Zones, Schedules, Forms and Optimization, designed for clean integration into a wider stack.
• Full-parity sandbox at api-sandbox.elogii.com so integration work can run in parallel with the existing Salesforce / ERP rollout.
• Webhooks with live driver GPS and ETA stream push real-time state back to Salesforce, the dispatcher view or the customer-facing app. No polling, no cron jobs, no stale data.
• Bulk operations. POST /tasks/createOrUpdateMany handles hundreds of tasks per call, built for high-volume ingest from any FSM or ERP.
• FSM, ERP and telematics independent. Customers running Salesforce Field Service, Salesforce Field Service, ServiceMax or IFS FSM use eLogii for the optimization layer alongside whichever FSM they already chose.

Salesforce exposes the Salesforce Platform REST API to every Salesforce org, with Salesforce Flow, Platform Events and the Pub/Sub API available for downstream subscribers. The two APIs combine cleanly: eLogii calls the Salesforce Platform REST API to read work orders, service resources, vehicles, territories, customer assets and Maintenance Plans and Maintenance Work Rules, runs the optimization across the routing horizons the Dispatcher Console and Enhanced Scheduling and Optimization are not designed to lead on, and writes optimized bookings and ETAs back. The Salesforce Field Service mobile app picks up the planned route; completion data flows back into Salesforce for the work-order record, customer asset history, inventory and reporting.

API surface, side by side

Both sides expose REST APIs. Salesforce’s is the integration surface for the Salesforce data model, reachable on every Salesforce org through the Web API, Salesforce Flow connectors and Platform Events and the Streaming API. eLogii’s is the integration surface for a routing and optimization engine, with the optimizer itself callable as REST endpoints.

eLogii API

• 70+ REST endpoints across Tasks, Routes, Drivers, Vehicles, Depots, Customers, Zones, Forms, Schedules and Optimization. Full reference.
• Authentication: ApiKey header, generated in Dashboard > Configuration > API Keys. Machine-to-machine without an OAuth round-trip.
• Sandbox: api-sandbox.elogii.com, full parity with production at api-35.elogii.com.
• Bulk operations: POST /tasks/createOrUpdateMany handles hundreds of tasks per call, built for high-volume ingest from any FSM or ERP.
• Optimization callable via REST: all six modes available programmatically; dispatchers can lock specific routes, manually reorder stops, or re-run with new constraints.
• Seven webhook event types, including Driver/Task Tracking Update with live GPS stream and Route ETAs Update. No polling, no cron jobs.
• Custom fields end-to-end through driver app, webhooks and reporting.
• FSM, ERP and telematics independent via REST API, including SAP, Oracle NetSuite, Microsoft Dynamics 365 Business Central, Sage, Acumatica, IFS, Infor, Joblogic, BigChange, Simpro, ServiceTitan, FieldRoutes, Salesforce Field Service, Samsara and Geotab.

Salesforce Field Service API

• Salesforce Platform REST API for every Field Service table, including work orders, service resources, service crews, bookings, customer assets, Maintenance Plans and inventory.
• Salesforce Platform connectors: Salesforce Flow flows on data changes, Apex triggers and plug-ins on data events, custom APIs and custom connectors.
• Platform Events and the Streaming API: Service Bus, Pub/Sub API and Event Hubs for streaming downstream subscribers off Salesforce change feeds.
• Sandbox environments: full Salesforce parity for development and UAT, managed in the Salesforce Platform admin center.
• What’s not externally callable as named optimization modes: Enhanced Scheduling and Optimization can be triggered programmatically against configured scopes, but the optimizer is not exposed as a documented set of assignment/load-balancing modes with operator-facing controls.

For an integration team, the typical pattern when Salesforce Field Service and eLogii are both in the stack: Salesforce Field Service owns the system of record for work orders, customer assets, Maintenance Plans, inventory and service resources; eLogii reads work orders/requirements/resources/vehicles/territories from Salesforce over the Web API, runs the optimization across the horizons the Dispatcher Console and Enhanced Scheduling and Optimization are not designed for, writes optimized bookings and ETAs back; Salesforce Field Service mobile app shows the route to the technician; completion writes back to Salesforce for the work-order record, customer asset history and inventory.

Pricing and time to live

eLogii runs alongside Salesforce Field Service; it does not replace what you’re paying Salesforce today. The question is what eLogii adds on top, and what it costs to add it.

eLogii pricing starts from $3,000 per month as a platform fee, banded by field staff, drivers, jobs per day and the modules required. Each band includes a quota; cost steps up when the operation crosses a band, not when you add an individual seat. Customers typically report 3 to 4× return on investment within 6 months, and combined Salesforce Field Service + eLogii rollouts complete in 3 to 5 weeks including the connector build.

Salesforce publishes list pricing for Salesforce Field Service on Enterprise Edition, billed annually: USD 165 per user per month for a Dispatcher or Mobile Employee license, USD 220 per user per month for Field Service Plus (Field Service plus Service Cloud), USD 50 per user per month for Contractor and USD 150 per user per month for Contractor Plus. Unlimited Edition runs roughly double those rates. Every Field Service deployment also needs at least one Service Cloud user license, and any existing Service Cloud customer adding Field Service needs at least one Dispatcher license. Enhanced Scheduling and Optimization is bundled with Field Service Plus or available as a separately negotiated add-on; the base Dispatcher and Mobile Employee SKUs include the Dispatcher Console and Auto-schedule but not the full ESO surface, and Salesforce typically caps optimization runs and scheduled jobs per day on add-on tiers. The pricing models compose: Salesforce charges per user for the FSM and the scheduling stack, eLogii charges a platform fee for the routing layer. There is no per-seat cost from eLogii.

When eLogii on top of Salesforce Field Service starts to pay off

Adding eLogii alongside Salesforce Field Service

Three steps for Salesforce Field Service customers whose dispatch problem has grown past what the Dispatcher Console and Enhanced Scheduling and Optimization are designed to solve. Salesforce Field Service stays in place for the Salesforce FSM; eLogii layers on as the routing engine.

Unimasters runs eLogii across a multi-country operation and achieved 50% less planning time and 49% fewer service calls. Multi-country rollouts deploy in weeks, not quarters.

Each pattern, in depth

Salesforce Field Service’s dispatch surface is excellent at Salesforce Field Service. Four patterns where the optimization decision layer alongside it is the bottleneck, each with its own deep dive:

Frequently asked questions

Is eLogii a Salesforce Field Service alternative or a complement?

Complement, in most cases. Salesforce Field Service is the FSM on the Salesforce Platform: work orders, customer assets, Maintenance Plans, inventory, the Dispatcher Console for the dispatcher and Enhanced Scheduling and Optimization as the optional AI add-on, with Einstein, Salesforce Flow, Slack and Service Cloud wired in. eLogii is the routing and optimization layer that runs alongside Salesforce Field Service when the planning problem starts to dominate: multi-depot field-service operations, dense same-day plans with hundreds of competing time-window constraints, optimizer-driven assignment across crews, recurring service programs at thousands of stops. Salesforce Field Service stays the system of record for the work order, customer asset, Maintenance Plan and inventory. integration runs over the Salesforce Platform REST API on one side and eLogii’s REST API on the other.

When does adding eLogii on top of Salesforce Field Service make sense?

When the Dispatcher Console stops being the right place to solve the optimization problem and Enhanced Scheduling and Optimization is not closing the gap. The Dispatcher Console is a powerful dispatcher cockpit for assignment, drag-and-drop and exception handling on top of Salesforce, and Enhanced Scheduling and Optimization adds AI-driven booking and optimization as a licensed add-on. Both are valid for the core work-order lifecycle. eLogii layers on when the operation needs constraint-aware assignment across multi-day, multi-depot and recurring patterns in one optimization run, programmatic re-optimization with operator-visible rules, and slot booking that respects the current optimized plan.

Does Salesforce Field Service handle multi-resource crews, multi-day plans and multi-depot routing?

Yes at the FSM-workflow level. Salesforce Field Service supports service crews for multi-resource bookings, multi-day work orders, Maintenance Plans and territory-based scheduling in Salesforce. Enhanced Scheduling and Optimization handles AI-driven scheduling within configured scopes. What neither the Dispatcher Console nor Enhanced Scheduling and Optimization positions as the lead capability is constraint-heavy optimization across multi-day plans and multi-depot rebalancing as a single optimization input, recurring service programs at thousands of stops in one solver run, or operator-visible rule-based re-optimization callable as a public REST surface. That’s where eLogii’s two engines and six configurable modes add depth, with Salesforce Field Service staying the system of record for the work order, customer asset, Maintenance Plan and inventory.

How does eLogii integrate with Salesforce Field Service?

Integration runs over the Salesforce Platform REST API and the Salesforce Platform connectors. eLogii’s REST API has 70+ endpoints, ApiKey auth, a full-parity sandbox at api-sandbox.elogii.com and seven webhook events including live driver GPS and Route ETAs Update. Salesforce Field Service exposes its data model through the Salesforce Platform REST API, Salesforce Flow, custom connectors and Platform Events / Pub/Sub API integration patterns. The typical pattern, Typically: eLogii reads work orders, service crews, service resources, vehicles, territories, customer assets and Maintenance Plans and Maintenance Work Rules from Salesforce; runs the optimization across the routing horizons the Dispatcher Console and Enhanced Scheduling and Optimization are not designed to lead on; writes optimized bookings and ETAs back. Completion writes back to Salesforce Field Service for the work-order record, customer asset history, inventory and reporting.

How does pricing compare?

Salesforce publishes list pricing. Salesforce Field Service is USD 165 per user per month per Dispatcher or Mobile Employee license on Enterprise Edition (billed annually), with the Contractor SKU at USD 50 per user per month and the Contractor Plus SKU at USD 150 per user per month. Enhanced Scheduling and Optimization is bundled with Field Service Plus or available as a separately negotiated add-on; base Dispatcher and Mobile Employee SKUs include the Dispatcher Console and Auto-schedule but not the full ESO surface, and Salesforce typically caps optimization runs and scheduled jobs per day on add-on tiers. Contractor SKUs cover occasional crew members at USD 50 per user per month or USD 150 per user per month with full mobile access. eLogii is a platform fee, banded by field staff, drivers, jobs per day and modules, from USD 3,000 per month. The pricing models compose: Salesforce charges per user for the FSM and Enhanced Scheduling and Optimization, eLogii charges a platform fee for the routing layer. Customers typically report 3 to 4× return on investment within 6 months on eLogii.

How long does adding eLogii to a Salesforce Field Service stack take?

Typically 3 to 5 weeks from kickoff to a phased go-live, including building the custom connector against the Salesforce Platform REST API. eLogii reads work orders, service crews, service resources, vehicles, territories, customer assets and Maintenance Plans and Maintenance Work Rules from Salesforce Field Service; routes, ETAs and completion data flow back. Most teams start with the business unit where the Dispatcher Console is leaking the most: usually a multi-depot regional field-service book, a recurring service program at scale, or the part of the operation where the dispatcher is hand-rebalancing every morning. Salesforce Field Service stays in place for everything else.

Why would a Salesforce Field Service customer add a routing engine instead of using the Dispatcher Console and Enhanced Scheduling and Optimization?

Three reasons. First, the Dispatcher Console and Enhanced Scheduling and Optimization were built to assign work to service resources against the Salesforce work-order model. Once the operation needs constraint-heavy multi-day, multi-depot optimization as the daily input, that surface is not the tool. Second, eLogii customers at scale report operational outcomes that go past what FSM scheduling alone delivers: Brymec 30% productivity and 20% routing efficiency; ATS Building Products 98% improvement in deliveries per route; Porcelanosa 60%+ planning time cut; Unimasters 50% less planning time and 49% fewer service calls. Third, eLogii exposes the optimizer itself as REST endpoints with seven webhook events, so the routing layer integrates cleanly into the Salesforce stack via the Salesforce Platform REST API, Platform Events and the Streaming API.

Is eLogii enterprise-grade?

Yes. eLogii runs operations at scale: J-Club (9,000+ stores), NHS, Belfast City Council, Vergo Pest Management (400 technicians, Tyro Group), Bristow & Sutor (200+ enforcement agents, 200,000+ case visits routed annually), Porcelanosa, Caldic and Berkmann Wine Cellars. ISO 27001 and SOC 2 Type 2 certified.