Salesforce Field Service Implementation
Salesforce Field Service — formerly Field Service Lightning — set up around how your field operation actually runs: territories and skills that match your crews, a scheduling policy your dispatchers trust, and a mobile app technicians use offline, at the job.
01
The product
What Salesforce Field Service is
Salesforce Field Service, formerly Field Service Lightning, is the part of Salesforce that runs work done at a customer’s site: it turns a case or a contract into a work order, books an appointment with a technician who has the right skills and is in the right place, and gives that technician a mobile app to do the job and close it out. It runs on Service Cloud, so the case, the account, the asset and the visit all live on the same record.
What it is made of
- Work orders and work types The job and its template: how long it takes, which skills it needs, which parts it usually consumes.
- Service appointments The scheduled visit, with an arrival window, a status and an assigned resource. One work order can need several.
- Service resources and crews The technicians, contractors and equipment that get scheduled, each with skills, a home territory and availability.
- Service territories and operating hours Where you work and when. Every scheduling decision starts from these, which is why they come first in a build.
- The scheduling engine Scheduling policies combine work rules, which must hold (the skill, the territory, the working hours), with service objectives, which are weighed (least travel, preferred resource, earliest slot).
- The Dispatcher Console The Gantt and map view where dispatchers see the day, drag appointments and let optimisation rebuild the schedule.
- The Field Service mobile app Offline-capable, for iOS and Android: the day’s appointments, the work order, the asset history, parts used, the service report and the customer’s signature.
- Parts, assets and maintenance Van stock and product consumed, installed assets with their service history, and maintenance plans that generate the next preventive visit on their own.
02
The setup
How a Field Service implementation is set up
The order matters more than in most of Salesforce, because the scheduler reads everything below it. Configure it out of order and the first symptom is a dispatcher overriding every suggestion it makes.
-
Territories and operating hours
Draw territories the way work is actually divided, not the way sales regions are, and give each its hours, holidays and time zone.
-
Resources and skills
Every technician, subcontractor and crew as a service resource, with the skills and skill levels they hold, their home base and their primary and secondary territories.
-
Work types
One per kind of job, with its duration, required skills and the parts it normally uses. Most of the scheduling quality comes from getting these right.
-
The scheduling policy
Start from one of the standard policies, then tune the work rules and weigh the objectives against a sample of real days from your own history, not invented test data.
-
The Dispatcher Console
List views, Gantt filters and map layers set up for how each dispatch team works its territory.
-
The mobile app
What gets primed offline, the flows a technician steps through at the job, the service report template and signature capture.
-
Parts and inventory, if in scope
Locations for warehouses and vans, product items, and what happens to stock when a technician records a part as used.
-
A first territory, live
One territory goes live ahead of the rest, so dispatchers can prove the policy on real work before it is rolled out everywhere.
03
Failure points
Where Field Service rollouts go wrong
Scheduling switched on before the data behind it
The most common cause of a stalled rollout. Operating hours with the wrong time zone, skills nobody maintains, and work types with a guessed duration make the engine produce schedules no dispatcher would accept. They stop trusting it within a week and go back to the whiteboard. The fix is the data, not the policy.
Territories drawn from the org chart
Territories copied from sales regions or cost centres send technicians across a region for a job the next team over could reach in ten minutes. Draw them from where work actually happens and which crews actually cover it; secondary territories cover the overlap.
A mobile app nobody designed
Prime everything and the app is slow to open; prime too little and the technician is standing at the job without the asset history they need. Offline priming, the job flow and the service report are designs in their own right, tested in a basement with the signal off.
Parts treated as an afterthought
If van stock is not tracked, a technician arrives without the part, the appointment is rebooked, and first-time fix rate — the number most field teams are judged on — falls. Decide early whether inventory is in scope, and if it is, model the vans as locations from day one.
Licences bought before the roles were counted
Field Service is licensed by role, and orgs regularly buy technician licences for people who only ever dispatch, or dispatcher seats for managers who only need reports. Count the roles first, then buy.
04
When to call
When you need a Field Service partner
A single team with a handful of technicians and one territory can get started from Salesforce’s own setup guidance.
Bring us in when
- There are several territories or contractor crews
- The schedule has to be optimised rather than just recorded
- Technicians work without signal
- Parts and van stock have to be tracked
- A rollout has stalled and dispatchers have gone back to spreadsheets
How we run it
We run it on the same five phases as every Salesforce implementation: an inventory of territories, resources, skills and work types first, a written design that names every scheduling rule, fortnightly demos in your sandbox, a first territory proved on real work, and a runbook your dispatch lead owns. For the product itself, from the business case to what it changes for a service team, read the benefits of Salesforce Field Service.
05
The problem
Why people call us about this.
A
Dispatchers build the day on a whiteboard or a spreadsheet, then type it into Salesforce afterwards.
B
The scheduler keeps sending the wrong technician, or one two hours away, and nobody can say why.
C
Technicians go back to paper the moment they lose signal, and the job is re-keyed at the end of the week.
06
What’s covered
The Salesforce we actually configure.
Scheduling can only be as good as the data it schedules against. So we build in the order the engine reads it: where you work and when, who can do what, what each job needs, and only then the rules that put them together.
07
How it runs
Five phases, and what you see at the end of each.
01 · Week 1
Inventory
What exists, who owns it, and which system is really the source of truth. Almost always surfaces something nobody knew was live.
A written map
02 · Weeks 2–3
Contract
The design in writing, with each decision and its reversal cost named. This is where we argue with the brief — before money is spent.
A signed scope
03 · Middle
Build
Built against the contract and reviewed against it. You see working software every two weeks, in your own sandbox.
Fortnightly demos
04 · Late
Prove
Volume testing at twice expected load, deliberate failure injection, and a replay run with your team watching.
A test evidence pack
05 · Final week
Hand over
Runbook, monitoring, escalation path and a named owner on your side — then a month watching it together before we step back.
Runbook and owner
08
First call
Thirty minutes. Three answers.
You speak to a certified architect, not a sales engineer. No deck, no discovery fee, and no obligation to go further — you leave the call with three things whether you hire us or not.
Whether this is even the right line
About a third of the time it is not, and we say so. Usually the ask is custom development when the real problem sits in the data model underneath.
A shape and a range
Roughly how long, roughly how many people, and the band it falls in. The firm number follows discovery about two weeks later, and it holds.
The two risks we would flag
The things most likely to blow the timeline on a project like yours — named on the call, before anyone has signed anything.
Book it for this week.
Pick a slot directly in the calendar — most questions get answered inside the thirty minutes.
09
FAQ
Asked on nearly every call.
Is Field Service Lightning the same as Salesforce Field Service?
Yes. Field Service Lightning was renamed Salesforce Field Service, and for a while it carried the Agentforce Field Service name. It is the same product: work orders, service appointments, scheduling, the Dispatcher Console and the Field Service mobile app, running on top of Service Cloud.
What licences does Salesforce Field Service need?
Field Service is licensed per user on top of Service Cloud, by role: dispatchers, the technicians who use the mobile app, and anyone else who schedules or is scheduled. The Dispatcher Console and the scheduling engine come from the Field Service managed package, installed into your org. We count the roles with you before anyone buys, because the licence mix is easy to over-buy.
Does the Field Service mobile app work offline?
Yes. The app primes the technician’s appointments, work orders, assets and knowledge onto the device, so they can update a job, record parts and capture a signature without signal, and it syncs when the connection returns. What gets primed has to be designed, or the app is slow to open and still missing the one record the job needs.
How long does a Field Service implementation take?
It follows the number of territories, work types and scheduling rules in scope, and whether parts and inventory are part of it. We give a number after the first two weeks, once territories, skills and work types are inventoried, rather than on the first call. A first territory usually goes live ahead of the rest, so dispatchers prove the scheduling policy before it is rolled out.
Can you fix a Field Service rollout that has stalled?
Usually, and more of it survives than people expect. Most stalled rollouts share a cause: scheduling was switched on before the territories, operating hours and skills behind it were right. We inventory those first, fix the data, and then re-tune the policy against real days from your own history.
Other lines