A Salesforce Field Service implementation turns requests into work orders, work orders into scheduled appointments, and appointments into completed jobs recorded from a technician's phone. The build order that works is data model first, then territories, resources and skills, then scheduling rules, then the mobile app and parts inventory, and finally integrations. Roll it out one crew or region at a time, because dispatch habits change slowly and the schedule is only as good as the data behind it.
The objects you are really designing
Field Service adds a set of standard objects to Salesforce, and most design decisions come down to how you use them. Getting these right early matters more than any screen, since scheduling, reporting and the mobile app all read from them.
| Object | What it represents | Decision to make |
|---|---|---|
| Work order | The job to be done for a customer, site or asset | What creates it: a case, a sale, a maintenance plan or a dispatcher |
| Work order line item | A distinct task within the job | Whether multi-step jobs need separate tasks, skills or appointments |
| Work type | A template for a kind of job | Default duration, required skills and parts for each job type |
| Service appointment | The scheduled visit a technician is assigned | Created automatically or by hand; single-day or multi-day |
| Service territory | A group of resources, usually by geography | Boundaries, time zones and which territory is primary for each person |
| Service resource | A technician, crew or piece of equipment that can be scheduled | Who needs a license, and how contractors are represented |
| Operating hours | When resources work and when customers accept visits | Shifts, holidays and customer time windows |
Work types deserve more attention than they usually get. When each one carries an accurate duration and the skills it requires, appointments can be created and matched to people automatically. Loose work types push that judgment back onto dispatchers, who then work around the scheduler instead of with it.
Territories, resources and skills
Salesforce calls the service territory the most basic grouping of resources, and territories can follow geography, product lines or customer types. Draw them the way dispatch actually works today, then adjust. Territories that are too large make travel estimates meaningless; territories that are too small force constant cross-territory borrowing.
Skills are where the scheduler earns its keep. A packaging-automation manufacturer we worked with had installed the scheduling tool but never configured it, so dispatchers ran technician calendars in Outlook. The rebuild aligned service territories to time zones and matched skills across 37 work types and multiple machine specializations, with appointments created from work orders and territories assigned by address. Once skills lived in the system, the scheduler could propose people a dispatcher would have picked.
Decide early how subcontractors and seasonal labor are represented. Some should be full service resources with the mobile app; others only need to be tracked against jobs. That choice affects licensing, so settle it with real headcounts before configuration starts.
Scheduling and optimization
Scheduling policies define how Field Service picks a resource. Work rules filter out anyone who cannot do the job, such as a missing skill, the wrong territory or no availability, and service objectives rank the remaining candidates by goals like less travel, earlier arrival or a preferred technician. Salesforce also offers an enhanced scheduling and optimization engine, which it describes as more scalable and producing better schedule quality than the earlier architecture. Confirm which engine your org uses before you tune anything.
Start with one policy that mirrors how your best dispatcher thinks, test it against a week of real jobs, and compare its choices with what actually happened. Add optimization runs, such as a nightly run for tomorrow's schedule or in-day reshuffles, only after dispatchers trust single-appointment suggestions. Multi-day jobs need their own testing, because long installs behave differently from one-hour calls on the Gantt chart.
Mobile app and offline work
Salesforce describes the Field Service mobile app as offline-first on iOS and Android, so technicians can keep working in basements, rural sites and plants with no signal and sync when they reconnect. Design for that: decide which records each technician carries offline, and test sync on the oldest phones in the fleet, not a developer's laptop.
Keep mobile screens short. A scent-marketing manufacturer running inventory across 40+ divisions built three mobile flows for parts consumption, transfers and case creation, each kept to three or four fields, with account, site and territory filled in from the work order. Every field you remove from a technician's screen is one less reason for them to finish paperwork in the truck at the end of the day.
Parts and inventory
Field Service tracks inventory through locations (warehouses, sites or vehicles), product items (stock of a product at a location), product requests when parts are needed, product transfers that move stock between locations, and products consumed on a job. Stock levels update as transfers are received and consumption is recorded, so the numbers are only as reliable as technicians' logging.
- Decide whether every van is a stock location or only warehouses are tracked.
- Limit what technicians can see and consume to their own territory or vehicle, as the scent-marketing manufacturer did with territory-based sharing.
- Define how defective parts and returns flow back, including any quality-hold location.
- Pick one system of record for stock quantities and cost, usually your ERP, and sync the rest.
- Reconcile Salesforce counts against the ERP during the pilot before trusting either.
Integrations and rollout by crew
Most Field Service projects connect to an ERP for parts, costs and invoicing, and sometimes to mapping, payroll or asset-monitoring systems. Agree which system owns each piece of data and when it moves: whether a completed work order triggers an invoice, whether timesheets flow to payroll daily, and what happens when a sync fails mid-job. Build and test those flows with the pilot crew, not after go-live.
Then roll out crew by crew. Pick one territory with a supportive supervisor, run it in parallel with the old process for a short period, and have dispatchers log every override so you can see where the scheduling rules are wrong. Train technicians on the phone they will actually carry, in the field, rather than in a classroom. Expand to the next crew only when the first one closes jobs in the app without prompting.
