field-service-scheduling-policy-designer-query

name	field-service-scheduling-policy-designer-query
description	Designs the four policy-level settings for a Salesforce Field Service scheduling policy — name, optimization mode (In-Day vs Global), commit mode, and description — and delegates to work rule design when complete. Use this skill when a user wants to design, configure, or set up a Field Service scheduling policy's policy-level settings.
user-invocable	false
metadata	{"version":"1.0","domains":["Field Service"],"cliTools":[{"tool":"[Truncated]","semver":">=2.0.0"}]}

Managing Sfs Scheduling Policy Designer

When to Use This Skill

Use this skill to reason about and design a complete Salesforce Field Service (SFS) scheduling policy — the policy's intent, work rules that filter candidate resources, relevance groups that scope rules and objectives, and service objectives with mathematically consistent optimization weight values. Trigger whenever the user mentions a scheduling policy, work rules, service objectives, relevance groups, In-Day Optimization, Commit Mode, field service optimization, penalty points, or wants to configure or tune a Salesforce Field Service scheduling policy. Walk the user through defining requirements (work rules), scoping (relevance groups), and trade-off questions to derive consistent weights for each objective, then emit a structured build spec that a separate data-layer skill turns into records. This skill designs the policy; it does NOT create, read, update, or delete any records.

Workflow

Salesforce Field Service – Scheduling Policy Designer (Business Logic, Condensed)

This skill helps the user design a complete Salesforce Field Service scheduling policy end to end and then hands the design off — as a structured build spec — delegating all record operations to the sfs-sobject-create skill. This skill owns what the policy should be and why; it never touches how records are created.

Interview sequence (REQUIRED): Run interviews IN THIS ORDER and make sure not to skip any question, completing each before moving to the next:

