End-to-end Incident SLA setup for Service Cloud ITSM — creating a MilestoneType, an Incident-scoped SLA Policy (SlaProcess), attaching a Milestone with criteria, and wiring an Entitlement so Incidents derive an EntityMilestone with a computed TargetDate. Use when the user asks to configure SLA miles

Configuring Incident SLA (End to End) Configures a complete Incident SLA pipeline for Service Cloud ITSM — the chain that derives an EntityMilestone (with a computed TargetDate) on every Incident with an Entitlement. Every operation runs through the Salesforce hosted headless 360 MCP server; 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 (the Phase 0.5 gate — see below). Setup has four parts: MilestoneType (what you measure) → SLA Policy (SlaProcess scoped to Incident, entry/exit criteria) → Milestone (time trigger + filter criteria) → Entitlement (wired to an Account so Incidents engage the 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 consent) enabling SLA Management for IT Service (Phase 0.5); halts if not fully enabled or consent declined. In scope — predefined vs custom (Phase 0.6): offering the OOB Standard Support for Incidents policy (Incident only) vs a custom one. Out of scope : Case SLA/entitlements; Assignment Rules; Escalation Rules; Notification Rules; general Entitlement CRUD not related to Incident SLA; SLA reporting. Routes at a glance Reads → mcp headless 360 dispatch readonly , writes → mcp headless 360 dispatch . Both take raw HTTP: {"url","method","body"?,"query params"?} — not {operation id, arguments} . Response envelope : standard REST — read body from {status code, body} . The full route table — create MilestoneType / SLA Policy / Milestone, Entitlement, BusinessHours, test Incident, the Phase 0.5 feature calls, and the create milestone action op — with request/response shapes lives in references/mcp invocation.md . Clarifying Questions Ask only what you cannot infer from context (pre populate; note "(from conversation)"). Resolve the Phase 0.5 gate first. Which org? headless 360 binds to the current OAuth session; confirm the target before mutating. Milestone strategy? See Phase 1.4 (skipped per its skip conditions). Target Account? For the Entitlement. Milestone criteria? Default Status != Closed , plus pattern specific filters. Default suggestion: SLA Policy Incident SLA Policy , default BusinessHours, the Account the user picks, Entitlement today → today + 1 year , milestone strategy resolved per Phase 1.4. Workflow All steps are sequential. Always read before you write. Every call goes through mcp headless 360 tools. Phase 0 — Reuse what the session already knows Each Phase 1 read carries a skip if already known clause: skip only when the same fact was produced this session by a successful dispatch readonly on the current org and unwritten since — a user statement is never cache eligible. Cacheable: master Incident Mgmt pref (step 1, only if ENABLED ), SLA feature + Versioning (Phase 0.5), Incident describe (3), BusinessHoursId (4), Account id (5), SLA Connect ops indexed (2). When in doubt, re check — a wrong skip on a live write is worse than a re read. Phase 0.5 — SLA Management for IT Service prerequisite gate Resolve this gate first, on its own. Reads are safe up front; confirm the org before any write. "SLA Management for IT Service" is enabled only when both Simplified SLA Setup (feature service cloud itsm manage sla policies ) and SLA Versioning ( EntitlementSettings.IsEntitlementVersioningEnabled ) are on; either off → not enabled. The one feature enable turns on both, permanently enabling versioning — inseparable. Shapes / enableBlockedReasons / ack wording: references/mcp invocation.md . Read both ( dispatch readonly ); proceed to Phase 0.6 only when both are on . On an OFF org, read the master license first (Phase 1 step 1, service cloud itsm incident ): NOT AVAILABLE → HALT — don't flip the permanent Versioning switch where Incident SLA can't run. Two separate AskUserQuestion acks — never merge. (a) master Incident Mgmt NOT ENABLED → ask to enable it first (reversible, no permanence warning). (b) a distinct permanence ack: enabling SLA Management turns on SLA Versioning , which can't be turned off (the feature disables later but Versioning stays on). Offer enable / stop — no "versioning off"; a bare "enable SLA" is not consent. Decline (b), non empty enableBlockedReasons , or a re read mismatch → HALT — enable no SLA Mgmt/Versioning, don't proceed to Phase 0.6/1 (a reversible master enable from (a) stands). After any write, re read both and report the REAL state — never trust 201 / 204 . Phase 0.6 — Predefined (OOB) vs Custom Once the gate passes, offer the OOB policy before any custom flow questions. Incident only. 1. Prerequisite + detect. Confirm master Incident Mgmt pref ENABLED (Phase 1 step 1). Then dispatch readonly GET /connect/sla management/sla policies with query params.processTypes=Incident ; match display name "Standard Support for Incidents" . Already present → no re seed (no idempotency), no custom upsell; report it is seeded. If warn/escalate actions were requested → resolve the named existing milestones → Phase 2.5 → Phase 3 verify → STOP (attach actions even though the policy was already seeded). 2. Fork — one AskUserQuestion , Predefined listed first / recommended : use Salesforce's predefined Incident SLA policy ( Standard Support for Incidents — priority tiered milestones) or build a custom one. One way note: predefined seeds an active policy + Entitlement, no un seed path (manual delete only). Predefined → resolve BusinessHours + Account (Phase 1 steps 4–5) → Phase 2 OOB → Phase 2.5 (if actions requested) → Phase 3 verify → STOP . Custom → existing Phase 1 → 1.4 → 1.5 → 2 → 3, unchanged. MUST read references/mcp invocation.md (Predefined Incident Policy) before seeding. Phase 1 — Preflight & discovery On any 401 / 403 / 404 from a step below, halt and surface the raw error — the org/client is misconfigured. 401 → MCP auth (ECA not propagated / expired token). 403 → user perm OR ITSM Incident Management license/pref missing ( ITSMIncidentMgmtEnabled / IncidentMgmt.orgHasITSMOrgPermission ). 404 → headless 360 not activated OR Entitlement Management not enabled for Incident. 1. Master Incident Management pref — direct read (skip conditions in Phase 0) . dispatch readonly GET .../connect/setup/discovery/features , filter features[] to the exact apiName == "service cloud itsm incident" — never a look alike ( service cloud incident management is generic Case based Incident Management, not our target). Read status : ENABLED → proceed; NOT AVAILABLE (license missing) → halt and surface it — cannot be enabled here, no delegate/ack; NOT ENABLED → explicit AskUserQuestion ack first (never auto enable as an implied SLA dependency) , then delegate to service itsm incident mgmt configure inline (confirms to write) and re read; if declined, halt — every SLA artifact below depends on the master being on. Full shape + why setup org preferences 404s here: references/mcp invocation.md (Preflight A). 2. 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. 3. 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. 4. 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 . 5. Resolve the target Account — (skip if already resolved this session) . Phase 2's Entitlement needs an AccountId . If the user named one → look up ( SELECT Id, Name FROM Account WHERE Name = '<escaped ' LIMIT 1 ); not found → stop and ask , never substitute. If the user authorized any/existing Account → pick the most recently active ( ... WHERE IsDeleted = false ORDER BY LastModifiedDate DESC LIMIT 1 ) and surface which in the plan. Otherwise → ask via AskUserQuestion : list real candidates by name only + "type a name"; never auto pick, pre select, or expose an internal sort key (e.g. recency). If none exists, stop. Capture AccountId + name. 6. Read existing SLA artifacts (idempotency probe) — dispatch readonly SOQL for SlaProcess by name ( ... WHERE Name = '<name ' AND SobjectType = 'Incident' — the field is SobjectType ; ProcessType returns INVALID FIELD ), each MilestoneType the strategy would create, SlaMilestone under the matched policy, and Entitlement by name on the resolved Account. If every artifact already exists with the requested config, set noOp=true and skip Phase 1.4 + Phase 2 (skip condition (b)); any missing/divergent artifact → proceed to Phase 1.4. Phase 1.4 — Milestone Strategy Every SLA policy needs at least one milestone. Load examples/milestone patterns.md — it lists the skip conditions (concrete shape in prompt / idempotent no op / explicit up front authorization) and the five strategy options with their AskUserQuestion prompt, defaults, and MilestoneType reuse rules. Skip condition (c) still requires Phase 1.5 plan narration before dispatch. Multi milestone selection expands to N creates in Phase 2 step 10 (one POST per milestone, order 1..N, same SlaProcess). Phase 1.5 — Confirm before mutating 7. Confirm the plan — present the resolved config (target org , SLA Policy name, resolved Account name, Entitlement date range, and the full per milestone list — never collapse Priority tiered / Custom to "N milestones"). Skip the AskUserQuestion (but still narrate the plan before dispatch) when up front authorization was granted (note (authorized in prompt) ), the branch is a no op, or it was already confirmed in conversation (note (confirmed in conversation) ); otherwise require an explicit "yes" before Phase 2. Everything before this step is read only; everything after mutates the org. Phase 2 — Create SLA Artifacts (exact order — each depends on the previous) 8. 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 . 9. Create SLA Policy — POST /connect/sla management/sla policies with processType='I

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