Salesforce Field Service goes live and dispatchers keep overriding it, because the scheduling policies were built to platform defaults instead of your territories, skills and SLA tiers. We design the dispatch model first, then configure the engine, the work orders and the mobile app around it.
Trusted by 500+ organizations — including telecom, utilities, healthcare and manufacturing operations running mobile workforces on Salesforce with Twopir Consulting.
Built for Field Operations
The scheduling engine is almost never the problem. The policies, the data model and the configuration underneath it are. These are the patterns we find again and again when we audit a live org.
The engine is live but dispatchers override every assignment. Optimisation rules were never set against real service territories, skill requirements or SLA tiers — so manual dispatch reinserts itself within weeks of go-live.
Technicians arrive without the right parts, or without the required skill, or without asset history on the phone. Each failure looks individual; the root cause is that work order, asset and inventory data were never properly connected.
Technicians got the app and a two-hour training session, and six weeks later they are back on paper. The app was never configured around how they actually complete a job — the steps, the offline requirement, the signature capture.
Asset records were last touched at installation and parts availability never syncs with the warehouse. Technicians request stock that is not there and wait days. Every job carries an invisible logistics risk.
Job status arrives hours after completion and breach alerts fire after the breach. Utilisation reporting is a Monday-morning export. Without live visibility, management is reactive and the customer escalates before you do.
The partner closed the project. Three months on, dispatchers are back on the old system and the org holds six weeks of clean data followed by nothing. That is a design failure, not a training failure.
Salesforce Field Service is the application that manages a mobile workforce end to end on the Salesforce platform — work order creation, intelligent scheduling and dispatch, the technician mobile app, parts and inventory, asset and preventive maintenance, and the reporting on top of all of it. It extends the same data model your service and sales teams already use, so a case, a work order, an asset and a contract are all one customer record.
The scheduling engine is genuinely good. What decides whether it works is everything you put into it: service territory boundaries that match how crews actually travel, work rules that encode your real SLA tiers, skill definitions granular enough to matter, and job duration profiles taken from completion data rather than estimates. Configure those to the platform's defaults and you get routes an experienced dispatcher will beat in five minutes — which is exactly when they stop trusting the system.
So the work is operations design before it is configuration. We map the dispatch workflow first, then build the engine around it. Field Service also sits next to Service Cloud in most operations — the contact centre raises the work, the field completes it — and we architect that handoff as one system rather than two. Where service contracts and renewals are sold as well as delivered, Sales Cloud joins the same record.
Field Service work splits into three jobs with different costs, timelines and risks. Most people who call us are in the middle column — already licensed, already live, and not getting the dispatch performance they paid for.
For operations going live on Field Service for the first time
A first build, or a move off a standalone field service tool. We map the dispatch workflow before touching setup, then design territories, scheduling policies, work types and the mobile experience against how your crews actually work.
Delivered with configuration and Flow. Apex, custom Lightning Web Components and bespoke integration are scoped separately as build-on work — never absorbed silently into an implementation estimate.
For teams already live whose dispatchers override the engine
Our most common entry point. Licences are in place and the build was delivered, but routes get overridden, mobile adoption stalled and first-time fix never moved. We audit the policy design and rebuild the parts that are failing.
A rescue works inside your existing org and its data. Where the territory or asset model cannot support the operation you now run, we say so and scope that rebuild honestly rather than tuning around it.
For operations whose requirements have outgrown configuration
Custom development for what declarative tools cannot reach: bespoke technician screens, scheduling logic specific to your trade, and integrations that need real error handling because a failed parts sync sends someone to site empty-handed.
We only write code where configuration genuinely cannot do the job. Custom logic in a scheduling engine is the most expensive thing here to own — it has to be re-tested every release — so the boundary is argued case by case, in writing.
Every capability below is designed against your actual field operation — how work originates, how it is assigned, what a technician needs on arrival, and how SLA performance is measured.
We configure the optimisation engine against your real territory boundaries, SLA tiers, skill sets and job duration profiles — so dispatchers get routing they act on rather than a suggestion they override.
Work order templates built per job type — installation, repair, inspection, preventive maintenance, emergency — with the fields, checklists and completion logic that match how technicians actually execute.
The mobile app configured around how a technician completes work, not the default walkthrough. Adoption is decided in the design phase — which screens, which fields, what happens with no signal.
Asset records kept current from field completion data, and maintenance triggered by age, usage threshold or sensor reading — so service is planned rather than reactive and history is accurate on arrival.
AI helps here when the underlying data is clean — skills, durations and completion history. We assess that first, then implement only what will move first-time fix or travel time.
Dashboards that give field managers the signals they act on during the day, not a Monday export: live job status, SLA position, first-time fix by territory, utilisation by region and parts consumption.
A scheduling engine reserving parts that are not in the warehouse will produce a confident, well-optimised, wrong answer. Each integration below states its purpose and which direction the data actually moves.
Job cost, billing events and service contract coverage, so a completed work order raises an invoice without anyone re-keying it.
Field Service ⇄ ERP · bi-directionalReal stock levels and van inventory behind the scheduling engine, so a part the optimiser reserves is a part that actually exists.
Inventory → Field Service · near real timeSensor thresholds that raise a work order before the asset fails, turning an emergency call-out into a planned maintenance visit.
Sensors → Field Service · event-drivenThe middleware layer where retry logic and error visibility matter — a silently failed parts sync is the one integration failure that strands a technician.
Middleware ⇄ orchestrated, with retryThe contact centre raises the work and the field completes it. One data model means the case, the work order and the customer promise never disagree.
Case ⇄ work order · same platformAppointment confirmation, arrival windows and technician tracking sent to the customer — the single biggest lever on no-shows and inbound "where are they" calls.
Field Service → customer · SMS and emailEscalations and parts requests raised from the job into the channel where the depot or engineering team already works, with replies written back to the record.
Field Service ⇄ chat · alerts and repliesWork history, asset records and open jobs migrated off a standalone field service tool with the service trail intact, validated in a parallel run before cutover.
Legacy → Field Service · one-way cutoverA focused build covering work orders, scheduling policies, mobile configuration and core reporting typically runs 10–14 weeks. Add optimisation tuning, IoT, asset management, ERP connectivity and multi-territory operations and it is realistically 18–28 weeks.
Before we open a sandbox we map the dispatch operation: where work orders originate, how jobs are triaged and assigned, how territories and shifts really work, what a technician needs on arrival, how parts are sourced, and where SLA time is actually lost. The output is an architecture blueprint that every later build decision traces back to.
We build the foundation: service territories and operating hours, skill and job duration models, work types and completion checklists, then the scheduling policies and work rules on top. Policies are tested against historical job data before anyone dispatches with them, because a route a dispatcher can beat is a route they will override.
With scheduling stable we build the layers that depend on it: the technician mobile experience including offline behaviour, the ERP, inventory and IoT integrations that make dispatch decisions reflect reality, and any Einstein or Agentforce capability the data is actually clean enough to support. Built iteratively, with technicians reviewing the mobile flows as they are made.
Rollout is phased: dispatcher training on the real console workflow, technician onboarding on the actual mobile build, manager coaching on the live dashboard. We then run a 30-day optimisation sprint — policy tuning against real completion data, mobile refinements from technician feedback — because the first month of live data always shows things no requirements document predicted.
Two engagements, and the numbers they moved. Each figure is scoped to the operation it was measured in — these are results from specific builds, not a promise about yours.
Twopir designed our scheduling logic from scratch. We had licences for 18 months but dispatchers were still using spreadsheets, because the scheduling engine had never been properly configured. After the rebuild our first-time fix rate went from 58% to 86% in the first quarter. The dispatchers stopped managing the system and let it manage them.
Multi-region Field Service rebuild, starting with the scheduling policies.
The organisation ran across multiple service regions with different SLA structures, technician skill requirements and disconnected billing systems. Twopir completed the Field Service and ERP integration within weeks and optimised the scheduling workflows from day one. Route efficiency improved substantially and operational delays came down.
Multi-region Field Service build with ERP integration for billing and job cost.
The mechanics differ by sector but the failure mode does not: a scheduling engine that does not reflect how the work is really done. If one of these describes your operation, the first conversation will be short and specific.
Installation, repair and maintenance across multiple regions with SLA commitments you cannot afford to miss, and a truck-roll cost that makes every avoidable second visit visible on the P&L.
Home health, medical equipment and clinical field teams needing compliance-aware job management, documentation that stands up to audit, and real-time visit tracking. See our healthcare practice.
Equipment makers and industrial service providers with complex asset hierarchies, multi-region crews, and preventive maintenance that has to stay connected to ERP and billing. See our manufacturing practice.
Large field workforces handling installation, fault response and metering at scale, where SLA compliance and dispatch efficiency drive both customer satisfaction and regulatory standing.
Multi-site maintenance contracts spanning several trades, tiered SLAs and client-facing reporting, where the schedule has to respect both the contract and the building's access windows.
You have the licences and the implementation was delivered, but dispatchers work around it and first-time fix never moved. This is our most common starting point, and it usually reaches results faster than starting over.
Field service implementations do not fail on the platform. They fail on policies that were never written against the real operation, and on a mobile app designed after the build instead of before it.
Out-of-box work rules look clean in a demo and produce manual override in week two. We configure against your service territories, SLA tiers and technician profiles, then test the policies against historical jobs before go-live.
Step sequence, offline behaviour, required fields, signature capture and completion logic are all decided before the build starts. Adoption is won in the design phase — a training session cannot rescue a flow that does not fit the job.
Field Service without clean ERP, inventory and asset integration dispatches against data that does not match the world. We have connected it to SAP, Oracle, NetSuite and proprietary systems through MuleSoft, Workato and Celigo — part of our wider Salesforce services.
The implement / rescue / build-on boundary is written into the scope before work starts. You are told which one you are buying, and custom code in the scheduling layer is argued for in writing rather than appearing on an invoice.
Twopir Consulting has delivered Salesforce for 12+ years, and we close engagements with a documented 30-day optimisation sprint against real completion data — not a project-closure email.
All three name the same product, in that order. It launched as Field Service Lightning (FSL), was renamed Salesforce Field Service, and in the 2025–26 Agentforce rebrand became Agentforce Field Service. Licences, API names, object names and existing configuration are unaffected by the renames, and most practitioners still say "FSL" in conversation. One point worth clarifying: there is no Salesforce product called "Field Service Cloud" — that is Oracle's product name. Buyers use the phrase informally for the Salesforce product all the time, but if you are running a vendor comparison it is worth being sure which product a document is actually describing.
A focused implementation covering work order management, scheduling policies, mobile app configuration and core reporting typically runs 10 to 14 weeks. A fuller deployment including optimisation engine tuning, IoT integration, asset management, ERP connectivity and multi-territory operations typically runs 18 to 28 weeks. The main drivers are the number of service territories, how many distinct work types you run, integration complexity, and whether you are starting clean or correcting an existing build. Scope, timeline and milestones are agreed before any build begins.
Usually yes, and this is our most common Field Service engagement. Override behaviour is almost always a policy problem rather than an engine problem: service territories that do not match how crews travel, skill definitions too coarse to distinguish who can actually do a job, job durations taken from estimates instead of completion data, or work rules that do not encode the real SLA tiers. We audit the scheduling policy design, territory configuration, work rule logic, mobile setup and integration health, then rebuild the parts that are failing inside the existing org. A full rebuild is only warranted when the territory or asset model cannot represent the operation you now run — and we will tell you plainly if that is the case.
Configuration covers service territories and operating hours, scheduling policies and work rules, work types and completion checklists, the standard mobile experience including offline behaviour, asset and maintenance plans, and most automation through Flow — which is the majority of what a field operation needs. Custom development starts when the technician experience needs a screen the app does not ship, when scheduling or completion logic must run at a volume or complexity Flow cannot handle reliably, or when an integration needs genuine error handling and retry. We hold that line harder on this product than on most, because custom logic inside a scheduling engine has to be re-validated at every Salesforce release.
We connect Field Service to SAP, Oracle, Microsoft Dynamics, NetSuite and proprietary ERP systems using MuleSoft, Workato, Celigo or direct API integration, depending on your data volume and the middleware you already own. Asset data, inventory levels, parts availability and billing events can be synchronised in both directions, so dispatch decisions reflect real stock and a completed job triggers invoicing without re-entry. The direction and freshness of each feed matters more here than on most products: a parts feed that lags by a day will let the optimiser reserve stock that is not there, and the technician finds out on site.
Yes — Einstein Work Recommendations for job-to-technician matching, Appointment Assistant so customers can self-schedule and track arrival, and Agentforce flows for appointment confirmation, technician briefing and escalation routing. The honest caveat is that all of it depends on the quality of the underlying data: skill definitions, job duration history and completion records. AI on top of coarse skills and estimated durations produces confident, wrong recommendations. We assess that readiness during the architecture phase and will tell you if the sensible sequence is to fix the data model first and add the AI in a second phase.
They solve adjacent problems. Service Cloud runs the contact centre: cases, omni-channel routing, entitlements and knowledge, for work resolved remotely. Field Service runs the mobile workforce: work orders, scheduling and dispatch, the technician app, parts and assets, for work that requires someone on site. If every issue is resolved by an agent at a desk, you do not need Field Service. If your service promise involves sending a person somewhere, you need both — and the handoff between them is where most of the value and most of the failure sits, because Field Service builds on the Service Cloud data model rather than sitting beside it.
We audit the Field Service org you already have — scheduling policies, territory and skill model, work order design, mobile configuration and integration health — and hand back written findings with prioritised recommendations. If the fix is smaller than you feared, that is what it will say.
Response within 24 hours · We start with diagnosis, not a sales call · Contact the team
