service-itsm-agentic-setup-incident-sla-configure

配置 Incident SLA（端到端）

**向用户提问前的第一步：**使用 dispatch_readonly 调用 GET /services/data/v68.0/connect/setup/discovery/features，读取 IT Service Enablement 门槛（Phase 1a），并筛选精确的 apiName service-cloud-itsm-setup。在其状态变为 ENABLED 之前，不要询问其他内容。

为 Service Cloud ITSM 配置完整的 Incident SLA 流水线——为每个具备 Entitlement 的 Incident 衍生 EntityMilestone（包含计算得出的 TargetDate）。所有操作均通过由 Salesforce 托管的 headless-360 MCP 服务完成（组织来自 OAuth JWT）。要求启用组织级别的 IT Service Management（Phase 1a 门槛）和 SLA Management for IT Service 设置项（Phase 1c 门槛），以及 Incident Management（Phase 1b 门槛）。 自定义流水线包含四项按序写入：MilestoneType（衡量内容）→ SLA Policy（SlaProcess，限定 Incident，创建时处于非活动状态，并设置进入／退出条件）→ Milestone（时间触发条件和判定条件）→ 激活策略（createEntitlement=true，自动配置 Entitlement——匹配的 Incident 随后通过 EntitlementId 按每个 Incident 应用 SLA，且无需 Account）。组织范围的自动应用 entitlement criterion 是可选的第五项写入，仅在明确要求始终匹配时才派发（Phase 4A 步骤 6），绝不默认执行。（预定义／OOB 种子分支有所不同——无需手动完成上述操作：一次种子调用即可一次性配置整个启用状态的套件，包括策略、里程碑和 Entitlement；参见 Phase 2／Phase 4B。） 此技能负责所有 Incident SLA 交互（门槛、分支、里程碑策略、验证）；原始写入操作则委派给获批的 SLA 叶级能力（csp-sun/MilestoneTypes、create-sla-policy、create-milestone、create-milestone-action、activate-sla-policy、create-entitlement-criteria），由它们负责获批的 Connect 契约——每项操作都应先发现、再描述、然后派发，不要在此重新推导其结构。 Phase 1c 的启用（+ 版本控制）以及 Phase 4B 的种子写入委派给 itsm-shakti/SLASettings（负责 SLA Management 设置界面）——同样遵循发现 → 描述 → 派发。

范围

• 范围内：上述 SLA 制品（MilestoneTypes、SLA Policy 及其里程碑、激活时自动配置的 Entitlement，以及——仅在明确要求组织范围始终匹配时——可选的自动应用判定条件）+ 验证 Incident 记录上的 SLA 应用情况；设置 SLA Management for IT Service 门槛（Phase 1c）；提供 OOB Standard Support for Incidents 策略或自定义策略供选择（仅限 Incident，Phase 2）——全部通过 headless-360 MCP 服务完成。
• 范围外：Case SLA／Entitlement；Assignment Rules；Escalation Rules；Notification Rules；与 Incident SLA 无关的一般 Entitlement CRUD；SLA 报告。

---

输出约定 — 适用于每条消息

绝不要在任何面向用户的文本中打印原始 Salesforce 记录 ID（15/18 位：55…、550…、0ny…、00…、Account 001…）——完整或掩码处理后都不行（557VW…R3XVYA0 仍会泄露），包括过程叙述和最终报告。此规则适用于你创建的项目和你检测到/复用的项目——逐一使用其名称（创建时提供的名称，或复用时匹配到的名称），将其 ID 保留在内部（仅用于串联操作）。通过 SOQL 验证或匹配？报告已验证的属性/名称，绝不报告你用于查询的 ID。查找 ID 也适用同一规则——解析 Business Hours（在 Phase 4A 第 1 步中解析、由用户选择或创建）或现有策略时会返回 {Id, Name}；叙述时只写解析出的名称，并将返回的 ID 保留在内部——绝不要回显为 Resolved "<name>" (001VW…)。唯一例外：暂停时可以原样转述原始错误正文，即使其中包含 ID 也可以——不要手动编辑。

• 错误： SLA policy created (552VW…) · Incident created (0ny…) · First Response → 557VW…R3XVYA0（复用）
• 正确： Created SLA policy "Standard Support for Incidents" · reusing the existing First Response milestone type · 在 Phase 6 之前，测试 Incident 称为 "the test Incident"；之后使用其 IncidentNumber；里程碑使用 MilestoneType 名称。

