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

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Configuring Incident SLA (End-to-End)

事件SLA端到端配置

Configures a complete Incident SLA pipeline for Service Cloud ITSM — the chain that derives an EntityMilestone (with a computed TargetDate) on every Incident that has an Entitlement. Every operation runs through the Salesforce-hosted Headless-360 MCP server (server key

headless-360

) via its four meta-tools (

discover

describe

dispatch_readonly

dispatch

). The org is derived from the OAuth JWT — the skill never handles an org id, alias, or credentials. It also needs the org-level SLA Management for IT Service setup item — a Setup Discovery feature plus a separate, permanent SLA Versioning bit, both gated by Phase 0.5. Setup has four parts:

MilestoneType — define what you're measuring (e.g., "First Response").
SLA Policy — the SlaProcess scoped to Incident with entry/exit criteria.
Milestone — attach to the policy with a time trigger and filter criteria.
Entitlement — wire to an Account so Incidents with that Entitlement engage the SLA.

为Service Cloud ITSM配置完整的事件SLA流程——为每个关联了Entitlement的事件生成带有计算得出的TargetDate的EntityMilestone的链路。所有操作均通过其四个元工具（

discover

、

describe

、

dispatch_readonly

、

dispatch

）在Salesforce托管的Headless-360 MCP服务器（服务器密钥

headless-360

）上执行。组织信息由OAuth JWT获取——本技能从不处理组织ID、别名或凭据。此外，还需要组织级别的SLA Management for IT Service配置项——这是一个Setup Discovery功能，加上一个独立的永久SLA Versioning开关，两者均受Phase 0.5限制。配置分为四个部分：

MilestoneType — 定义要衡量的内容（例如：“首次响应”）。
SLA策略 — 限定为事件范围的SlaProcess，包含进入/退出条件。
Milestone — 关联到策略，包含时间触发器和过滤条件。
Entitlement — 关联到客户账户，使带有该Entitlement的事件触发SLA。

Scope

范围

In scope: Creating MilestoneTypes, SLA Policies (SlaProcess), Milestones with criteria, Entitlements, and verifying SLA engagement on Incident records — all via
```
headless-360
```
MCP.
In scope — prerequisite: checking and (on confirmation) enabling the SLA Management for IT Service setup item — the feature + SLA Versioning (Phase 0.5).
Out of scope: Case SLA/entitlements; Assignment Rules; Escalation Rules; Notification Rules; general Entitlement CRUD not related to Incident SLA; SLA reporting.

包含范围：通过
```
headless-360
```
MCP创建MilestoneType、SLA策略（SlaProcess）、带条件的Milestone、Entitlement，并验证事件记录上的SLA触发情况。
包含范围——前置条件：检查并（经确认后）启用SLA Management for IT Service配置项——该功能加上SLA Versioning（Phase 0.5）。
排除范围：Case SLA/权益；分配规则；升级规则；通知规则；与事件SLA无关的通用Entitlement CRUD操作；SLA报告。

Routes at a glance

路由概览

Reads dispatch through

mcp__headless-360__dispatch_readonly

, writes through

mcp__headless-360__dispatch

. Both take raw HTTP:

{"url": "<path>", "method": "GET|POST|PATCH|...", "body"?: {...}, "query_params"?: {...}}

— not

{operation_id, arguments}

. Full request/response shapes live in

references/mcp-invocation.md

Concern	Method + path	Body
Master Incident Mgmt pref (read)	`GET /services/data/v67.0/connect/setup/discovery/features` , filter `apiName == "service-cloud-itsm-incident"` for `status`	—
SLA Mgmt prerequisite (Phase 0.5)	Feature `status` / `enable` + SLA Versioning read/PATCH on `EntitlementSettings` — see `references/mcp-invocation.md`	see ref
Preflight (Incident on)	`GET /services/data/v67.0/sobjects/Incident/describe`	—
Default BusinessHours	`GET /services/data/v67.0/query` (q via `query_params.q` )	—
Create MilestoneType	`POST /services/data/v67.0/connect/sla-management/milestone-types`	`{"name","description","recurrenceType"}`
Create SLA Policy	`POST /services/data/v67.0/connect/sla-management/sla-policies`	`{"name","processType":"Incident","businessHourId",...}`
Attach Milestone	`POST /services/data/v67.0/connect/sla-management/sla-policies/<id>/milestones`	`{"milestoneTypeId","timeTrigger","milestoneCriteria":[...]}`
Create Entitlement	`POST /services/data/v67.0/sobjects/Entitlement`	`{"Name","AccountId","SlaProcessId","BusinessHoursId","StartDate","EndDate"}`
Create test Incident	`POST /services/data/v67.0/sobjects/Incident`	`{"Subject","EntitlementId",...}`
Verify SLA policy	`GET /services/data/v67.0/query` (q for `SlaProcess` )	—
Verify engagement	`GET /services/data/v67.0/query` (q for `EntityMilestone` )	—

Response envelope: SLA Management Connect,

/sobjects/…

, and

/query

are standard REST — the

dispatch*

MCP tool returns the REST response directly (

{status_code, body}

); read

body

. Only

/headless/invoke/…

Aura-controller routes are doubly wrapped (

body.body

) — this skill uses none.

通过

