February 26, 2026
A scheduling policy in Salesforce Field Service is a reusable set of work rules and service objectives that tells the scheduling optimizer which resource should get each service appointment. Work rules filter out technicians who don't qualify. Service objectives then rank the rest by weighted priorities like travel time, speed, and preferred resource. You build one in Guided Setup, weight the objectives to match your goals, then set it as the default or pick it in the Dispatcher Console.
Get the policy right and the whole operation runs cleaner: shorter drives, faster arrivals, fewer manual reassignments. Get it wrong and dispatchers fight the schedule all day. This guide covers what a policy is, how work rules and objectives differ, the four standard policies, the exact setup steps, how optimization uses your policy, and the fixes for the scheduling problems teams hit most.
Think of the scheduling policy as the brain of your operation. It's a set of rules and ranked goals that guide the optimizer when it decides which appointment goes to which resource. Whether you care most about cutting travel time or making sure a preferred technician handles a key account, the policy enforces that priority every time work is scheduled.
Salesforce Field Service Management ships with policies you can use on day one and clone as your needs grow. If you're standing up Salesforce FSM for the first time, our Salesforce Field Service implementation team designs the policy model around how your crews actually work, not a generic default. Trailhead's scheduling policy learning module is a solid companion reference as you follow along.
Every policy has two moving parts, and mixing them up is the number-one setup mistake. Here's the split:
AspectWork Rules (the filter)Service Objectives (the ranking)JobDecide who is eligibleDecide who is bestLogicPass or failWeighted scoreEffectRemoves candidatesRanks the survivorsExampleMatch Skills, Match TerritoryMinimize Travel, ASAP, Preferred ResourceTuning knobOn or offA numeric weight you set
Work rules are pass-or-fail filters. They build the list of eligible candidates by removing anyone who doesn't meet a hard requirement. A technician either clears the rule or drops off the list.
These are the work rules most teams lean on:
Effective work order management starts here: if the skills and territory data on your resources are clean, these filters do quiet, accurate work. Apex Hours has a helpful breakdown of work rules and objectives if you want another angle.
Once work rules narrow the field to qualified candidates, service objectives rank them. Each objective carries a weight that defines how much it matters relative to the others.
Weights are where policy design gets real. Say Minimize Travel sits at 4 and ASAP sits at 9. The optimizer will book a faster slot even if it adds drive time, because speed outranks travel. Flip those numbers and short drives win instead.
Change one weight at a time and test after each change. Weighting every objective high is the same as weighting none of them, since nothing stands out as the priority. This tuning is quiet, ongoing work, and it's a core part of the Managed Services we run for field teams once a policy is live.
Salesforce Field Service includes four ready-made policies so you can schedule on day one. Clone one before you customize, so the original stays intact.
Most teams start from Customer First, clone it, and rename the copy something descriptive like Gold Partner Service before touching the weights.
This walkthrough builds a custom policy from a cloned standard one.
That's the whole loop. The hard part isn't clicking through the steps; it's choosing weights that map to real ROI, which is where most first builds drift.
A saved policy can work two ways. You can set it as the Default Scheduling Policy in Field Service Settings so every automatic schedule uses it. Or a dispatcher can pick a different policy on the fly in the Dispatcher Console for a specific run.
That flexibility matters during scheduling and dispatch. A dispatcher can run Customer First all morning, then switch to Emergency the moment a storm or outage hits, without an admin touching settings.
The policy doesn't just power one-off scheduling. Salesforce Field Service optimization runs your policy across the whole schedule to place appointments in the best order. Global Optimization reshuffles a full territory and horizon; In-Day Optimization reoptimizes today's remaining work as conditions change.
Optimization is only as good as the policy behind it, and only as good as the data feeding both. Clean skills, territories, and operating hours are what let it produce trustworthy results. Wiring that data in from HR, inventory, or ERP systems cleanly is an integration architecture job. Automation Champion's Field Service optimization write-ups are worth a read on how the engine behaves.
Two settings quietly shape most schedules. Street-level routing tells the optimizer to calculate real road travel time instead of straight-line distance, which makes Minimize Travel far more accurate. Working territories control which resources can serve which areas on a given day.
Together they anchor real mobile workforce management: technicians get routes that make sense on the ground, and dispatchers stop hand-fixing drive times. If you're migrating off legacy Field Service Lightning, re-tuning these during the move is part of a clean Field Service re-engineering effort.
When work doesn't schedule the way you expect, the cause is almost always a rule or a weight. Here are the usual suspects and the fixes:
Forcetalks keeps a running set of Field Service scheduling Q&A threads that mirror these same issues if you want community context.
It's a set of work rules and weighted service objectives that tell the optimizer how to assign work. It balances business goals like low travel cost against customer needs like fast arrival.
Work rules are strict filters that decide if a technician is eligible for a job. Service objectives are weighted goals that rank the eligible technicians and pick the best fit.
Yes. Dispatchers can switch policies in the Dispatcher Console, for example moving from Customer First to Emergency during a storm or urgent outage.
Open Field Service Settings and set your chosen policy as the Default Scheduling Policy in Global Settings. Every automatic schedule then uses that policy unless a dispatcher picks another.
You can clone and create as many as you need. Most teams keep a small set - a daily default, a high-volume policy, and an emergency policy - so dispatchers aren't guessing.
Yes. Salesforce Field Service is built on Salesforce Service Cloud, so scheduling policies operate alongside cases, work orders, and service data in the same platform.
The Minimize Travel objective is likely weighted too low, or street-level routing is off. Raise the travel weight and enable street-level routing so the optimizer uses real road distance.
Setting up one policy takes minutes. Tuning a whole scheduling model so it holds up across seasons, territories, and releases is the real work - and that's the part we do. At Minuscule Technologies, we act as your Salesforce engineering partner across the full Field Service lifecycle, from policy design to optimization tuning and release governance.
Ready to stop fighting your schedule? Talk to our Salesforce Field Service consulting team about a policy setup engineered around your actual field operations.
You've seen what's possible. Now, let's make it happen for your business. Whether you need an end-to-end Salesforce solution, a complex integration, or ongoing managed services, our team is ready to deliver.
Schedule a Free Strategic Call