---

路由速览

读取 → mcp__headless-360__dispatch_readonly，写入 → mcp__headless-360__dispatch。两者都接收原始 HTTP {"url","method","body"?,"query_params"?}，而不是 {operation_id, arguments}；从 {status_code, body} 中读取 body。包含请求/响应结构的完整路由表：references/mcp-invocation.md。

---

澄清问题

只询问无法从上下文推断的信息（预先填写；注明“(from conversation)”）。**先解决 Phase 1a 门槛，再解决 Phase 1b Incident Management 门槛，最后解决 Phase 1c 门槛，必须按此顺序。**然后询问：（headless-360 绑定到当前 OAuth 会话，因此不要询问使用哪个 org）；里程碑策略？（Phase 3b）；里程碑条件？（默认使用 Status != Closed + 特定模式的筛选条件）。不要询问 Account——Incident 没有 Account 字段；engagement 按 Incident 通过 EntitlementId 关联。**Business Hours：**仅当用户的选择不明确或 org 中没有 Business Hours 时才询问（Phase 3a 第 4 步）；Predefined 路径上绝不询问。

默认建议：SLA Policy Incident SLA Policy；建议的默认 Business Hours（在 Phase 3c 确认）；激活时自动配置 Entitlement（无 Account）；engagement 按 Incident 通过 EntitlementId 关联；按 Phase 3b 确定里程碑策略。

---

工作流

按顺序执行——始终先读后写；每次调用都通过 mcp__headless-360__*。 各阶段的详细信息（读取、委派写入、API 特性）见 references/workflow.md——执行前先阅读。 阶段索引及其不可妥协的门槛：

• 开始前——仅复用会话状态，且该状态必须来自本会话中针对此组织成功执行的 dispatch_readonly，之后未被写入；用户的陈述永远不符合缓存复用条件。
• 阶段 1a——IT 服务管理门槛（service-cloud-itsm-setup）。状态精确为 ENABLED 才能继续。 状态精确为 NOT_ENABLED 且无阻止原因 → 通过 AskUserQuestion 询问“IT Service Enablement is off — enable it now?”（是/否，绝不使用纯文本提问；选否则停止）→ 在获得确认后委派给 IncidentMgmt SOR → 继续前执行其验证步骤。缺失、错误、受阻或任何其他状态均停止并指向 Setup。
• 阶段 1b——事件管理门槛（service-cloud-itsm-incident）。状态精确为 ENABLED 才能继续；NOT_AVAILABLE → 停止；状态精确为 NOT_ENABLED 且无阻止原因 → 通过 AskUserQuestion 单独询问“Incident Management is off — enable it now?”（是/否），委派给 IncidentMgmt SOR（使用 MCP 步骤，绝不使用 Skill），并验证状态精确为 ENABLED；选否则停止。
• 阶段 1c——SLA 管理门槛。 SLA 管理和永久 SLA 版本控制开关——两项写入；委派给 itsm-shakti/SLASettings。先读取两个标志。如果任一项关闭，必须在任何写入前通过 AskUserQuestion 询问，且分成两个单独的问题：Q1“SLA Management for IT Service is off — enable it now?”（是/否；仅当 SLA 管理关闭时询问），然后是 Q2 SLA 版本控制永久生效确认（启用 / 停止；确切措辞见 references/mcp-invocation.md）。绝不合并这两个问题，绝不在每个问题得到回答前预览后续步骤，也绝不将阶段 1a/1b 中的“是”或原始请求视为同意；任何“否”均停止。
• 阶段 2——预定义还是自定义（仅限事件）。先检测预置策略；在分支判断前读取实时的 Incident.Priority 选项列表（存在自定义值时 → 建议选择自定义）；如果优先级矩阵关闭则发出警告（仅默认级别会触发）；仅当用户指定了时段时才说明营业时间。预定义 → 4B → 5（如果有要求）→ 6 → 停止； 自定义 → 3a → 3b → 3c → 4A → 5（如果有要求）→ 6。
• 阶段 3a——预检。 步骤 1 仅复用阶段 1b 的事件管理结果；然后对 SLA 操作执行 discover/describe、执行 Incident describe、解析营业时间、进行幂等性探测。不涉及 Account。遇到 401/403/404 → 停止并提供原始错误。
• 阶段 3b——里程碑策略，遵循 examples/milestone-patterns.md。
• 阶段 3c——确认完整计划（按名称列出营业时间和每个里程碑），然后才能进行任何写入。
• 阶段 4A——创建（如有计划，先创建营业时间，即步骤 1）→ MilestoneTypes → create-sla-policy → create-milestone ×N → activate-sla-policy；仅在用户明确要求始终匹配时，才可添加可选的步骤 6 条件。
• 阶段 4B——通过 save-selected-options（{"selectedOptions":["incident"]}）植入预设，委派给 itsm-shakti/SLASettings；验证并命名其营业时间。
• 阶段 5——里程碑操作（仅在用户要求时），应用于每个已命名的里程碑。
• 阶段 6——通过 SOQL 和非最低级别的测试 Incident（含 EntityMilestone）进行验证；如果矩阵关闭或重试一次后仍为 order-1 → 停止并报告其他级别尚未检查。