mcp__headless-360__dispatch_readonly

执行读取操作，通过

mcp__headless-360__dispatch

执行写入操作。两者均接受原始HTTP请求：

{"url": "<path>", "method": "GET|POST|PATCH|...", "body"?: {...}, "query_params"?: {...}}

— 不支持

{operation_id, arguments}

格式。完整的请求/响应结构请参考

references/mcp-invocation.md

。

关注点	请求方法 + 路径	请求体
事件管理主偏好（读取）	`GET /services/data/v67.0/connect/setup/discovery/features` ，过滤 `apiName == "service-cloud-itsm-incident"` 获取 `status`	—
SLA管理前置条件（Phase 0.5）	功能 `status` / `enable` + 在 `EntitlementSettings` 上读取/更新SLA Versioning——详见 `references/mcp-invocation.md`	参考文档
预检（事件功能已启用）	`GET /services/data/v67.0/sobjects/Incident/describe`	—
默认营业时间	`GET /services/data/v67.0/query` （查询语句通过 `query_params.q` 传递）	—
创建MilestoneType	`POST /services/data/v67.0/connect/sla-management/milestone-types`	`{"name","description","recurrenceType"}`
创建SLA策略	`POST /services/data/v67.0/connect/sla-management/sla-policies`	`{"name","processType":"Incident","businessHourId",...}`
关联Milestone	`POST /services/data/v67.0/connect/sla-management/sla-policies/<id>/milestones`	`{"milestoneTypeId","timeTrigger","milestoneCriteria":[...]}`
创建Entitlement	`POST /services/data/v67.0/sobjects/Entitlement`	`{"Name","AccountId","SlaProcessId","BusinessHoursId","StartDate","EndDate"}`
创建测试事件	`POST /services/data/v67.0/sobjects/Incident`	`{"Subject","EntitlementId",...}`
验证SLA策略	`GET /services/data/v67.0/query` （查询 `SlaProcess` ）	—
验证触发情况	`GET /services/data/v67.0/query` （查询 `EntityMilestone` ）	—

响应包：SLA Management Connect、

/sobjects/…

和

/query

均为标准REST接口——

dispatch*

MCP工具直接返回REST响应（

{status_code, body}

）；读取

body

即可。仅

/headless/invoke/…

Aura控制器路由会被双重封装（

body.body

）——本技能不使用此类路由。

Clarifying Questions

澄清问题

Ask only what you cannot infer from conversation context (pre-populate and note "(from conversation)"). Resolve the Phase 0.5 gate first, on its own.

Which org?
```
headless-360
```
binds to the current OAuth session; confirm the target before mutating.
Milestone strategy? See Phase 1.4 — skipped when the prompt already names a shape, when the branch is a no-op, or when up-front authorization + a derivable shape are given.
Target Account? Account to attach the Entitlement to.
Milestone criteria? Default
```
Status != Closed
```
, plus pattern-specific filters.

Default suggestion: SLA Policy

Incident SLA Policy

, default BusinessHours, first active Account, Entitlement

today → today + 1 year

, milestone strategy resolved per Phase 1.4.

仅询问无法从对话上下文推断的问题（预先填充并标注“(来自对话)”）。首先单独解决Phase 0.5限制。

目标组织？
```
headless-360
```
绑定到当前OAuth会话；在执行变更前确认目标组织。
里程碑策略？ 详见Phase 1.4——当提示已明确指定结构、分支为无操作，或已预先授权且可推导结构时，跳过此步骤。
目标账户？ 要关联Entitlement的客户账户。
里程碑条件？ 默认条件为
```
Status != Closed
```
，加上特定场景的过滤规则。

默认建议：SLA策略名称为

Incident SLA Policy

，使用默认营业时间，选择第一个活跃账户，Entitlement有效期为

今日 → 今日+1年

，里程碑策略按Phase 1.4规则确定。

Workflow

工作流程

All steps are sequential. Always read before you write. Every call goes through

mcp__headless-360__*

tools.

所有步骤按顺序执行。始终先读取再写入。 所有调用均通过

mcp__headless-360__*

工具完成。

Phase 0 — Reuse what the session already knows

Phase 0 — 复用会话已有的信息

Each Phase 1 read below carries a skip-if-already-known clause: skip only when the same fact was produced this session from a successful
dispatch_readonly
response tied to the current org. A user statement is not cache-eligible — a mistaken assertion would produce a stale create. When the only source is a user statement, re-read.

Master Incident Management pref — reuse only when the pref was read live this session (successful
```
dispatch_readonly
```
on Setup Discovery, or a live read by
```
service-itsm-incident-mgmt-configure
```
) AND
```
status
```
was
```
ENABLED
```
AND no write since. A cached "not enabled" / unknown / user-asserted value is NOT cache-eligible — fall through to step 1.
SLA Management feature + SLA Versioning — reuse only if both were read live this session (Phase 0.5) and unwritten since; else re-run Phase 0.5.
Incident describe / SLA-field presence — if
```
Incident.describe
```
was already run against the current org this session and the presence of
```
EntitlementId
```
/
```
SlaStartDate
```
/
```
SlaExitDate
```
is in context, skip step 3 and reuse the answer.
Default BusinessHours id — if a
```
BusinessHoursId
```
for the current org's default is already captured, skip step 4.
Account id — if the Account the user named (or the fallback first-active Account) was already resolved to an
```
Id
```
this session, skip step 5.
Discover / describe of SLA Connect operations — if the routes were already verified as indexed this session, skip step 2.

