field-service-work-rule-designer-configure

Salesforce Field Service – 工作规则设计器

为排程策略设计工作规则。 此技能通过结构化访谈收集工作规则配置——每次只提一个问题——并输出 workRules[] 块。它不会创建任何 Salesforce 记录。完成后，会委派给 sfs-service-objective-designer。

访谈阶段： 排程策略 → 工作规则（此技能）→ 服务目标 → 记录创建

---

工作规则

工作规则是硬性筛选条件。 它们通过排除任何违反规则的服务资源，缩小服务预约的候选列表。工作规则始终先于服务目标应用，而服务目标只会为通过规则筛选的资源评分。如果要求是“必须”，那就是工作规则；如果是“优先”，那就是服务目标。

16 种工作规则类型

每行的格式为：名称 — 引擎（DB/Apex）— 作用。“DB w/ ESO”表示仅在启用 Enhanced Scheduling and Optimization 时，规则才在数据库级别运行；否则以 Apex 方式运行。至少使用一条 DB 规则，在 Apex 规则运行前将候选项缩减至约 20 个。

工作规则	引擎	作用
服务资源可用性	Apex — 必需	确保资源确实可用：遵循营业时间、差旅、休息、缺勤和现有分配情况。还会为基于容量的资源强制执行容量限制。可配置休息、间隔、加班以及往返住所的差旅。
匹配时间规则	Apex	根据服务预约的日期/时间字段限制排期时间窗口。附带标准规则 最早允许开始时间和到期日期（两者均为必需），以及基于到达时间窗口的已排期开始时间/已排期结束时间。
匹配技能	Apex	将服务预约的技能要求与资源的已分配技能进行匹配；可强制执行技能等级。技能类型逻辑为匹配所有技能（AND）（默认）或至少匹配一项技能（OR）（OR 需要 ESO）。
匹配字段	DB w/ ESO	将一个服务预约字段与一个资源字段进行匹配（1:1）。如果要将一个服务预约字段与多个资源值进行比较，请改用 Extended Match。
匹配布尔值	DB w/ ESO	要求资源上的复选框字段为 true（或 false）。**每个策略最多 5 条。**附带标准规则“活跃资源”。
扩展匹配	数据库	通过将服务预约字段与资源上的相关列表关联的联接对象，按自定义条件进行匹配（例如，可服务的邮政编码、产品线）。
匹配服务区域	数据库	将范围限制为服务区域中的主要成员或调动成员资源。
工作区域	数据库	强制执行服务区域的主要和次要成员资格。
最大居家差旅距离	数据库	限制资源住所与任何已分配服务预约之间的距离/差旅时间。
必需资源	DB w/ ESO	强制分配给标记为必需的资源（工单/工单产品上的 Resource Preference）。限制性很强。
排除资源	DB w/ ESO	禁止分配工单/工单产品上标记为排除的资源。
计数规则	Apex	限制每个资源每天的分配次数、工时或自定义值（例如，每天排期工时 ≤8、卡车上的物品数 ≤N）。时间分辨率为每日。每个策略最多可配置 10 条自定义字段计数规则。
工作容量	Apex — 仅限 ESO	强制执行各服务区域的 Work Capacity Limit 记录（例如，将安装工作量限制在服务区域容量的 80%）。
服务预约访问时段	Apex	强制执行客户营业时间/允许访问时段（例如，工作日上午 8 点至中午）。此规则只能整体启用或停用（不支持相关性组）。
时段指定工作	Apex	将某个时段/班次预留给特定工作类型——该时段内只排期此类型的工作。此规则只能整体启用或停用（不支持相关性组）。
服务团队资源可用性	Apex	确保仅当团队型资源符合父记录中规定的最低团队人数时，才分配该资源。

需求映射

不要从规则列表入手——应先了解业务需求，然后将每项需求映射到满足该需求的规则。带领用户完成此映射：