Phase 1: Scheduling Policy Interview — Collect policy settings (name...

Phase 2: Work Rule Design Interview — Ask one question...

Phase 3: Service Objective Interview — Group trade-off questions by...

Phase 4: The scheduling policy definition — name, description, In-Day...

Phase 5: Work rules — the hard filters that decide...

Phase 6: Relevance groups — optionally scope a work rule...

Phase 7: Service objectives + weights — the soft scoring that grades the surviving options. This is the deepest part of the skill

a conversational trade-off interview back-calculates weight values from the penalty math so all objectives are calibrated on a consistent scale.

Phase 8: The build spec — a structured, machine-readable summary...

Rules vs. objectives — the core mental model: Work rules are hard filters — they reject any resource or slot that violates them, and are always applied before objectives. Service objectives are soft scoring — they grade the candidates that survive the rules and never reject anyone. If a user wants "must have X," that's a work rule. If they want "prefer X," that's an objective. Rules shrink the candidate list; objectives rank what's left.

Terminology: Always call the product Field Service when talking to the user — never use the abbreviation "FSL," even though it appears in this skill's own internal notes as shorthand for the managed package.

Scope boundary — design only, no CRUD: This skill produces decisions and values, never records. It has no knowledge of Salesforce object/field API names, composite API structure, or record-creation order, and it must not attempt to create, read, update, or delete anything. When the design is complete, it emits the build spec and delegates all record operations to the sfs-sobject-create skill. If the user asks "now create it" / "deploy this," produce (or finalize) the build spec and hand off to sfs-sobject-create.

How to use this skill: If the user just wants weights, go straight to Conversation Flow (the trade-off interview) — that behavior is unchanged. If they want to design or reason about the whole policy, work through the sections in order: policy definition → work rules → relevance groups → objectives/weights → build spec.

Source of truth: The calculations and weight-derivation math in this skill are authoritative — they reflect the true internal SFS optimizer behavior and take precedence over Salesforce public documentation, which is less precise about the math. The documentation links in Live Documentation References are for background and behavioral details that may change over time — fetch them for current details, but never let them override the penalty formulas in this skill.

---

Defining a Scheduling Policy

A scheduling policy bundles work rules and service objectives together and tells the optimizer how to schedule. This skill decides the policy's settings and intent; the data-layer skill creates the actual record. When helping a user design one, collect these policy-level decisions first — each maps to a field the data-layer skill will populate.

How to run this section conversationally: Ask about each setting one at a time — Name, then In-Day Optimization vs. Global, then Commit Mode, then Description — never bundle multiple questions into a single message; wait for the user's answer before asking the next. Keep this section scoped strictly to the policy-level settings below — do not mention work rules, the mandatory Service Resource Availability rule, or any other rules-related framing notes here; that framing belongs only once the conversation reaches the Work Rules section that follows. This skill always builds a fully custom policy from the user's own requirements: never offer, suggest, or ask whether the user wants to start from one of Salesforce's standard starter policies or any other template (see Starting points below — background only, not a conversational option). Always call the product Field Service — never use the abbreviation "FSL" in any interaction with the user.

Core settings:

• Scheduling Policy Name — the display name for the policy. Tip: if In-Day Optimization is enabled, Salesforce recommends putting "In-Day" in the name so it's easy to identify when dispatching or optimizing.
• Description — a free-text description of the policy's intent. Good place to record the "Policy at a Glance" summary this skill generates in Step 3.
• In-Day Optimization (boolean) — when true, the policy uses in-day optimization instead of global optimization. Global runs for hours across the full horizon; in-day is time-boxed for last-minute changes (up to 5 minutes with Enhanced Scheduling and Optimization, up to 10 minutes without it) and can be triggered by dispatchers or a scheduled job.
• Commit Mode — governs what happens when a dispatcher (or a scheduling operation) changes the schedule while a global/in-day/resource optimization is already running and the two conflict. Two values:
  • Always Commit — apply the change even if it conflicts with the in-progress optimization.
  • Rollback — reject/undo the conflicting change to protect the optimization run.

Capture each of these as a value in the build spec's policy object — do not worry about how the record is stored; that is the data-layer skill's job.

Mandatory rules (every policy) — this is the one canonical statement of this rule; every other mention in this skill just points back here:

• Service Resource Availability — always include exactly one in the design and the build spec (mandatory: true), regardless of what the user asks for. The Field Service managed package does not create this rule automatically, so it must always be emitted for the data-layer skill to create. If the user gives no availability details, emit a baseline Service Resource Availability rule anyway (no breaks, no overtime/travel flags) so the policy is valid.
• Earliest Start Permitted and Due Date (Match Time rules) — do not include these in the build spec. The Field Service managed package creates them automatically when the scheduling policy is created. Do not design, emit, or ask about them; they are provisioned for you.

Starting points (background only — not a conversational option): Salesforce ships four standard starter policies — Customer First, High Intensity, Soft Boundaries, Emergency. This is background knowledge only; never suggest or offer these to the user as a jumping-off point — every policy this skill designs is built fresh from the user's own stated requirements, not modeled on a template.

For behavioral background on these settings, fetch: service.pfs_scheduling.htm (see Live Documentation References).

---

Work Rules

Work rules are hard filters. They refine the candidate list for a service appointment by rejecting any service resource that violates a rule. They are always applied before service objectives, and objectives only ever score the resources that survive the rules. If a requirement is "must," it's a work rule; if it's "prefer," it's an objective.

Database rules vs. Apex rules (why it matters for performance)

• Database rules filter at the SOQL-query level — disqualified resources never come back from the database, so they're cheap. They're aggregated into one query and applied in no particular order.
• Apex rules run after the initial query, iterating over every returned candidate (like a for-loop) to validate — this has a real CPU cost, compounded by objective grading that runs afterward.
• Guidance: include at least one database rule so Appointment Booking / Get Candidates start from a small candidate pool. Aim to narrow to roughly ~20 candidates with database rules before Apex rules and objectives run.

The 16 work rule types

Each row: name — engine (DB/Apex) — what it does. "DB w/ ESO" means the rule runs at the database level only when Enhanced Scheduling and Optimization is enabled, and as Apex otherwise.

Work Rule	Engine	What it does
Service Resource Availability	Apex — MANDATORY	Ensures a resource is actually available: respects operating hours, travel, breaks, absences, and existing assignments. Also enforces capacity for capacity-based resources. Configurable breaks, gaps, overtime, and travel-to/from-home.
Match Time Rule	Apex	Constrains the scheduling window from an appointment's date/time fields. Ships with standard rules Earliest Start Permitted and Due Date (both mandatory), plus Scheduled Start / Scheduled End (arrival-window based).
Match Skills	Apex	Matches an appointment's skill requirements to a resource's assigned skills; can enforce skill level. Skill Type Logic is All Skills Match (AND) (default) or At Least One Skill Matches (OR) (OR requires ESO).
Match Fields	DB w/ ESO	Matches one appointment field to one resource field (1:1). Use Extended Match instead when comparing one appointment field against multiple resource values.
Match Boolean	DB w/ ESO	Requires a checkbox field on the resource to be true (or false). Max 5 per policy. Ships with standard "Active Resources."
Extended Match	Database	Custom-criteria matching via a junction object linking an appointment field to a related list on the resource (e.g., serviceable postal codes, product lines).
Match Territory	Database	Restricts to resources who are primary or relocation members of the appointment's service territory.
Working Territories	Database	Enforces primary and secondary service territory memberships.
Maximum Travel from Home	Database	Caps distance/travel time between a resource's home base and any assigned appointment.
Required Resources	DB w/ ESO	Forces assignment to a resource marked Required (Resource Preference on the WO/WOLI). Very restrictive.
Excluded Resources	DB w/ ESO	Prevents assigning a resource marked Excluded on the WO/WOLI.
Count Rule	Apex	Caps assignments, hours, or a custom value per resource per day (e.g., ≤8 scheduled hours, ≤N items on a truck). Time Resolution is Daily. Up to 10 custom-field count rules per policy.
Work Capacity	Apex — ESO only	Enforces per-territory Work Capacity Limit records (e.g., cap install work at 80% of territory capacity).
Service Appointment Visiting Hours	Apex	Enforces customer operating hours / allowed visit windows (e.g., weekdays 8 AM–noon). All-or-nothing rule (no relevance groups).
TimeSlot Designated Work	Apex	Reserves a time slot/shift for a specific work type — only that type schedules in that window. All-or-nothing rule (no relevance groups).
Service Crew Resources Availability	Apex	Ensures a crew-type resource is only assigned when the crew meets the parent record's minimum crew size.

Doc naming note: the docs' "Considerations" list once refers to "Enhanced Match" in the baseline-database-rules list — there is no rule type called Enhanced Match; it means Extended Match. Treat as a documentation typo.

Step 1 of building rules: define your requirements

If the requirement is…	Use this work rule
Resources need specific skills / proficiency levels	Match Skills; Extended Match
Non-skill matching factors (e.g., serviceable postal codes)	Match Boolean; Match Skills; Extended Match
Breaks during the day / specific or multiple breaks	Service Resource Availability (+ work rule entries for multiple breaks, ESO)
Can work go into overtime? Can resources travel outside working hours?	Service Resource Availability
Max number / duration of appointments per resource per day	Count Rule
A specific resource must be assigned	Required Resources
A specific resource must not be assigned	Excluded Resources
Customer has specific service-call time windows	Service Appointment Visiting Hours
Ensure crew-type resources get scheduled	Service Crew Resources Availability
Appointments have arrival windows / required arrival times	Match Time Rule
Cap travel distance from home / control travel cost across large territories	Maximum Travel from Home — ask whether the cap is by distance or by travel time (see note below)
Assign specific work types to a resource for part/all of a day	TimeSlot Designated Work
Restrict work to the resource's primary and secondary service territory memberships	Working Territories

Arrival Window Match Time rules (opt-in default pair). If the user wants appointments to honor customer arrival windows, ask them to confirm, and if they agree, emit two Match Time rules with these exact default settings — do not ask the user to fill these in, they are the standard arrival-window configuration:

Setting	Rule A	Rule B
Name	Arrival Window Start	Arrival Window End
Service Schedule Time Property	SchedStartTime	SchedStartTime
Service Time Operator	Later than or Equal to	Before or Equal to
Service Time Property	ArrivalWindowStartTime	ArrivalWindowEndTime
Pass Empty Values	true	true

Emit each as a Match Time work rule whose params carry those four values (keys serviceScheduleTimeProperty, serviceTimeOperator, serviceTimeProperty, passEmptyValues). These are separate from the mandatory Earliest Start Permitted / Due Date rules (never emitted — see Mandatory rules).

Interpreting and emitting break times (clock time vs. shift-start offset): A Service Resource Availability rule expresses breaks in one of two shapes, and this skill decides the shape and emits the values the data-layer skill needs — the data-layer skill never receives a clock time it has to convert. Choose the shape as follows:

• One fixed daily break at an absolute clock time (e.g. "30 minutes at 12:00 every day") → emit it as an absolute break: { "mode": "absolute", "startClock": "12:00", "durationMinutes": 30 }. No offset math, no working-day start needed.
• One or more breaks defined as an offset from the start of the working day (e.g. "a 30-minute lunch starting 3 hours into the shift") → emit each as an offset break, in minutes from the start of the working day: { "mode": "offset", "earliestStartOffsetMinutes": 180, "latestEndOffsetMinutes": 240, "durationMinutes": 30 }. All three of earliestStartOffsetMinutes, latestEndOffsetMinutes, and durationMinutes are mandatory for an offset break. When the user states the break in offset terms already (e.g. "3 hours after the start of day"), that offset is earliestStartOffsetMinutes (180) — do not ask for the working-day start; you don't need it.
• Breaks given as clock times but there is more than one (e.g. "15 minutes at 10:00 and 30 minutes at 12:00") → you must use the offset shape, which means converting each clock time into an offset from the start of the working day. You cannot do that without knowing when the day starts, so ask the user for the shift / working-day start, then compute earliestStartOffsetMinutes = (break start clock − day start) in minutes for each break. Never assume the day starts at midnight (that would turn "10:00" into a wrong 600-minute offset). (Only ask for the day start in this clock-time case — never when the break is already expressed as an offset.)

Always emit latestEndOffsetMinutes for every offset break — ask for it directly, do not fabricate a window. The earliest start comes from what the user stated (an offset, or a converted clock time) — do not invent ± tolerance windows around it (no "±1 hour" / "±2 hour" options). If the user only gave a break start (or a duration with no stated finish-by), ask them plainly for the latest the break may end, phrased in the same terms they used: if they gave an offset ("starts 3 hours after start of day"), ask "what is the latest it may end, as time after the start of the day?" and convert (e.g. "4 hours after start" → 240); if they gave a clock time, ask for a clock time and convert with the day start. If the user says the break is fixed/pinned with no flex, set latestEndOffsetMinutes = earliestStartOffsetMinutes + durationMinutes. Never emit an offset break missing any of the three fields, and never guess the latest-end. If a break requirement is too involved to convert reliably, ask clarifying questions or recommend the manual approach rather than guessing.

Maximum Travel from Home — establish the cap type, not the unit. When a requirement caps how far a resource may travel from home, ask the user whether the cap is by distance or by travel time — the two are configured differently and the data-layer skill needs to know which. Emit the value and the type in params: { "maxTravelFromHome": 50, "maxTravelFromHomeType": "Distance" | "Travel Time" }. Interpret the user's phrasing to set the type — "50 miles"/"50 km" ⇒ Distance, "45 minutes" ⇒ Travel Time — but do not ask for or emit a distance unit (miles vs km): it is not part of the work-rule config; the unit is governed by the org's locale/distance settings elsewhere, so the rule stores only the number. For Travel Time the value is minutes. Never emit the cap value without its type.

Step 2 of building rules: per-rule parameter questions

Once the requirements funnel (Step 1) has selected which rules to build, ask the specifics for each selected rule. The Emit line gives the exact params keys to put in the build spec — use these key names verbatim so the data-layer skill can map them to fields. Only ask about rules the user actually selected; keep the rest out of the conversation.

All rule types below have a fully-defined question → param path — the data-layer fields are confirmed against the Field Service managed-package model.

• Service Resource Availability (always present) — ask: "Can work run into overtime?" (yes/no) · "Can resources travel outside working hours to/from home?" — if yes, ask up to how many minutes of travel are allowed from home (to the first job) and to home (from the last job); treat "no limit" as 120 (Field Service's effective unlimited ceiling), and if the answer is no, both are 0 · and the breaks interview (see Interpreting and emitting break times above). Emit: { "enableOvertime": true|false, "travelFromHomeMinutes": <number>, "travelToHomeMinutes": <number>, "breaks": [ … ] }. travelFromHomeMinutes/travelToHomeMinutes are minute values, not booleans — 0 = no travel outside working hours, 120 = effectively unlimited, or the specific cap the user gives. If the user gives no availability detail, emit a baseline rule (enableOvertime: false, travel-minute keys and breaks omitted).
• Match Time (arrival windows) — ask only "Should appointments honor customer arrival windows?" If yes, emit the two default rules from the Arrival Window table above (no further questions).