Use this skill to create, configure, or tune Field Service Lightning scheduling policies — including work rules (pass/fail filters) and service objectives (weighted ranking criteria). Covers the four default policies, custom policy design, work rule type selection, and objective weighting strategy. NOT for configuring service territories, resource availability calendars, or the Salesforce Scheduler (Appointment Scheduling) product.
This skill activates when a practitioner needs to create, modify, or troubleshoot a Field Service Lightning scheduling policy — the configuration object that governs how the scheduling engine filters and ranks available service resources for appointment slots. It covers work rule design, service objective weighting, and the selection between Salesforce's four built-in default policies.
Gather this context before working on anything in this domain:
FSL__Scheduling_Policy__c is the top-level scheduling policy object. It acts as a container for two categories of child configuration records:
Work Rules (FSL__Work_Rule__c) — hard pass/fail filters. A candidate time slot is eliminated from consideration if it violates any active work rule. Work rules are binary: the slot either passes or it does not. There is no partial credit.
Service Objectives (FSL__Service_Objective__c) — weighted ranking criteria. After work rules eliminate ineligible slots, service objectives score the remaining candidates. Each objective has a percentage weight set via a slider. Weights across all objectives in a policy should sum to 100%.
A slot must pass all work rules before it is ever scored by service objectives. The two layers are sequential, not simultaneous.
FSL includes 15+ built-in work rule types. The most frequently used types are:
| Work Rule Type | What It Filters |
|---|---|
| Service Resource Availability | Eliminates slots that fall outside the resource's working hours or during recorded absences. Required in every custom policy. |
| Match Skills | Eliminates resources who do not have the skills listed on the work order or work type |
| Match Required Skills | Like Match Skills but only enforces skills explicitly flagged as required |
| Match Territory | Eliminates resources who are not members of the service appointment's territory |
| Hard Boundary | Eliminates resources whose Primary or Relocation territory does not match the appointment territory |
| Match Boolean | Eliminates resources where a boolean field on the resource does not match a field on the appointment |
| Match Crews | Eliminates crew members who are not part of the assigned crew |
| Maximum Appointments | Eliminates resources who already have the configured maximum number of appointments for the day |
| Match Time Slot | Eliminates slots that fall outside the customer's preferred time windows |
| Match Job Family | Eliminates resources whose job family does not match the appointment |
| Exclude Weekends | Eliminates slots that fall on Saturday or Sunday |
Work rules can be added, removed, or duplicated within a policy. A policy with no work rules will never filter any candidate, which is rarely the correct behavior.
Service objectives score the candidate slots that survive work rule filtering. Each objective has a weight (a percentage between 0 and 100) set using a slider in the Scheduling Policy setup UI. Available objectives include:
A typical customer-focused policy weights ASAP and Preferred Resource heavily. A cost-focused policy weights Minimize Travel and Minimize Overtime heavily.
Salesforce ships four ready-to-use scheduling policies. They cannot be deleted and serve as starting points for customization:
| Policy | Primary Use Case | Key Characteristics |
|---|---|---|
| Customer First | Maximizing customer satisfaction and preferred windows | Weights customer time windows and preferred resource; lighter travel optimization |
| High Intensity | Maximizing appointment volume per technician per day | Weights ASAP and minimizes idle time; accepts longer travel for density |
| Soft Boundaries | Allowing cross-territory assignments without strict enforcement | No Hard Boundary work rule; technicians can be scheduled across territories |
| Emergency | Urgent, high-priority appointments requiring immediate dispatch | Weights ASAP heavily; lighter filtering to maximize candidate count |
Custom policies should be created by duplicating the closest default policy and adjusting rules and weights. Do not modify the default policies directly, as they are shared reference points across the org.
When to use: The org has a defined territory structure, technicians carry certifications required for certain work types, and scheduling must enforce both territory membership and skill eligibility before ranking candidates.
How it works:
Why not the alternative: Using a default policy as-is risks inheriting objectives and work rules that conflict with the org's specific requirements. Emergency policy, for example, has very permissive filtering which is wrong for routine maintenance scheduling.
When to use: A subset of work order types represent urgent or safety-critical appointments with strict response-time SLAs. These appointments need to be scheduled immediately regardless of territory, preferred resource, or travel optimization.
How it works:
Why not the alternative: Applying a standard policy to emergency appointments allows the work rules to filter out nearer technicians who happen to be in an adjacent territory. The result is a longer response time, which defeats the purpose of the emergency escalation.
| Situation | Recommended Approach | Reason |
|---|---|---|
| New org with no custom policy needs | Start with Customer First default | Balanced settings; good starting point before calibrating |
| Org needs strict territory enforcement | Add Hard Boundary work rule to custom policy | Hard Boundary enforces Primary/Relocation only; blocks cross-territory leakage |
| Technicians have certifications for work types | Add Match Skills or Match Required Skills work rule | Prevents unqualified dispatch; critical for safety-regulated industries |
| Custom policy is ignoring resource absences | Verify Service Resource Availability work rule is present | Without it, absences and off-hours are invisible to the scheduler |
| Emergency appointments need fastest response | Use or duplicate Emergency policy; remove territory boundary rules | Maximize candidate pool; weight ASAP at 100% |
| Business priority is cost reduction | Weight Minimize Travel and Minimize Overtime heavily | Directly reduces mileage reimbursement and overtime payroll costs |
| Technicians are being over-dispatched daily | Add Maximum Appointments work rule with daily cap | Prevents burnout and SLA degradation from over-scheduling |
| Appointments need customer preferred windows | Add Match Time Slot work rule; weight ASAP lower | Respect customer-preferred windows before optimizing for schedule density |
| Soft cross-territory coverage needed | Use Soft Boundaries policy or remove Hard Boundary rule | Allows technicians near a territory border to pick up adjacent appointments |
Step-by-step instructions for an AI agent or practitioner working on this task:
Identify the business scheduling priority — Interview the dispatcher or operations manager to determine the primary goal: customer satisfaction, travel efficiency, SLA compliance, or overtime control. This determines which default policy to start from and which objectives to emphasize.
Audit existing policy configuration — Navigate to Setup > Field Service > Scheduling Policies. Review all active policies, their work rules, and their objective weights. Identify which policy is currently applied to service territories and whether it is producing the correct scheduling behavior.
Duplicate the closest default policy — Never modify a default policy directly. Use the "Clone" or duplicate action on the most relevant default policy to create a named custom policy. This preserves the defaults as stable reference points.
Configure work rules — Add, remove, or adjust work rules on the new policy. Mandatory baseline: confirm Service Resource Availability is present. Add Match Skills or Match Territory based on org requirements. Remove rules that create unnecessary filtering for this policy's use case.
Set service objective weights — Use the objective weight sliders to reflect the business priority identified in step 1. Ensure weights sum to approximately 100% across all active objectives. Test objective weights by running a scheduling simulation on a test service appointment and reviewing the candidate ranking.
Assign the policy to territories or appointments — Set the custom policy as the default for the relevant service territories, or configure the scheduling policy field on service appointments via Flow or Apex for use-case-specific overrides (e.g., emergency appointments always use the Emergency policy).
Validate and monitor — After go-live, review the Gantt view for yellow triangle icons, which indicate work rule violations that were overridden during dispatch. A high rate of yellow triangles means the policy's work rules are too strict for real-world dispatch patterns and should be relaxed.
Run through these before marking work in this area complete:
Non-obvious platform behaviors that cause real production problems:
Missing Service Resource Availability rule causes the scheduler to ignore all working hours and absences — A custom scheduling policy created without the Service Resource Availability work rule will silently schedule appointments during technician lunch breaks, weekends, holidays, and recorded absences. No error is shown. The scheduler treats every time slot as valid because nothing is filtering by availability.
Yellow triangles on the Gantt are informational only — the dispatcher can still save — When a dispatcher manually assigns an appointment that violates a work rule, the Gantt displays a yellow warning triangle. This does not block the save or dispatch action. Practitioners sometimes assume the yellow triangle means the operation failed; it does not. The violation is logged but not enforced.
Default policies cannot be deleted but can be accidentally edited — The four default policies (Customer First, High Intensity, Soft Boundaries, Emergency) are not protected from in-place edits. An administrator editing a default policy "just to test something" changes the shared reference point for any territory or automation still pointing to it. Always duplicate before modifying.
Objective weights are percentages but do not auto-balance — Salesforce does not enforce that service objective weights sum to 100%. A policy can have weights totaling 40% or 200% and will not show a validation error. Imbalanced weights produce unexpected candidate rankings that are difficult to diagnose. Always manually verify the total.
Work rule order within a policy does not affect filtering sequence — Practitioners sometimes reorder work rules expecting earlier rules to apply first, like firewall rules. FSL applies all work rules simultaneously as a set of filters, not sequentially. Reordering them has no effect on the outcome.
| Artifact | Description |
|---|---|
| FSL__Scheduling_Policy__c record | Named scheduling policy containing the full work rule and objective configuration |
| FSL__Work_Rule__c records | Individual work rule records attached to the policy, each with a specific type and parameters |
| FSL__Service_Objective__c records | Objective records with calibrated percentage weights reflecting the org's scheduling priority |
| Policy assignment configuration | Territory-level default policy assignments or automation logic routing appointments to the correct policy |
| Validation checklist | Completed checklist confirming mandatory work rules, weight totals, and no default policy modification |
fsl-service-territory-setup — service territory and member configuration that work rules like Hard Boundary and Match Territory depend onfsl-service-resource-setup — resource skills, certifications, and availability records that Match Skills and Service Resource Availability rules evaluatefsl-work-order-management — work order and work type configuration, including required skills that drive rule matching