Field Service Settings is where you turn the feature on and set its core policies. The steps below cover initial enablement and the first round of configuration most orgs do before going live.
- Open Field Service Settings
In Setup, type Field Service Settings into the Quick Find box and select it. This is the dispatcher-side configuration page, separate from Field Service Mobile Settings.
- Enable Field Service
Turn on the Enable Field Service toggle at the top. This activates the core objects (Work Order, Service Appointment, Service Territory, Service Resource) and makes the managed package available to install.
- Set operational defaults
Configure Enable Notifications, the Days After Created Date for auto-created appointments, the Knowledge search field (commonly Subject), and the mobile En Route status so daily behavior matches your business.
- Build a scheduling policy
Create at least one scheduling policy and attach work rules (Match Skills, Match Territory, Work Capacity) and service objectives (Minimize Travel, Minimize Gaps). Mark a default policy.
- Enable optimization and verify
Turn on Enhanced Scheduling and Optimization if you want the newer engine, then test scheduling against synthetic appointments in a sandbox before relying on it in production.
The master toggle that activates the core objects and the Dispatch Console framework. Required before any other setting matters.
Switches on push and in-app alerts so the workforce hears about assigned or changed work.
Sets how far in the future an auto-created Service Appointment's due date lands relative to its creation date.
Moves the org to the newer optimization engine, changing how appointment priorities bump and replace each other.
Maps your custom status values onto Salesforce status categories and defines allowed transitions.
- Enabling Field Service exposes new objects and tabs immediately, so do it during a low-traffic window and stage permission sets first.
- Core Field Service and the managed package are two layers. The toggle here handles the objects; the Dispatch Console and optimizer come with the package you install separately.
- Optimizer behavior depends on the work rules and objectives in your policy. A small rule change can reshuffle many appointments on the next run, so test in a sandbox.
- Renaming or recategorizing statuses after teams depend on them breaks saved list views, reports, and automations that referenced the old values.