Field Service Settings
Field Service Settings is the Setup page in Salesforce where admins enable Field Service and configure the dispatcher-side behavior of the product.
Definition
Field Service Settings is the Setup page in Salesforce where admins enable Field Service and configure the dispatcher-side behavior of the product. It is the single place to turn the feature on, set scheduling and optimization defaults, define how work orders and service appointments move through their statuses, and control notifications, service reports, and the Dispatch Console.
You reach it from Setup by typing Field Service Settings into the Quick Find box. The top of the page holds the Enable Field Service toggle, which activates the core objects (Work Order, Service Appointment, Service Territory, Service Resource) and makes the Field Service managed package available to install. Everything below that toggle is the policy layer that dispatchers, schedulers, and back-office teams rely on every day.
What lives inside the Field Service Settings page
The Enable Field Service toggle and what it switches on
The first action on the page is the Enable Field Service toggle. Turning it on activates the core data model: Work Order, Work Order Line Item, Service Appointment, Service Territory, Service Resource, and the related objects that hang off them. It also unlocks the Field Service permission sets and makes the managed package available for install. Without this toggle flipped, none of the Field Service objects or the Dispatch Console exist in the org, so this is always step one. The setting is org-wide and not something you turn off lightly once teams depend on it. Salesforce treats core Field Service (the objects and base scheduling) and the managed package (the Dispatch Console, the optimizer, the scheduling UI) as two layers. The toggle here handles the first layer. The managed package is installed separately, and many of its richer settings then appear once it is in place. So this page is the front door, but it is not the whole house. Plan the enablement during a low-traffic window, because new objects and tabs appear for users the moment it goes live.
Notifications, due dates, and the small toggles that shape daily work
Below enablement sits a cluster of operational settings that are easy to overlook but shape the technician and dispatcher experience. Enable Notifications keeps the workforce informed when work is assigned or changed, and it underpins the push alerts mobile workers receive. The Days After Created Date field sets how far out an auto-created Service Appointment's due date lands, so a value of 3 means a new appointment is due three days after it is generated. There is a setting for the field used when technicians search Salesforce Knowledge from a Work Order or Work Order Line Item, commonly the Subject field, which controls how relevant articles surface in context. A mobile widget setting maps an En Route status (often Dispatched) so the app knows when a technician is traveling to a job. None of these are dramatic on their own. Together they decide whether due dates make sense, whether the right help articles appear, and whether status updates feel accurate to dispatchers watching the board. Tune them early so the defaults match how your service business actually runs.
Scheduling policies, work rules, and service objectives
The scheduling section is where the page earns its keep. A scheduling policy is a named bundle of rules and goals that the system applies when it places a Service Appointment on a resource. Within a policy you attach work rules, which are hard constraints the optimizer must respect. Common rule types include Match Skills (only resources with the needed skills qualify), Match Territory (keep work inside the resource's service territory), and Work Capacity (do not overload a resource's daily limits). Alongside the rules sit service objectives, which are softer goals the optimizer tries to satisfy and weight against each other, such as Minimize Travel, Minimize Gaps, Group Nearby Appointments, and ASAP. The same appointment can produce very different assignments under two different policies, so most orgs build several (a tight same-day policy, a routine maintenance policy, an emergency policy). Settings is where these are defined and where you mark a default. Getting the balance of rules and objectives right is the difference between full technician calendars with sane drive times and a board full of conflicts.
Optimization and Enhanced Scheduling and Optimization
Field Service ships an optimization engine that reshuffles appointments across resources and time to honor the active policy. The page exposes the Enable Enhanced Scheduling and Optimization toggle, which moves the org to the newer engine and changes how priorities behave. With it on, a higher-priority appointment can bump a lower-or-equal-priority one out of a slot rather than overlap it, which keeps the schedule cleaner. You can run optimization globally, in a window, or for a single resource day, and you can enable enhanced optimization per service territory so different regions adopt it on their own timeline. Optimization reads everything the rest of the page configures: skills on resources, operating hours on territories, travel modes, and the objectives in the policy. That is why a change to a work rule can shift dozens of appointments the next time the optimizer runs. Treat optimizer changes carefully. Test them against synthetic appointments in a sandbox before enabling for production, because the engine's behavior can surprise teams who have not modeled their constraints fully.
Service appointment life cycle and status flows
Field Service uses status categories to standardize where any record sits in its life. Service Appointments move through categories like None, Scheduled, Dispatched, In Progress, Cannot Complete, Completed, and Canceled, while Work Orders and Work Order Line Items have their own pipelines. The Service Appointment Life Cycle settings let you map your custom status values onto those underlying categories so reporting, color coding on the dispatch board, and automation all behave consistently. You can also define which status transitions are allowed and what happens automatically when one occurs, for example flipping a parent Work Order when its appointments complete. This is what keeps a dispatcher's view trustworthy: a job marked In Progress really is being worked, and a Completed appointment rolls up the way managers expect. Plan the status model before you create custom values, because every report filter, flow, and dashboard downstream depends on it. Renaming or recategorizing statuses after teams rely on them is disruptive and tends to break saved list views and automations that referenced the old values.
The Dispatch Console and what dispatchers actually see
The Dispatch Console (the Gantt-based scheduling cockpit from the managed package) is configured in large part through these settings. You control the time frame and contents of the appointment list and the Gantt, customize each section's layout, and use field sets to decide which fields show in the appointment list, the resource view, and the detail panels. You can create custom dispatcher actions and custom appointment list filters so a scheduler can, for instance, instantly see all unscheduled emergency jobs in a region. The console is also where manual scheduling, drag-and-drop, and on-demand optimization happen, and the settings here decide how much of that power each dispatcher gets. A well-configured console means a dispatcher opens one screen and sees exactly the work, resources, and map context they need. A poorly configured one buries the right fields three clicks deep. Because the console reads the same policies and statuses defined elsewhere on the page, changes you make to scheduling or life-cycle settings show up here immediately, which makes this page the natural place to tune the whole dispatcher experience.
Service reports, Knowledge, and connected features
The page also governs how the deployment connects to the rest of Salesforce. Service report settings control the PDF documents a technician generates at the end of a visit, using templates with placeholders for work performed, parts used, customer signature, and photos, and you can keep several templates for different visit types. Knowledge settings decide which field drives article search from a Work Order so technicians get relevant guidance in the flow of work. Other toggles wire Field Service to surveys for post-appointment CSAT and to AI-driven scheduling recommendations where licensed. Each of these is opt-in per org, so a deployment starts lean and grows as the team is ready. The practical value is that one configuration surface ties the field workforce to documentation, customer feedback, and reporting without bolting on separate tools. When you audit a Field Service org, this page is the first stop, because almost every behavior a dispatcher or technician experiences traces back to a toggle or policy defined right here.
How to enable and configure Field Service Settings
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.
Prefer this walkthrough as its own page? How to Field Service Settings in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Set Up Field ServiceSalesforce
- Get Ready for Field Service Scheduling and OptimizationSalesforce
Straight from the source - Salesforce's reference material on Field Service Settings.
- Enable Field ServiceSalesforce
- FieldServiceSettings (Field Service Developer Guide)Salesforce
Hands-on resources to go deeper on Field Service Settings.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does flipping the first toggle, Enable Field Service, in Field Service Settings actually do?
Q2. Which Cloud does Field Service Settings primarily support as part of its feature surface?
Q3. Which related Salesforce features can Field Service Settings opt the org into for the field workflow?
Discussion
Loading discussion…