---

规则 / 约束

约束	理由
先启用 IT 服务管理（Phase 1a），再启用 Incident Management（Phase 1b，单独询问 Yes/No），然后才能进入 Phase 1c——只能使用精确的 apiNames，绝不可使用相似项；规则见上方阶段列表	更高层级的组织门控位于所有 ITSM 功能之上
首先启用 SLA Management（Phase 1c）——分两次单独写入（先写入 SLA Management，再写入单向的 SLA Versioning）；写入前必须分别调用两次 AskUserQuestion（Q1：SLA Management Yes/No，然后 Q2：是否接受永久生效）——绝不可合并提问，也不可根据此前门控的 Yes 推断同意；拒绝／受阻／验证失败 → HALT；重新读取并报告真实状态	Versioning 不可逆；写入操作无法确认状态
首先提供预定义（OOB）选项（Phase 2，仅限 Incident）；先检测，再进行初始化；若选择此项，则初始化 → 验证 → STOP（不得追加推销自定义方案）	OOB 初始化不是幂等操作——重复初始化会产生重复项
任何变更前先执行 discover + describe	尽早发现 SLA 功能不可用或 Incident Mgmt 已禁用
询问（AskUserQuestion）里程碑策略；绝不可默认选择 Single	实际 ITSM 策略通常有多个里程碑
共享名称复用同一个 MilestoneType；不同关注点使用不同的 MilestoneType	运行时通过 MilestoneType 为里程碑编制键值
多里程碑：任何里程碑创建失败都必须停止（不得附加不完整的策略）	部分附加会偏离已确认的计划
按优先级分层：派发前必须将每个 Priority 值与实时选项列表核对——删除或重命名不匹配的标准行，并为组织新增的每个自定义活动值添加一个里程碑	服务端接受任意字符串 → 未知值会成为无效里程碑；自定义值若没有里程碑，则不会获得 SLA
所有由本技能负责的写入都必须委派——前置功能启用委派给 IncidentMgmt SOR；SLA 写入委派给获准的 SLA 叶节点（MilestoneTypes、create-sla-policy、create-milestone、create-milestone-action、activate-sla-policy、create-entitlement-criteria）。Phase 4A 第 1 步的 Business Hours 创建仍内联执行，因为没有受服务的 SOR 负责此项	每次写入只由一个合约所有者负责；在此处重新推导由所有者负责的合约，会偏离其受服务的所有者
Business Hours（自定义）：遵循指定名称的时间表、所描述的日历或时区（仅指定时区时，询问选择 24×7（推荐）还是自定义营业时间；复用匹配项，否则在 Phase 3c 确认后创建一个）；若没有活动项，则提供创建 24×7 项的选项。绝不设置 IsDefault，也不修改现有记录。预定义方案：初始化程序始终使用组织默认项——仅在用户指定营业时间时发出警告	使用默认的 24×7 时段或客户自己的日历；BusinessHours 无法通过 API 删除，因此创建前必须确认
自定义流程：激活会创建自动 Entitlement（activate-sla-policy：将 isActive + createEntitlement 作为 QUERY 参数）——匹配的 Incident 随后通过 EntitlementId 按 Incident 生效（不是手动创建 sObject Entitlement，也不需要 Account）。通过 create-entitlement-criteria 设置组织范围的自动应用条件是可选项——仅在明确要求始终匹配时设置，绝不默认设置。OOB 初始化路径：调用一次初始化程序（save-selected-options，selectedOptions 小写）即可配置整个活动套件，包括 Entitlement——不逐个调用叶节点，不手动执行 POST /sobjects/Entitlement，也不执行 activate PATCH	自定义流程：一次调用即可激活并配置，因此手动执行 POST /sobjects/Entitlement 会造成重复。OOB：平台初始化程序在服务端构建并激活整个默认套件，因此技能既不逐个重建叶节点，也不手动配置 Entitlement
任何消息中都不得包含记录 Id（见输出约定，包括复用的产物）；AskUserQuestion 标签须面向客户（不得使用“demo”／内部默认值）	泄露 Id／使用内部措辞会显得不专业
若已有另一项 Incident 策略处于活动状态且用户选择自定义方案 → 仅说明两者共存。自定义策略通过 EntitlementId 按 Incident 指定目标（Incident 没有可用于限定范围的 Account 字段），且是附加策略；现有（预定义／广泛适用的）策略仍是组织范围的策略。无论在分支流程还是结束报告中，都绝不可提议、计划或执行停用现有策略、重新排序其 entitlement 条件、扩大自定义策略范围以匹配所有项／自动应用于所有项，或“决定／解决各策略之间的优先级”。通过 EntitlementId 指定目标 Incident；现有策略保持活动状态（见 references/workflow.md → Coexistence）	修改用户未要求处理的策略超出范围——此技能负责配置一项与现有策略共存的新自定义策略，而非修改现有策略。停用（activate-sla-policy 可以发送 isActive=false）或重新排列另一项策略的条件，可能扰乱正在生效的 SLA；并且没有任何叶节点会裁定跨策略优先级（预定义策略：无法撤销初始化，只能手动删除）。两者本应共存——否则 Agent 可能会擅自提出超出范围的停用／重新排序／优先级方案
其他 API 特殊情况：references/mcp-invocation.md。