如果需求是……	使用此工作规则
资源需要特定技能／熟练程度	匹配技能；扩展匹配
非技能匹配因素（例如，可服务的邮政编码）	匹配布尔值；匹配技能；扩展匹配
白天休息／特定或多次休息	服务资源可用性（多次休息、ESO 需添加工作规则条目）
工作能否延长至加班？资源能否在工作时间之外出行？	服务资源可用性
每个资源每天的预约数量／时长上限	计数规则
必须分配特定资源	必需资源
不得分配特定资源	排除资源
客户对服务呼叫有特定时间段要求	服务预约上门时段
确保安排班组类型的资源	服务班组资源可用性
预约有到达时间段／要求的到达时间	匹配时间规则
限制从家出发的行驶距离／控制大范围区域内的行驶成本	最大居家行驶距离 — 询问上限是按距离还是按行驶时间计算（见下方说明）
为资源分配一天中的部分／全部时段所对应的特定工作类型	时段指定工作
将工作限制在资源的主要和次要服务区域成员资格范围内	工作区域

始终恰好包含一条服务资源可用性规则 — 这是此技能生成的唯一必需规则。绝不生成 Earliest Start Permitted 或 Due Date — 系统会自动配置。

到达时间段匹配时间规则（默认选择加入的一对规则）。 如果用户希望预约遵循客户的到达时间段，请征求确认；如果用户同意，则生成两条 Match Time 规则，并使用以下确切的默认设置 — 不要要求用户填写这些设置，它们是标准的到达时间段配置：

设置	规则 A	规则 B
名称	Arrival Window Start	Arrival Window End
服务计划时间属性	SchedStartTime	SchedStartTime
服务时间运算符	Later than or Equal to	Before or Equal to
服务时间属性	ArrivalWindowStartTime	ArrivalWindowEndTime
通过空值	true	true

将每条规则生成为 Match Time 工作规则，其 params 携带这四个值（键为 serviceScheduleTimeProperty、serviceTimeOperator、serviceTimeProperty、passEmptyValues）。这些规则与必需的 Earliest Start Permitted / Due Date 规则相互独立（绝不生成）。

解读和生成休息时间（时钟时间与班次开始偏移量）： Service Resource Availability 规则以两种形式之一表示休息时间，而此技能负责决定形式，并生成数据层技能所需的值 — 数据层技能绝不会收到需要转换的时钟时间。按以下方式选择形式：

• 每天在一个固定的钟表时间休息一次（例如“每天 12:00 休息 30 分钟”）→ 将其输出为绝对时间休息：{ "mode": "absolute", "startClock": "12:00", "durationMinutes": 30 }。无需计算偏移量，也无需知道工作日开始时间。
• 一次或多次休息，按相对于工作日开始时间的偏移量定义（例如“班次开始 3 小时后开始午休 30 分钟”）→ 将每次休息输出为偏移量休息，单位为距工作日开始时间的分钟数：{ "mode": "offset", "earliestStartOffsetMinutes": 180, "latestEndOffsetMinutes": 240, "durationMinutes": 30 }。偏移量休息必须包含 earliestStartOffsetMinutes、latestEndOffsetMinutes 和 durationMinutes 这三个字段。如果用户已经用偏移量描述休息时间（例如“当天开始 3 小时后”），该偏移量就是 earliestStartOffsetMinutes（180）——不要询问工作日开始时间；不需要知道它。
• 休息时间以钟表时间给出，但有多个时间点（例如“10:00 休息 15 分钟，12:00 休息 30 分钟”）→ 必须使用偏移量格式，也就是说，要将每个钟表时间转换为相对于工作日开始时间的偏移量。不知道一天何时开始就无法计算，因此请询问用户班次／工作日的开始时间，然后为每次休息计算 earliestStartOffsetMinutes = (休息开始钟表时间 − 工作日开始时间)（单位为分钟）。绝不要假定一天从午夜开始（否则会将“10:00”错误地转换为 600 分钟的偏移量）。（仅在这种钟表时间场景下询问工作日开始时间——如果休息时间已经用偏移量表示，则绝不要询问。）

