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) First action, before any question to the user: read the IT Service Enablement gate (Phase 1a) with dispatch readonly on GET /services/data/v68.0/connect/setup/discovery/features , filtered to the exact apiName service cloud itsm setup . Ask nothing else until it is ENABLED . Configures a complete Incident SLA pipeline for Service Cloud ITSM — the chain deriving an EntityMilestone (with a computed TargetDate) on every Incident with an Entitlement, all via the Salesforce hosted headless 360 MCP server (org from the OAuth JWT). Requires the org level IT Service Management enablement (the Phase 1a gate) and SLA Management for IT Service setup item (the Phase 1c gate), plus Incident Management (the Phase 1b gate). The custom pipeline (four ordered writes): MilestoneType (what you measure) → SLA Policy (SlaProcess, Incident scoped, created inactive, entry/exit criteria) → Milestone (time trigger + criteria) → activate the policy ( createEntitlement=true , which auto provisions the Entitlement — matching Incidents then engage the SLA per Incident via EntitlementId , with no Account). An org wide auto apply entitlement criterion is an optional fifth write, dispatched only on an explicit always match request (Phase 4A step 6) — never by default. (The predefined/OOB seed fork differs — it does none of this by hand: a single seed call provisions the whole active bundle — policy, milestones, and Entitlement — in one shot; see Phase 2 / Phase 4B.) This skill owns all the Incident SLA interaction (gates, forks, milestone strategy, verification); the raw write operations are delegated to the approved SLA leaf capabilities ( csp sun/MilestoneTypes , create sla policy , create milestone , create milestone action , activate sla policy , create entitlement criteria ), which own the approved Connect contracts — discover → describe → dispatch each rather than re deriving its shape here. The Phase 1c enable (+ Versioning) and Phase 4B seed writes delegate to itsm shakti/SLASettings (owns the SLA Management settings surface) — same discover → describe → dispatch. Scope In scope : the SLA artifacts above (MilestoneTypes, the SLA Policy and its milestones, activation with its auto provisioned Entitlement, and — only on an explicit org wide always match request — the optional auto apply criterion) + verifying SLA engagement on Incident records; gating SLA Management for IT Service (Phase 1c); offering the OOB Standard Support for Incidents policy vs a custom one (Phase 2, Incident only) — all via headless 360 MCP. Out of scope : Case SLA/entitlements; Assignment Rules; Escalation Rules; Notification Rules; general Entitlement CRUD not related to Incident SLA; SLA reporting. Output contract — applies to EVERY message Never print a raw Salesforce record Id (15/18 char: 55… , 550… , 0ny… , 00… , Account 001… ) — full or masked ( 557VW…R3XVYA0 still leaks) — in any user facing text: interim narration and the final report. Holds for artifacts you created and ones you detected/reused — name each (the name you supplied on create, or matched on reuse), keep its Id internal (chaining only). Verifying or matching via SOQL? Report the verified attributes/name , never the Id you queried by. Looking up an Id is the same rule — resolving Business Hours (resolved, user selected, or created in Phase 4A step 1) or an existing policy returns {Id, Name} ; narrate the resolved name only and keep the returned Id internal — never echo it back as Resolved "<name " (001VW…) . One exception: on a halt you may relay the raw error body verbatim even if it embeds an Id — don't hand edit it. Wrong: SLA policy created (552VW…) · Incident created (0ny…) · First Response → 557VW…R3XVYA0 (reuse) Right: Created SLA policy "Standard Support for Incidents" · reusing the existing First Response milestone type · the test Incident is "the test Incident" until Phase 6, then its IncidentNumber ; milestones by MilestoneType name. 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} ; read body from {status code, body} . Full route table with request/response shapes: references/mcp invocation.md . Clarifying Questions Ask only what you cannot infer from context (pre populate; note "(from conversation)"). Resolve the Phase 1a gate, then the Phase 1b Incident Management gate, then the Phase 1c gate, first and in that order. Then: ( headless 360 binds to the current OAuth session, so do not ask which org); milestone strategy? (Phase 3b); milestone criteria? (default Status != Closed + pattern specific filters). Do not ask for an Account — Incident has no Account field; engagement is per Incident via EntitlementId . Business Hours: ask only when the user's choice is ambiguous or the org has none (Phase 3a step 4); never ask on the Predefined path. Default suggestion: SLA Policy Incident SLA Policy , suggested default Business Hours (confirmed at Phase 3c), Entitlement auto provisioned on activation (no Account), engagement per Incident via EntitlementId , milestone strategy resolved per Phase 3b. Workflow Sequential — always read before you write ; every call goes through mcp headless 360 . Per phase detail (reads, delegated writes, API quirks) lives in references/workflow.md — read it before executing. Phase index and their non negotiable gates: Before you start — Reuse session state only from a successful dispatch readonly this session on this org, unwritten since; a user statement is never cache eligible. Phase 1a — IT Service Management gate ( service cloud itsm setup ). Exact ENABLED continues. Exact NOT ENABLED with no blocked reasons → ask “IT Service Enablement is off — enable it now?” via AskUserQuestion (Yes/No, never plain text; No halts) → delegate to the IncidentMgmt SOR with that confirmation → use its verify step before continuing. Missing, error, blocked, or any other status halts and points to Setup. Phase 1b — Incident Management gate ( service cloud itsm incident ). Exact ENABLED continues; NOT AVAILABLE → HALT; exact NOT ENABLED with no blocked reasons → its own Yes/No “Incident Management is off — enable it now?” via AskUserQuestion , delegate to the IncidentMgmt SOR (MCP steps, never Skill ), verify exact ENABLED ; No halts. Phase 1c — SLA Management gate. SLA Management and the permanent SLA Versioning switch — two writes; delegate to itsm shakti/SLASettings . Read both flags first. If either is off, ask with AskUserQuestion before ANY write, as two separate questions: Q1 “SLA Management for IT Service is off — enable it now?” (Yes/No; only when SLA Management is off), then Q2 the SLA Versioning permanence ack (Enable / Stop; exact wording in references/mcp invocation.md ). Never merge them, never preview later steps before each is answered, and never treat a Yes at Phase 1a/1b or the original request as consent; any No → HALT. Phase 2 — Predefined vs Custom (Incident only). Detect the seeded policy first; read the live Incident.Priority picklist before the fork (custom values → recommend Custom); warn if the priority matrix is off (only the default tier fires); Business Hours note only if the user specified hours. Predefined → 4B → 5 (if asked) → 6 → STOP ; Custom → 3a → 3b → 3c → 4A → 5 (if asked) → 6. Phase 3a — Preflight. Step 1 only reuses the Phase 1b Incident Management result; then discover / describe the SLA ops, Incident describe, resolve Business Hours, idempotency probe. No Account. 401 / 403 / 404 → halt with the raw error. Phase 3b — Milestone strategy per examples/milestone patterns.md . Phase 3c — Confirm the full plan (Business Hours by name, every milestone) before any write. Phase 4A — Create (Business Hours first if planned, step 1) → MilestoneTypes → create sla policy → create milestone ×N → activate sla policy ; optional step 6 criterion only on an explicit always match request. Phase 4B — Seed via save selected options ( {"selectedOptions":["incident"]} ), delegated to itsm shakti/SLASettings ; verify and name its Business Hours. Phase 5 — Milestone actions (only if asked) on every named milestone. Phase 6 — Verify via SOQL + a non lowest tier test Incident with an EntityMilestone ; matrix off or still order 1 after one retry → stop and report the other tiers unchecked. Rules / Constraints Constraint Rationale Gate IT Service Management enablement (Phase 1a), then Incident Management (Phase 1b, its own Yes/No) before Phase 1c — exact apiNames only, never a look alike; rules as in the phase list above Higher level org gate sits above every ITSM feature Gate SLA Management first (Phase 1c) — two separate writes (SLA Management, then the one way SLA Versioning ); two separate AskUserQuestion s before any write (Q1 SLA Management Yes/No, then Q2 permanence) — never merged, never inferred from an earlier gate's Yes ; decline/blocked/verify fail → HALT ; re read + report real state Versioning is irreversible; writes don't confirm state Offer predefined (OOB) first (Phase 2, Incident only); detect before seed; if chosen, seed → verify → STOP (no custom upsell) OOB seed isn't idempotent — re seed duplicates discover + describe before any mutation Catches a missing SLA surface / disabled Incident Mgmt early Ask ( AskUserQuestion ) the milestone strategy — never silently default to Single Real ITSM policies have 1 milestone Reuse one MilestoneType per shared name; a distinct one per distinct concern Runtime keys milestones by MilestoneType Multi milestone: halt on any milestone create failure (no half attached policy) Partial attach diverges from the confirmed plan Priority tiered: reconcile every Priority value against the live picklist before dispatch — drop/rename standard rows that don't match and add a milestone for each custom active value the org added Server accepts any string → an unknown value is a dead milestone; a custom value with no milestone gets no SLA Delegate every owned write — prerequisite feature enables to the IncidentMgmt SOR; SLA writes to their approved SLA leaves ( MilestoneTypes , create sla policy , create milestone , create milestone action , activate sla policy , create entitlement criteria ). The Phase 4A step 1 Business Hours create remains inline because no served SOR owns it Single contract owner per write; re deriving an owned contract here would drift from its served owner Business Hours (Custom): honor a named schedule, described calendar, or time zone (time zone only → ask 24×7 (recommended) or custom hours; reuse a match, else create one after the Phase 3c confirm); zero active → offer a 24×7 create. Never set IsDefault or modify an existing record. Predefined: the seeder always uses the org default — warn only if the user specified hours Default 24×7 or the customer's own calendar; BusinessHours is not API deletable, so creates are confirmed first Custom flow : activation provisions the auto Entitlement ( activate sla policy : isActive + createEntitlement as QUERY params ) — matching Incidents then engage per Incident via EntitlementId ( not a manual sObject Entitlement, and no Account). An org wide auto apply criterion via create entitlement criteria is optional — only on an explicit always match request, never by default. OOB seed path : one seeder call ( save selected options , lowercase selectedOptions ) provisions the entire active bundle incl. the Entitlement — no per leaf calls, no manual POST /sobjects/Entitlemen

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