---

验证清单

• IT Service Management 启用门控（Phase 1a）——读取精确的 apiName service-cloud-itsm-setup，状态必须恰为 ENABLED；或者状态恰为 NOT_ENABLED 且未收到任何阻止原因时，向 IncidentMgmt SOR 委派一个 Yes/No 启用问题，并由其验证步骤确认状态恰为 ENABLED；拒绝、受阻、缺失、错误或意外状态 → 在 Phase 1b 之前 HALTED。
• Incident Management 启用门控（Phase 1b）——通过实时读取确认状态恰为 ENABLED；或者在状态为 NOT_ENABLED 时，在其自身的 Yes/No 问题之后委派给 IncidentMgmt SOR（NOT_AVAILABLE → HALT）；其验证步骤确认状态为 ENABLED——不能是用户声称的状态，也不能是看似相同的状态。
• SLA Management 启用门控（Phase 1c）——SLA Management 和 SLA Versioning 均已启用（分两次单独写入），且只能在 Q1（SLA Management Yes/No）和单独的 Q2 永久性确认之后启用；两项都通过 AskUserQuestion 询问。报告的状态必须来自重新读取，而不是写入结果。拒绝／受阻／验证失败 → 在 Phase 2/3a 之前 HALTED，不创建任何工件。
• 已提供预定义与自定义选项（Phase 2）——功能启用后，首先提供 OOB Standard Support for Incidents；若其已存在，则报告但不重新植入；若用户选择，则植入（2 个 MilestoneType + 6 个里程碑 + Entitlement），完成验证后，不得再提供自定义选项。
• discover/describe 已确认 SLA Connect 操作。
• Incident describe 返回 200，且包含 EntitlementId、SlaStartDate、SlaExitDate。
• 已解析活动 Business Hours，并在已确认的计划中按名称注明——用户指定的日程／匹配的日历／组织默认值／用户选择的记录，或者在 Phase 3c 确认创建（使用已描述的日历；若不存在则使用 24×7），然后通过 SOQL 验证其处于活动状态。预定义方案：按名称报告植入策略的 Business Hours（或“none”）。
• 已确定里程碑策略——满足 Phase 3b 跳过条件，或已使用 AskUserQuestion 询问；Priority 分层／Custom 方案在分派前，已根据实时选项列表核对每个 Priority/条件值（删除／重命名不匹配的标准行，并为每个自定义的活动 Priority 值添加一个里程碑）。
• 已确认配置或满足跳过条件（预先完成身份验证／无操作／此前已确认／“yes”）；在 Phase 4A 之前已口头说明已确定的计划（组织、SLA 名称、按名称注明的 Business Hours、参与模式 = 每个 Incident 通过 EntitlementId（不使用 Account）、逐个里程碑列表）。
• 按顺序将写入操作委派给 SLA 叶节点——四项核心写入：MilestoneType(s) → Policy → Milestone(s) → 激活 + 自动 Entitlement（只有在明确要求时才添加可选的组织范围自动应用条件）；任何里程碑创建失败都必须停止（不得部分关联）。无操作时视为简单完成。
• 里程碑操作（Phase 5）——如有要求，附加到每个已命名的里程碑；每项都根据 body.success + actionMappings 确认，而不是依据 201；写入前口头说明完整集合。
• 通过 SOQL 验证 SLA Policy，而非依赖创建响应（无操作时，Phase 3a 的读取即为验证）。
• 测试 Incident 至少有一个 EntityMilestone，且其位于正确层级并带有 TargetDate（参与证明；Priority 分层方案中须匹配 Priority）；预期的里程碑均已存在。若 Matrix 关闭／重试一次后仍为 order-1，则报告“未检查其他层级”并指明 Setup 中的 Priority Matrix 设置，不要反复重建。SlaStartDate 已填充也可作为确认依据，但 Entitlement 通过条件自动应用时，该字段可能为 null——这不算失败。无操作时跳过。
• 任何消息中都不得包含记录 Id——包括过程说明和最终报告；工件用名称指代，测试 Incident 用 IncidentNumber 指代（参见 Output contract）。
• 已显示前后状态及摘要；无操作时须逐字说明现有配置，并注明“未做任何更改”。