每次偏移量休息都必须输出 latestEndOffsetMinutes——直接询问用户，不要捏造时间窗口。 最早开始时间取自用户提供的信息（偏移量或转换后的钟表时间）——不要自行添加 ± 容差窗口（不要提供“±1 小时”／“±2 小时”选项）。如果用户只提供了休息开始时间（或只提供时长，未说明最晚结束时间），请直接询问休息最晚可以何时结束，并沿用用户使用的同一种表达方式：如果用户提供的是偏移量（“当天开始 3 小时后开始”），就问“从当天开始算，最晚可以在几小时后结束？”，并进行换算（例如“开始后 4 小时”→ 240）；如果用户提供的是钟表时间，就询问钟表时间，并结合工作日开始时间进行换算。如果用户表示休息时间固定／不可变，没有灵活空间，则设定 latestEndOffsetMinutes = earliestStartOffsetMinutes + durationMinutes。绝不要输出缺少这三个字段中任何一个的偏移量休息，也绝不要猜测最晚结束时间。如果休息要求过于复杂，无法可靠换算，请提出澄清问题，或建议采用手动方式，而不要猜测。

从家出行的最大限度——确定上限类型，而非单位。 如果要求限制资源从家出行的距离或时间，请询问用户上限是按距离还是按出行时间计算——两者的配置方式不同，数据层技能需要知道采用哪种方式。将数值和类型输出到 params：{ "maxTravelFromHome": 50, "maxTravelFromHomeType": "Distance" | "Travel Time" }。根据用户的表述设置类型——“50 英里”／“50 千米” ⇒ Distance，“45 分钟” ⇒ Travel Time——但不要询问或输出距离单位（英里还是千米）：它不是工作规则配置的一部分；单位由其他位置的组织区域设置／距离设置决定，因此规则只保存数值。对于 Travel Time，数值单位为分钟。绝不要在没有类型的情况下输出上限数值。

每条规则的配置

需求映射选定要构建哪些规则后，配置每条规则的具体内容。Emit 行会给出准确的 params 键——请原样使用，以便数据层技能进行映射。只配置用户选定的规则，其余规则一律跳过。

---

服务资源可用性 （始终存在） 门槛：始终包含 — 无需选择。 询问：

• “工作是否可能超时？”（是/否）
• “资源能否在工作时间之外往返住所？”— 如果可以，询问从住所到第一个工作地点以及从最后一个工作地点到住所分别需要多少分钟；“不限” = 120；“不可以” = 两者均为 0
• 休息时间访谈（参见解读和输出休息时间）

输出：{ "enableOvertime": true|false, "travelFromHomeMinutes": <number>, "travelToHomeMinutes": <number>, "breaks": [ … ] } 注意：出行值以分钟为单位 — 0 = 工作时间之外不出行，120 = 实际上不限。如果用户未提供可用性详情，则输出基线（enableOvertime: false，省略出行键和休息时间）。

---

匹配时间规则 （到达时间窗口） 门槛：仅在需求映射中选中时适用。 询问：“预约是否应遵守客户的到达时间窗口？” 输出：到达时间窗口表中的两条默认规则 — 无需进一步提问。

---

匹配技能 门槛：仅在需求映射中选中时适用。 询问：“资源是否还必须达到最低技能等级（熟练度），还是只需具备该技能即可？” 输出：{ "matchSkillLevel": true|false } 注意：不要询问技能类型的 AND/OR 逻辑 — 此技能不会配置 skillTypeLogic。

---

匹配字段 门槛：仅在需求映射中选中时适用。 询问：“哪个服务预约字段必须与哪个服务资源字段匹配，使用什么运算符？” 输出：{ "serviceProperty": "<SA field>", "resourceProperty": "<resource field>", "booleanOperator": "=" } 注意：运算符为 =, >=, <=, >, < 之一（默认为 =）。字段名称由客户自行定义 — 按原样传递。

---

匹配布尔值 门槛：仅在需求映射中选中时适用。 询问：“资源上的哪个复选框字段必须为真（或假）？” 输出：{ "resourceProperty": "<resource field>", "value": true|false } 注意：每个策略最多设置 5 条匹配布尔值规则。

---

最大居家出行范围 门槛：仅在需求映射中选中时适用。 询问：“上限按距离还是按出行时间计算？”（参见需求映射中的上限类型说明） 输出：{ "maxTravelFromHome": <number>, "maxTravelFromHomeType": "Distance"|"Travel Time" } 注意：距离单位（英里或公里）不属于规则的一部分 — 由组织区域设置决定。对于出行时间，值以分钟为单位。

