Service Itsm Agentic Setup Incident Sla Configure

Configuring Incident SLA (End-to-End)

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 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 1b 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 1b); 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 and Phase 1b gates first, in that order. Then: which org? (headless-360 binds to the current OAuth session — confirm before mutating); 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). NOT_ENABLED → one ack (reversible) → direct enable → re-read.
• Phase 1b — SLA Management gate. SLA Management and the permanent SLA Versioning switch — two writes, two separate acks (master, then permanence); delegate to itsm-shakti/SLASettings.
• 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. Master Incident Mgmt (service-cloud-itsm-incident; NOT_AVAILABLE → HALT, NOT_ENABLED → one ack + delegate), 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

Additional API quirks: references/mcp-invocation.md.

---