When in doubt, re-check. Skip only when the earlier fact is unambiguously in context AND you have not switched orgs — the

headless-360

MCP session binds to one org via the JWT, so an org change is only possible if the session was re-authed mid-conversation. If the user hints at a different org, or you cannot tell which org the earlier fact came from, re-run the read. A wrong skip on a live org write is worse than a duplicated read.

以下每个Phase 1的读取操作均带有已知则跳过的规则：仅当本次会话中通过针对当前组织的成功

dispatch_readonly

响应获取到相同信息时，才跳过该步骤。用户陈述不纳入缓存——错误的断言会导致过时的创建操作。若信息仅来自用户陈述，需重新读取。

事件管理主偏好 — 仅当本次会话中通过Setup Discovery的
```
dispatch_readonly
```
或
```
service-itsm-incident-mgmt-configure
```
的实时读取确认
```
status
```
为
```
ENABLED
```
，且之后未执行写入操作时，才可复用。缓存的“未启用”/未知/用户断言的值不可复用——需执行步骤1。
SLA管理功能 + SLA Versioning — 仅当本次会话中（Phase 0.5）已实时读取两者且之后未执行写入操作时，才可复用；否则重新执行Phase 0.5。
事件描述 / SLA字段存在性 — 若本次会话中已针对当前组织执行过
```
Incident.describe
```
，且上下文已确认
```
EntitlementId
```
/
```
SlaStartDate
```
/
```
SlaExitDate
```
存在，则跳过步骤3并复用结果。
默认营业时间ID — 若本次会话中已获取到当前组织的默认
```
BusinessHoursId
```
，则跳过步骤4。
账户ID — 若本次会话中已将用户指定的账户（或默认的第一个活跃账户）解析为
```
Id
```
，则跳过步骤5。
SLA Connect操作的发现/描述 — 若本次会话中已验证路由已被索引，则跳过步骤2。

存疑时重新检查。 仅当之前的信息明确存在于上下文且未切换组织时，才可跳过——

headless-360

MCP会话通过JWT绑定到单个组织，因此仅当会话中途重新授权时才可能切换组织。若用户暗示切换组织，或无法确定之前信息所属的组织，需重新执行读取操作。错误跳过导致的组织写入错误，比重复读取的影响更严重。

Phase 0.5 — SLA Management for IT Service prerequisite gate

Phase 0.5 — SLA Management for IT Service前置条件限制

Resolve this gate on its own first — not batched with the clarifying questions. Its reads are safe to run up front; still confirm the target org before the enable write. Gate on the org-level SLA Management for IT Service setup item before any Phase 2 mutation — two independent bits: the Setup Discovery feature

service-cloud-itsm-manage-sla-policies

(Connect route, not Tooling) and the separate, permanent SLA Versioning bit (

EntitlementSettings.IsEntitlementVersioningEnabled

). Full call shapes,

enableBlockedReasons

handling, and the permanence rule are in

references/mcp-invocation.md

Read both (
```
dispatch_readonly
```
); feature
```
ENABLED
```
and versioning
```
true
```
→ skip to Phase 1.
Confirm, then enable only what's off (
```
AskUserQuestion
```
) — stop and relay if
```
enableBlockedReasons
```
is non-empty; if versioning is off, flag it's permanent.
Enable, then re-read — never trust the
```
201
```
/ empty-
```
204
```
write response; require
```
ENABLED
```
/
```
true
```
first.

首先单独解决此限制——不要与澄清问题批量处理。其读取操作可安全地提前执行；但在执行启用写入操作前仍需确认目标组织。 在执行任何Phase 2变更前，需满足组织级别的SLA Management for IT Service配置项要求——两个独立的配置：Setup Discovery功能

service-cloud-itsm-manage-sla-policies

（Connect路由，非工具类）和独立的永久SLA Versioning开关（

EntitlementSettings.IsEntitlementVersioningEnabled

）。完整的调用结构、

enableBlockedReasons

处理规则和永久开关规则请参考

references/mcp-invocation.md

。

读取两者（
```
dispatch_readonly
```
）；功能状态为
```
ENABLED
```
且版本开关为
```
true
```
→ 跳过至Phase 1。
确认后仅启用未开启的项（
```
AskUserQuestion
```
）——若
```
enableBlockedReasons
```
非空，停止操作并告知用户；若版本开关未开启，需标注其为永久设置。
启用后重新读取——永远不要信任
```
201
```
/空
```
204
```
的写入响应；必须先确认状态为
```
ENABLED
```
/
```
true
```
。

Phase 1 — Preflight & discovery

Phase 1 — 预检与发现

On any
401
/
403
/
404
from a step below, halt and surface the raw error — the org or client is not configured correctly.

→ MCP auth (ECA not propagated / expired token).