---

工作区域 门槛：仅在需求映射中选中时适用。 询问：无 — 选中规则即可。 输出：{ "workingLocationEnablePrimary": true } 注意：无需单独询问匹配区域 — 访谈不会输出独立的匹配区域规则。如果需要仅限主要区域或迁移区域的范围，建议手动配置。

---

服务团队资源可用性 门槛：仅在需求映射中选中时适用。 询问：

• “规则是否应评估团队成员个人的可用性和技能，而不仅仅是团队记录？” → considerCrewMembership
• “除基础团队外，最多可以调入多少名额外资源？” → maxAdditionalResources（可选）

输出：{ "considerCrewMembership": true|false, "maxAdditionalResources": <number> }（如果留空，则省略 maxAdditionalResources）

---

扩展匹配 （仅供参考 — 数据层技能不会构建此项） 门槛：仅在需求映射中选中时适用。 询问：无 — 无需收集参数。 建议用户在部署前完成设置：

1. 一个恰好包含两个主从关系（分别指向服务资源和匹配对象）的关联对象 — 打包的触发器要求关系恰好为两个，否则规则将失败
2. 一个用于驱动匹配的服务预约查找字段；关联对象上有一个与其匹配的引用字段
3. 完成上述设置后，在设置中手动创建并配置规则（现场服务设置 → 排程 → 工作规则）

将计划使用的对象/字段记录在 prerequisites 中作为建议文本 — 不要在 workRules[] 中输出。

---

计数规则 门槛：仅在需求映射中选中时适用。 询问：请用户用通俗语言描述限制，然后归类为：

• countBy — "Appointments"（作业数量）、"Hours"（时长上限）或 "Custom"（自定义 SA 字段的总和）
• maxValue — 数值上限（对于 Hours，换算为小时）
• fieldHint — 要汇总的 SA 字段；对于普通的 Appointments 计数，设为 null

输出：{ "countBy": "Appointments"|"Hours"|"Custom", "maxValue": <number>, "fieldHint": "<SA field>"|null } 注意：时间分辨率始终为 Daily；计数对象始终为 Service Appointment。数据层技能会自动设置这两项。每个策略最多可设置 10 条自定义字段计数规则。当 countBy 为 Custom，或 Hours 基于某个字段计数时，添加前置条件：“确认 Service Appointment 上存在字段 <fieldHint>。”

---

仅选择规则（无配置字段 — 每条规则都是一个开关，告知调度器强制执行组织中其他位置定义的约束；在需求映射中选中即可，无需进一步提问）

所需资源 / 排除资源 门槛：仅在需求映射中选中时适用。 输出：{} 前置条件：工作订单 / WOLI 上必须存在 Resource Preference 记录 — 此规则会强制执行这些偏好，但不会创建记录。

工作容量（仅适用于 ESO） 门槛：仅在需求映射中选中时适用。 输出：{} 前置条件：必须在策略之外按区域配置 WorkCapacityLimit 记录。

服务预约访问时段 门槛：仅在需求映射中选中时适用。 输出：{} 注意：不要询问时段 — 它们是 OperatingHours 记录中的账户级数据，而非整个策略的统一值。（不适用相关性组范围限定。） 前置条件：每个账户都必须填写访问时段 / 营业时间；工作订单的访问时段必须能从账户解析得出。

时段指定工作 门槛：仅在需求映射中选中时适用。 输出：{} 注意：不要询问时段到工作的映射 — 这是数据设置。将选项表述为“工作类型”，而不是“Work Type”（指定范围比 Work Type 对象更广）。（不适用相关性组范围限定。） 前置条件：必须配置时段，以指定预期工作。

---

相关性组

相关性组用于限定单条工作规则或服务目标的适用范围，使其仅适用于某些预约或资源，而非整个策略。这样，一个策略就能针对不同的工作类型或资源类型采用不同逻辑 — 例如，为兼职与全职员工设置不同的休息 / 行程限制，或为高价值账户安排优先调度。

工作原理与分工

