/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: ["sf"]
      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