→ user perm missing OR ITSM Incident Management license/preference missing (

ITSMIncidentMgmtEnabled

IncidentMgmt.orgHasITSMOrgPermission

→

headless-360

server not activated OR Entitlement Management not enabled for Incident.

Master Incident Management pref — direct read (skip conditions in Phase 0).
```
dispatch_readonly
```
on
```
GET /services/data/v67.0/connect/setup/discovery/features
```
, filter
```
features[]
```
client-side to
```
apiName == "service-cloud-itsm-incident"
```
, read
```
status
```
. If
```
ENABLED
```
, proceed. If not, delegate to
service-itsm-incident-mgmt-configure
inline to enable (it runs its own confirm-to-write), then re-read to verify. If the user declines, halt — every SLA artifact below depends on the master being on. Full call shape + why the setup-org-preferences endpoint 404s here is in
```
references/mcp-invocation.md
```
(Preflight A).
Discover the Connect operations — (skip if already verified this session — see Phase 0).
```
mcp__headless-360__discover(query="sla-management milestone")
```
to confirm the SLA Management Connect API is indexed, then
```
mcp__headless-360__describe(id=<operation_id>)
```
for the
```
milestone-types
```
,
```
sla-policies
```
, and
```
sla-policies/{id}/milestones
```
POST operations to pull their exact input schemas + HTTP routes. If
```
discover
```
returns nothing after rewording the query, the corpus does not index this surface for the org — direct the user to Setup → SLA/Entitlement setup and stop.
Verify Incident Management + SLA fields — (skip if
Incident.describe
result for the current org is already in context — see Phase 0). Otherwise
```
dispatch_readonly
```
on
```
GET /services/data/v67.0/sobjects/Incident/describe
```
and confirm
```
fields[]
```
includes
```
EntitlementId
```
,
```
SlaStartDate
```
,
```
SlaExitDate
```
. If the describe 404s or fields are missing, direct the user to enable Entitlement Management for Incident and stop.
Find default BusinessHours — (skip if
BusinessHoursId
for the current org's default is already captured this session). Otherwise
```
dispatch_readonly
```
on
```
GET /services/data/v67.0/query
```
with
```
query_params.q="SELECT Id, Name FROM BusinessHours WHERE IsActive = true AND IsDefault = true"
```
. If
```
body.records
```
is empty, stop with a message to create default Business Hours in Setup. Capture
```
BusinessHoursId
```
.
Resolve the target Account — (skip if the Account the user named — or, absent a name, the fallback first-active Account — is already resolved to an Id this session). Otherwise the Entitlement in Phase 2 requires an
```
AccountId
```
, so resolve it now, before any mutation. If the user named an Account, look it up by name via a
```
dispatch_readonly
```
SOQL:
```
SELECT Id, Name FROM Account WHERE Name = '<escaped name>' LIMIT 1
```
. If the named Account is not found, stop and ask — do NOT silently substitute a different Account. Only when the user did not name one, fall back to the first active Account (
```
SELECT Id, Name FROM Account WHERE IsDeleted = false ORDER BY CreatedDate LIMIT 1
```
) and surface which Account you chose in the confirmation gate below. If no Account exists at all, stop with a message to create one first. Capture
```
AccountId
```
and the Account name.
Read existing SLA artifacts (idempotency probe) —
```
dispatch_readonly
```
SOQL against
```
SlaProcess
```
by name (
```
SELECT Id, Name FROM SlaProcess WHERE Name = '<name>' AND SObjectType = 'Incident' LIMIT 1
```
— the physical sObject field is
```
SObjectType
```
;
```
ProcessType
```
returns
```
INVALID_FIELD
```
),
```
MilestoneType
```
by name for each type the strategy would create,
```
SlaMilestone
```
under the matched
```
SlaProcess
```
, and
```
Entitlement
```
by name against the resolved Account. Record which artifacts already exist. If every artifact the request would create already exists with the requested configuration, Phase 1.4 skip condition (b) applies — set
```
noOp=true
```
and skip Phase 1.4 and Phase 2. Any missing or divergent artifact means a mutation is required; proceed to Phase 1.4.

若以下步骤返回
401
/
403
/
404
，立即停止并显示原始错误——组织或客户端配置不正确。

→ MCP授权问题（ECA未传递/令牌过期）。

→ 用户权限缺失或ITSM事件管理许可证/偏好缺失（

ITSMIncidentMgmtEnabled

IncidentMgmt.orgHasITSMOrgPermission

）。

→

headless-360

服务器未激活或事件的权益管理未启用。

事件管理主偏好——直接读取（跳过规则见Phase 0）。通过
```
dispatch_readonly
```
调用
```
GET /services/data/v67.0/connect/setup/discovery/features
```
，在客户端过滤
```
features[]
```
中
```
apiName == "service-cloud-itsm-incident"
```
的项，读取
```
status
```
。若为
```
ENABLED
```
，继续执行。若未启用，内部分派给
service-itsm-incident-mgmt-configure
进行启用（该技能会执行自己的确认写入流程），然后重新读取验证。若用户拒绝，停止操作——以下所有SLA组件均依赖主偏好已启用。完整的调用结构及为何此处配置组织偏好端点会返回404，请参考
```
references/mcp-invocation.md
```
（预检A）。
发现Connect操作（若本次会话已验证则跳过——见Phase 0）。调用
```
mcp__headless-360__discover(query="sla-management milestone")
```
确认SLA Management Connect API已被索引，然后调用
```
mcp__headless-360__describe(id=<operation_id>)
```
获取
```
milestone-types
```
、
```
sla-policies
```
和
```
sla-policies/{id}/milestones
```
的POST操作的精确输入模式+HTTP路由。若重新调整查询词后
```
discover
```
仍无返回，说明组织未索引此接口——引导用户前往设置→SLA/权益配置并停止操作。
验证事件管理 + SLA字段（若本次会话中当前组织的
```
Incident.describe
```
结果已在上下文则跳过——见Phase 0）。否则通过
```
dispatch_readonly
```
调用
```
GET /services/data/v67.0/sobjects/Incident/describe
```
，确认
```
fields[]
```
包含
```
EntitlementId
```
、
```
SlaStartDate
```
、
```
SlaExitDate
```
。若描述返回404或字段缺失，引导用户启用事件的权益管理并停止操作。
查找默认营业时间（若本次会话中已获取到当前组织的默认
```
BusinessHoursId
```
则跳过）。否则通过
```
dispatch_readonly
```
调用
```
GET /services/data/v67.0/query
```
，
```
query_params.q="SELECT Id, Name FROM BusinessHours WHERE IsActive = true AND IsDefault = true"
```
。若
```
body.records
```
为空，停止操作并提示用户在设置中创建默认营业时间。记录
```
BusinessHoursId
```
。
解析目标账户（若本次会话中已将用户指定的账户——或未指定时的默认第一个活跃账户——解析为Id则跳过）。否则Phase 2中的Entitlement需要
```
AccountId
```
，因此需在执行任何变更前解析完成。若用户指定了账户名称，通过
```
dispatch_readonly
```
执行SOQL查询：
```
SELECT Id, Name FROM Account WHERE Name = '<转义后的名称>' LIMIT 1
```
。若未找到指定账户，停止操作并询问用户——不要静默替换为其他账户。仅当用户未指定账户时，默认选择第一个活跃账户（
```
SELECT Id, Name FROM Account WHERE IsDeleted = false ORDER BY CreatedDate LIMIT 1
```
），并在下方的确认步骤中告知用户所选的账户。若不存在任何账户，停止操作并提示用户先创建账户。记录
```
AccountId
```
和账户名称。
读取现有SLA组件（幂等性探测）——通过
```
dispatch_readonly
```
执行SOQL查询：按名称查询
```
SlaProcess
```
（
```
SELECT Id, Name FROM SlaProcess WHERE Name = '<名称>' AND SObjectType = 'Incident' LIMIT 1
```
——实际对象字段为
```
SObjectType
```
；
```
ProcessType
```
会返回
```
INVALID_FIELD
```
）、按名称查询策略所需的每个
```
MilestoneType
```
、查询匹配的
```
SlaProcess
```
下的
```
SlaMilestone
```
、按名称查询已解析账户下的
```
Entitlement
```
。记录已存在的组件。若请求要创建的所有组件均已按要求配置存在，则Phase 1.4的跳过条件(b)适用——设置
```
noOp=true
```
并跳过Phase 1.4和Phase 2。若有任何组件缺失或配置不符，则需要执行变更；继续执行Phase 1.4。

Phase 1.4 — Milestone Strategy

Phase 1.4 — 里程碑策略

Every SLA policy needs at least one milestone. Load

examples/milestone-patterns.md

— it lists the Phase 1.4 skip conditions (concrete shape in prompt, idempotent no-op, explicit up-front authorization) and the five strategy options (Single, Response + Resolution, Priority-tiered, Escalation ladder, Custom/mixed) with their

AskUserQuestion

prompt, default numbers, and MilestoneType-reuse rules. Skip conditions (c) still requires Phase 1.5 plan-narration before dispatch. Multi-milestone selection expands to N milestone creates in Phase 2 step 10 (one POST per milestone,

order

1..N, all attached to the same SlaProcess).

每个SLA策略至少需要一个里程碑。参考

examples/milestone-patterns.md

——其中列出了Phase 1.4的跳过条件（提示中已指定结构、幂等无操作、预先明确授权）以及五种策略选项（单一里程碑、响应+解决、优先级分层、升级阶梯、自定义/混合），包含对应的

AskUserQuestion

提示、默认时间和MilestoneType复用规则。跳过条件(c)仍需在执行前完成Phase 1.5的方案说明。多里程碑选择会在Phase 2步骤10中扩展为N个里程碑创建操作（每个里程碑一个POST请求，

order

为1..N，均关联到同一个SlaProcess）。

Phase 1.5 — Confirm before mutating

Phase 1.5 — 变更前确认

Confirm the plan — present the resolved configuration (target org, SLA Policy name, resolved Account name, Entitlement date range, and the full per-milestone list from Phase 1.4 — never collapse Priority-tiered / Custom to "N milestones").
Skip the
AskUserQuestion
confirmation prompt (still narrate the plan before dispatch) when: up-front authorization was granted (note
```
(authorized in prompt)
```
); the branch is a no-op (skip Phase 1.5 + Phase 2, report the no-op); or the plan was already confirmed in conversation (note
```
(confirmed in conversation)
```
). Otherwise dispatch
```
AskUserQuestion
```
and require an explicit "yes" before Phase 2. Everything before this step is read-only; everything after mutates the org.

确认方案——展示已解析的配置（目标组织、SLA策略名称、已解析的账户名称、Entitlement日期范围，以及Phase 1.4中的完整里程碑列表——不要将优先级分层/自定义策略简化为“N个里程碑”）。
跳过
AskUserQuestion
确认提示（仍需在执行前说明方案）的场景：已预先授权（标注
```
(已在提示中授权)
```
）；分支为无操作（跳过Phase 1.5+Phase 2，报告无操作）；方案已在对话中确认（标注
```
(已在对话中确认)
```
）。否则调用
```
AskUserQuestion
```
并要求用户明确回复“是”后再执行Phase 2。此步骤之前的所有操作均为只读；之后的操作会变更组织配置。

Phase 2 — Create SLA Artifacts (exact order — each depends on the previous)

Phase 2 — 创建SLA组件（严格按顺序——每个步骤依赖前一个步骤）

Create MilestoneType(s) —
```
POST /connect/sla-management/milestone-types
```
. One POST per distinct MilestoneType required by the strategy. Reuse a single MilestoneType across milestones that share a name (Priority-tiered "First Response" reuses one MilestoneType across all four milestones); create separate MilestoneTypes for distinct concerns (Response + Resolution = two MilestoneTypes; Escalation ladder = three). Capture each
```
id
```
.
Create SLA Policy —
```
POST /connect/sla-management/sla-policies
```
with
```
processType='Incident'
```
and the
```
businessHourId
```
from Phase 1. Capture
```
id
```
. The response echoes nulls — verify via SOQL, not the response body.
Attach Milestone(s) — load the request-body template from
```
assets/attach-milestone.json
```
and, for each milestone in the strategy, populate
```
milestoneTypeId
```
,
```
timeTrigger
```
,
```
order
```
(1..N in the strategy's order) and any per-pattern
```
filterItems
```
additions from
```
examples/milestone-patterns.md
```
, then
```
POST /connect/sla-management/sla-policies/<slaId>/milestones
```
.
```
milestoneCriteria
```
is mandatory (
```
filterType: RuleFilter
```
). Do not put
```
slaProcessId
```
in the body — it is carried by the path. Multi-milestone strategies dispatch this call once per milestone; if any milestone POST fails, halt and surface the raw error — do not continue with a half-attached policy.
Create Entitlement —
```
POST /sobjects/Entitlement
```
linking the resolved Account (from Phase 1 step 5), the SLA Policy (
```
SlaProcessId
```
), and Business Hours. For immediate engagement, backdate
```
StartDate
```
to yesterday.

创建MilestoneType——调用
```
POST /connect/sla-management/milestone-types
```
。策略所需的每个不同MilestoneType对应一个POST请求。名称相同的里程碑复用同一个MilestoneType（优先级分层的“首次响应”在四个里程碑中复用同一个MilestoneType）；不同关注点创建独立的MilestoneType（响应+解决=两个MilestoneType；升级阶梯=三个）。记录每个
```
id
```
。
创建SLA策略——调用
```
POST /connect/sla-management/sla-policies
```
，参数为
```
processType='Incident'
```
和Phase 1中获取的
```
businessHourId
```
。记录
```
id
```
。响应会返回空值——需通过SOQL验证，不要信任响应体。
关联Milestone——加载
```
assets/attach-milestone.json
```
中的请求体模板，为策略中的每个里程碑填充
```
milestoneTypeId
```
、
```
timeTrigger
```
、
```
order
```
（按策略顺序为1..N）以及
```
examples/milestone-patterns.md
```
中特定场景的
```
filterItems
```
扩展，然后调用
```
POST /connect/sla-management/sla-policies/<slaId>/milestones
```
。
```
milestoneCriteria
```
为必填项（
```
filterType: RuleFilter
```
）。不要在请求体中放入
slaProcessId
——该参数通过路径传递。多里程碑策略需为每个里程碑调用一次此接口；若任何里程碑POST请求失败，立即停止操作并显示原始错误——不要继续执行部分关联的策略。
创建Entitlement——调用
```
POST /sobjects/Entitlement
```
，关联已解析的账户（来自Phase 1步骤5）、SLA策略（
```
SlaProcessId
```
）和营业时间。若要立即触发SLA，将
```
StartDate
```
设置为昨天。

Phase 3 — Verify

Phase 3 — 验证

Verify the SLA Policy — SOQL on
```
SlaProcess
```
(do not trust the create response).
Create a test Incident with
```
EntitlementId
```
pointing at the new Entitlement. For Priority-tiered strategies, set a specific
```
Priority
```
on the test Incident (or create one test Incident per Priority) so at least one milestone's criteria matches — otherwise no
```
EntityMilestone
```
will spawn even though the policy is wired correctly.
Verify engagement — SOQL confirming
```
Incident.SlaStartDate
```
is populated and the expected
```
EntityMilestone
```
row(s) exist with the correct
```
TargetDate
```
(s). For multi-milestone strategies, expect one
```
EntityMilestone
```
per milestone whose criteria the Incident satisfies.
Report results using the output format below.

验证SLA策略——通过SOQL查询
```
SlaProcess
```
（不要信任创建响应）。
创建测试事件，
```
EntitlementId
```
指向新创建的Entitlement。对于优先级分层策略，需为测试事件设置特定的
```
Priority
```
（或为每个优先级创建一个测试事件），以便至少满足一个里程碑的条件——否则即使策略配置正确，也不会生成
```
EntityMilestone
```
。
验证触发情况——通过SOQL确认
```
Incident.SlaStartDate
```
已填充，且预期的
```
EntityMilestone
```
行存在并带有正确的
```
TargetDate
```
。对于多里程碑策略，事件满足条件的每个里程碑应对应一个
```
EntityMilestone
```
。
按以下格式报告结果。

Rules / Constraints

规则/约束

Constraint	Rationale
Gate on SLA Management for IT Service first (Phase 0.5) — feature `ENABLED` AND versioning `true` ; confirm before enabling, versioning permanent, re-read after each write	Skipping risks a mid-flow 403/404; versioning can't be undone; writes don't confirm state
Discover + describe before any mutation	Catches a missing SLA surface / disabled Incident Management early
Ask (via `AskUserQuestion` ) which milestone strategy to use — do not silently default to Single	Real ITSM policies almost always have more than one milestone; picking silently hides the choice from the user
Reuse one MilestoneType per shared name; create a distinct MilestoneType per distinct concern	The runtime keys milestones by MilestoneType — sharing collapses distinct concerns
For multi-milestone strategies, halt on any milestone POST failure — do not continue with a half-attached policy	The confirmation gate covers all N milestones together; partial attach diverges from the confirmed plan
Priority-tiered strategy: validate every `Priority` value against the live Incident picklist before dispatch	The server accepts any string on `filterItems.value` — an unknown Priority value silently makes the milestone dead code
Entitlement is standard sObject DML (not Connect API); `StartDate` controls status (future = Inactive)	Not part of the `/connect/sla-management/` surface
Verify SLA Policy via SOQL, not the create response	The create response echoes nulls
Never show Salesforce record IDs to the user	Use human-readable names and IncidentNumber

Additional API quirks (payload rules, filter-operator enum, missing-criteria error) are documented in

references/mcp-invocation.md

— consult before dispatch.

约束	理由
首先满足SLA Management for IT Service限制（Phase 0.5）——功能状态为 `ENABLED` 且 `IsEntitlementVersioningEnabled` 为 `true` ；启用未开启的项前需确认，版本开关为永久设置，每次写入后重新读取	跳过此步骤可能导致流程中途出现403/404错误；版本开关无法撤销；写入操作不返回状态确认
变更前先执行发现+描述操作	提前捕获缺失的SLA接口/未启用的事件管理功能
通过 `AskUserQuestion` 询问用户使用哪种里程碑策略——不要默认为单一里程碑	实际ITSM策略几乎总是包含多个里程碑；静默选择会向用户隐藏选项
名称相同的里程碑复用同一个MilestoneType；不同关注点创建独立的MilestoneType	运行时通过MilestoneType识别里程碑——复用会合并不同的关注点
多里程碑策略中，若任何里程碑POST请求失败，立即停止操作——不要继续执行部分关联的策略	确认步骤已涵盖所有N个里程碑；部分关联会偏离已确认的方案
优先级分层策略：执行前验证每个 `Priority` 值与事件的实时选择列表匹配	服务器接受 `filterItems.value` 的任何字符串——未知的优先级值会导致里程碑失效
Entitlement为标准对象DML（非Connect API）； `StartDate` 控制状态（未来日期=未激活）	不属于 `/connect/sla-management/` 接口范围
通过SOQL验证SLA策略，不要信任创建响应	创建响应会返回空值
永远不要向用户显示Salesforce记录ID	使用易读的名称和事件编号

其他API特性（负载规则、过滤操作符枚举、条件缺失错误）记录在

references/mcp-invocation.md

中——执行前请参考。

Verification Checklist

验证清单

SLA Management prerequisite gated (Phase 0.5) — feature
```
ENABLED
```
AND
```
IsEntitlementVersioningEnabled
```
```
true
```
; whatever was off was enabled only after confirmation (versioning flagged permanent) and re-read to verify, never trusting the write response; non-empty
```
enableBlockedReasons
```
halted the run.
Master Incident Management pref was confirmed
```
ENABLED
```
via a live Setup Discovery read this session (or via an inline delegation to
```
service-itsm-incident-mgmt-configure
```
when it came back off). A user-asserted state is NOT a substitute for the live read.
```
discover
```
+
```
describe
```
(or the Incident describe) confirmed the SLA Management Connect operations.
Incident describe returned 200 with
```
EntitlementId
```
,
```
SlaStartDate
```
,
```
SlaExitDate
```
.
Default BusinessHours found.
Milestone strategy resolved — via a Phase 1.4 skip condition (prompt named a shape / no-op branch / up-front authorization + derivable shape) OR via
```
AskUserQuestion
```
. A skipped
```
AskUserQuestion
```
under a valid skip condition is honoring the contract, not violating it. For Priority-tiered / Custom, every
```
Priority
```
/ criteria value was validated against the live Incident picklist before dispatch.
Configuration confirmed OR skip condition met — up-front authorization, no-op branch, prior confirmation in conversation, OR explicit "yes" via
```
AskUserQuestion
```
. In every case, the resolved plan (org, SLA name, account, entitlement range, per-milestone list) was narrated before Phase 2 dispatched.
Artifacts created in order (MilestoneType(s) → Policy → Milestone(s) → Entitlement); each POST returned 201; any milestone POST failure halted the run (no partial attach). Trivially satisfied on no-op runs.
SLA Policy verified via SOQL (not the create response). On no-op runs, the Phase-1 read is the verification.
Test Incident has
```
SlaStartDate
```
populated (Priority chosen to match at least one criterion for Priority-tiered). Skip on no-op runs.
At least one EntityMilestone exists with the correct TargetDate; for multi-milestone strategies, the expected milestone(s) are present. Skip on no-op runs.
Before/after and summary shown. On no-op runs, the summary states the pre-existing configuration verbatim and reports "no changes made".

已满足SLA管理前置条件限制（Phase 0.5）——功能状态为
```
ENABLED
```
且
```
IsEntitlementVersioningEnabled
```
为
```
true
```
；未开启的项仅在确认后启用（版本开关标注为永久），并重新读取验证，从不信任写入响应；
```
enableBlockedReasons
```
非空时已停止操作。
事件管理主偏好已通过本次会话的Setup Discovery实时读取确认
```
ENABLED
```
（或当未启用时内部分派给
```
service-itsm-incident-mgmt-configure
```
进行启用）。用户断言的状态不能替代实时读取结果。
```
discover
```
+
```
describe
```
（或事件描述）已确认SLA Management Connect操作可用。
事件描述返回200且包含
```
EntitlementId
```
、
```
SlaStartDate
```
、
```
SlaExitDate
```
。
已找到默认营业时间。
已确定里程碑策略——通过Phase 1.4的跳过条件（提示中指定结构/无操作分支/预先授权且可推导结构）或
```
AskUserQuestion
```
。在有效跳过条件下跳过
```
AskUserQuestion
```
符合要求，并非违规。对于优先级分层/自定义策略，执行前已验证每个
```
Priority
```
/条件值与事件的实时选择列表匹配。
已确认配置或满足跳过条件——预先授权、无操作分支、对话中已确认，或通过
```
AskUserQuestion
```
获得明确的“是”。无论哪种情况，执行Phase 2前均已说明已解析的方案（组织、SLA名称、账户、权益范围、里程碑列表）。
组件按顺序创建（MilestoneType→策略→Milestone→Entitlement）；每个POST请求返回201；任何里程碑POST请求失败时已停止操作（无部分关联）。无操作分支自动满足此要求。
通过SOQL验证SLA策略（不要信任创建响应）。无操作分支中，Phase 1的读取即为验证。
测试事件已填充
```
SlaStartDate
```
（优先级分层策略中选择了至少满足一个条件的优先级）。无操作分支可跳过此步骤。
至少存在一个带有正确TargetDate的EntityMilestone；多里程碑策略中，预期的里程碑已存在。无操作分支可跳过此步骤。
已展示变更前后对比和总结。无操作分支中，总结需准确说明现有配置并报告“未进行任何变更”。

Output Format

输出格式

See

examples/output-templates.md

for the canonical failure / single-milestone success / multi-milestone success templates. Fill in the placeholders as-is. No record IDs in user-facing output. No files are produced — the skill mutates org configuration in place through headless-360 MCP dispatch.

请参考

examples/output-templates.md

中的标准失败/单一里程碑成功/多里程碑成功模板。直接填充占位符即可。用户输出中不得包含记录ID。不生成任何文件——本技能通过headless-360 MCP调度直接变更组织配置。

Reference File Index

参考文件索引

File	When to read
`references/mcp-invocation.md`	Every phase — exact `mcp__headless-360__*` call shapes, payload templates, response envelope, discovery, and gotchas (filter-operator enum, v67 routes, entitlement behavior)
`examples/milestone-patterns.md`	Phase 1.4 — the five milestone strategies (Single, Response + Resolution, Priority-tiered, Escalation ladder, Custom) with default times, criteria, MilestoneType reuse rules, and per-pattern filter-item extensions
`examples/output-templates.md`	Output Format — canonical failure / single-milestone success / multi-milestone success templates
`assets/attach-milestone.json`	Phase 2 step 10 — reusable request-body template for `POST /connect/sla-management/sla-policies/<slaId>/milestones` ; substitute `milestoneTypeId` , `businessHoursId` , `timeTrigger` , `order` , and append per-pattern `filterItems`

文件	读取时机
`references/mcp-invocation.md`	所有阶段——精确的 `mcp__headless-360__*` 调用结构、负载模板、响应包、发现操作和注意事项（过滤操作符枚举、v67路由、权益行为）
`examples/milestone-patterns.md`	Phase 1.4——五种里程碑策略（单一、响应+解决、优先级分层、升级阶梯、自定义），包含默认时间、条件、MilestoneType复用规则和特定场景的过滤项扩展
`examples/output-templates.md`	输出格式——标准失败/单一里程碑成功/多里程碑成功模板
`assets/attach-milestone.json`	Phase 2步骤10—— `POST /connect/sla-management/sla-policies/<slaId>/milestones` 的可复用请求体模板；替换 `milestoneTypeId` 、 `businessHoursId` 、 `timeTrigger` 、 `order` ，并添加特定场景的 `filterItems`