相关性分组由一个布尔（true/false）字段驱动。Service Appointment 和 Service Territory Member 对象上的所有标准或自定义布尔字段，都可以在规则/目标的 Relevance Group 下拉菜单中选择。在工作规则或目标中，你选择用于限定范围的布尔字段；随后，规则/目标仅适用于该字段为 true 的记录。两种依据只是布尔字段所在的对象不同：

• Service Appointment 依据 — 根据正在评估的预约限定范围（例如，名为“Platinum Account”的公式复选框，当关联账户的等级为 Platinum 时为 true）。用于指定目标预约类型。
• Service Territory Member 依据 — 根据正在评估的资源所属的服务区域成员限定范围（例如，“Part-Time” / “Full-Time”复选框）。用于指定目标资源群体。仅支持主要成员关系和调动成员关系，不支持次要成员关系。

在设计阶段：确定依据（Service Appointment 还是 Service Territory Member）以及用于标识子集的布尔字段名称，然后在构建规范中将两者记录到规则/目标上（relevanceGroup: { basis, booleanField }）。此技能只负责确定哪个字段限定哪个规则/目标的范围；将分组关联到记录是数据层技能的职责。

布尔字段本身是用户必须自行负责的前置条件，不由这对技能中的任何一个创建：创建字段属于架构变更（DDL），而在记录上设置其 true/false 值则需要通过流、公式、触发器或数据加载实现。因此，建议用户在部署前：(1) 在相应对象上为每个子集创建一个自定义布尔字段（资源子集使用 Service Territory Member，工作子集使用 Service Appointment）；(2) 将该子集中的记录恰好设为 true（通过流/公式/导入），并在规则类型有此要求时确保各子集互斥。然后在构建规范中按名称引用该字段，以便数据层技能将其关联为相关性分组。

示例（标准模式）

若要将 Match Boolean 规则（或任何范围限定）仅应用于特定预约类型：在 Service Appointment 上确定（或让用户创建）一个对这些预约为 true 的布尔字段，并在构建规范中将其指定为规则的相关性分组。这样，规则就只适用于该字段为 true 的预约。对 Service Territory Member 布尔字段（例如 Part-Time 与 Full-Time）采用相同模式，可以设计两份 Maximum Travel from Home 规则，分别设置不同的限制——一份限定于兼职人员，另一份限定于全职人员。

对于目标，经典示例是将 ASAP 与相关性分组结合：在预约上创建一个名为“Platinum Account”的公式复选框，再创建一个名为“Expedite Platinum Accounts”的 ASAP 目标，将其限定到该字段并赋予较高权重，从而让白金级账户的工作更早安排（接受更多行程）。为限定范围的高优先级目标设置明显更高的权重，否则引擎可能会因为 ASAP 惩罚而宁愿完全不安排该预约。

将任何规则或目标限定为某个子集（通用规则）

这适用于每项工作规则和每个服务目标，而不仅仅是休息时间或可用性。只要请求表示某条规则或某个目标仅适用于特定资源或特定工作，而非整个策略，就应使用相关性组。留意这一信号，并始终采用这种方式：

• “……适用于某些类型的资源”（例如“法国的资源”“兼职技术人员”“高级工程师”“安装团队”）→ 创建 Service Territory Member 相关性组：在 Service Territory Member 上添加一个布尔字段，对且仅对这些资源设为 true，并将其选作该规则或目标的相关性组。
• “……适用于某些类型的工作”（例如“安装作业”“白金账户预约”“紧急工作订单”“超过 2 小时的作业”）→ 创建 Service Appointment 相关性组：在 Service Appointment 上添加一个布尔字段，对且仅对这些预约设为 true，并将其选作该规则或目标的相关性组。

务必检查具体规则或目标是否支持你需要的依据。并非每条规则或每个目标都能按 Service Territory Member 限定范围，也并非都能按 Service Appointment 限定范围。在建议使用相关性组之前，先核实该具体规则或目标的相关性组支持矩阵——仅考虑 Enhanced Scheduling & Optimization (ES&O) 支持，忽略旧版／非 Enhanced 列。如果 ES&O 下该规则或目标不支持所需依据，请明确说明，并建议最接近的受支持替代方案，而不要凭空编造。