---

输出格式

使用 examples/output-templates.md 中的模板；占位符按原样填写。成功报告必须明确包含：SLA Policy；按 MilestoneType 名称 + 时间 + 条件列出每个里程碑；Entitlement（自动配置，不需要 Account——Incident 没有 Account 字段）；按里程碑层级/MilestoneType 名称（绝不能使用里程碑 Id）+ Warning/Violation 角色 + 偏移量 + 确认方式列出每项请求的操作；一个 Verification 部分（通过 SOQL 确认策略，以及测试 Incident 的 SlaStartDate/EntityMilestones，或如实说明部分完成）；每项产物是新建还是复用；一条范围说明（仅 Incident SLA）。不得出现任何记录 Id。如果已有其他 Incident 策略处于启用状态，请明确说明它们并存（两者均保持启用；现有/预定义策略仍是适用于整个组织的广泛策略；自定义策略通过 EntitlementId 针对特定 Incident），并且不得提议停用或重新排序该策略、将自定义策略扩大为自动应用于所有 Incident，或“决定”不同策略之间的优先级。

---

参考文件索引

文件	何时阅读
references/workflow.md	执行时——Phase 1–6 的完整逐步说明（每个阶段的读取、委派写入、API 特性）；约束表和验证清单保留在此 SKILL.md 正文中
references/mcp-invocation.md	每个阶段——调用形式、模板、响应信封、发现、注意事项
examples/milestone-patterns.md	Phase 3b——五种策略：时间、条件、复用 MilestoneType、筛选器扩展
assets/attach-milestone.json	Phase 4A 步骤 4——里程碑 POST 正文；替换 ids/timeTrigger/order；追加 filterItems
assets/attach-milestone-action.json	Phase 5——Warn/Escalate 操作正文模板（字段更新）；结合 mcp-invocation.md（里程碑操作）使用
examples/output-templates.md	输出格式——成功/部分完成报告模板；填写占位符，不得包含记录 Id

---

相关技能

优先级矩阵（Impact × Urgency → Priority）单独配置，此处不配置； 如果请求了按 Priority 分层的策略，但 Incident.Priority 没有值，请先引导用户前往 Setup 中的 Priority Matrix 设置。其他 ITSM 工作流（Major Incident Mgmt、自定义字段）不在范围内。