如果两个子集需要对同一规则或目标采用不同配置，请为每个子集分别设计一个实例，绝不要合并为一个实例。单个规则或目标实例会应用于其覆盖的所有记录，因此无法用一个实例表达“法国采用模式 A，其他所有人采用模式 B”。应改为每个子集指定一个实例，各自使用不同的布尔字段进行限定，并确保各组互斥（对于 Service Resource Availability 这类单一覆盖规则类型，重叠会报错——参见 关键规则与注意事项）。例如：“法国的资源在上午 10 点休息 15 分钟，并在 12 点至 2 点之间午餐；其他资源在 12 点至 3 点之间休息 30 分钟”需要两条 Service Resource Availability 规则——“Availability – France” 由 Break_Group_France__c 这个 STM 复选框限定，“Availability – Standard” 由 Break_Group_Standard__c 这个 STM 复选框限定——每条规则只包含其所属组的休息安排，并确保每个资源恰好属于一个组。

如果场景确实过于复杂，请建议采用手动设计。如果请求涉及多个子集、含义不明确的值，以及尚未创建的相关性组字段，不要强行在规范中合并为单个实例。应引导用户按照上述方式设计相关性组，让他们进一步细化（或仅规范明确无误的部分），而不要输出一个看似合理、实际却错误的合并规则或目标。与其猜测，不如优先提出澄清问题（是哪个子集？是资源还是工作？用哪个布尔字段标识各组？ES&O 下该规则或目标是否支持这一依据？）。

关键规则和注意事项

• 相关性组必须互斥。 如果两条规则的相关性组存在重叠，则以限制更严格的规则为准；对于 Service Resource Availability，重叠会导致错误。每项资源必须且只能由一条 Service Resource Availability 规则覆盖。
• 可叠加的规则类型 — 可以多次出现，也可以合理地覆盖相同的资源／预约：Count Rule、Extended Match、Match Boolean、Match Fields、Match Time。
• 单一覆盖规则类型 — 每次最多只能由一个实例覆盖某项资源／预约：Match Skills、Match Territory、Maximum Travel from Home、Required Resources、Service Crew Resource Availability、Service Resource Availability、Working Territories。（另外：不要同时使用 Match Territory 和 Working Territories 覆盖同一项资源。）
• 必须整体应用的规则——不使用相关性组： TimeSlot Designated Work 和 Service Appointment Visiting Hours。此外，Work Capacity 不支持相关性组。
• 目标也可以重复并使用相关性组，但同一条记录不能同时满足同一类型中两个目标的条件——Resource Priority 除外；如果每个实例指向不同的资源优先级字段（例如「Primary Priority」和「Secondary Priority」／「Tenure」），则可以合理地让同一批预约同时适用两次。
• Enhanced 和 non-Enhanced 引擎对于规则／目标能否按预约或区域成员进行范围限定的支持各不相同——设置范围时请核对支持表。Group Nearby 和 Same Site 目标完全不支持相关性组。

---

输出

确认所有规则后，输出 workRules[] 块，并提供通俗易懂的摘要——包括规则名称、筛选内容和任何关键参数。委派前请让用户确认。

传递到下一步的 workRules[] 块：

{
  "workRules": [
    {
      "type": "<rule type>",
      "name": "<policy name> - <rule label>",
      "mandatory": true | false,
      "params": { ... },
      "relevanceGroup": { "basis": "ServiceAppointment" | "ServiceTerritoryMember", "booleanField": "<field API name>" } | null
    }
  ],
  "prerequisites": [ "<advisory text for items the user must set up manually>" ]
}

---

交接

用户确认工作规则后，将任务委派给 sfs-service-objective-designer。将 policy 块和 workRules[] 块都作为上下文传递——目标设计器会根据所选规则，提供相关目标建议（例如，选择了 Match Skills → 建议 Skill Level 和 Skill Preference 目标）。

不要在此处开始服务目标访谈。过渡消息：

「工作规则已确定。下一步：服务目标——用于给符合条件的候选项排序的评分标准。我会一次带你讨论一个权衡问题。」