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

Constraint	Rationale
Gate IT Service Management enablement first (Phase 1a, before Phase 1b) — exact apiName service-cloud-itsm-setup, never a look-alike; NOT_ENABLED → tell the user plainly + a single ack to enable (reversible) or stop; the enable write is dispatched directly (no owning SOR exists yet) and re-read to confirm	Higher-level org gate sits above every ITSM feature, including the Master Incident Mgmt pref below
Gate SLA Management first (Phase 1b) — two separate writes (SLA Management, then the one-way SLA Versioning); two separate acks (master, then permanence) — never merged; 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 write to its approved SLA leaf (MilestoneTypes, create-sla-policy, create-milestone, create-milestone-action, activate-sla-policy, create-entitlement-criteria) — the skill decides inputs, the leaf owns the contract. Scoped inline exceptions (no served owning SOR yet): the Phase 1a enable and the Phase 4A step 1 Business Hours create	Single contract-owner per write; the skill re-deriving Connect shapes drifts from the served leaves
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/Entitlement, no activate PATCH	Custom: one call activates and provisions, so a manual POST /sobjects/Entitlement would duplicate it. OOB: the platform seeder builds and activates the whole default bundle server-side, so the skill neither rebuilds it leaf-by-leaf nor provisions the Entitlement by hand
No record Id in any message (see Output contract, incl. reused artifacts); AskUserQuestion labels customer-facing (no "demo"/internal defaults)	Leaked Ids / internal framing look unprofessional to the customer
Another Incident policy already active + Custom chosen → narrate coexistence only. The custom policy is targeted per-Incident via EntitlementId (Incident has no Account field to scope on) and additive; the existing (predefined/broad) policy stays the org-wide one. Never offer, plan, or perform — in the fork or the closing report — deactivating an existing policy, reordering its entitlement criteria, broadening the custom policy to match-all / auto-apply-to-all, or "deciding/resolving precedence" across policies. Target specific Incidents via EntitlementId; the existing policy stays active (see references/workflow.md → Coexistence)	Changing a policy the user didn't ask to touch is out of scope — this skill configures a new coexisting custom policy, not edits to an existing one. Deactivating (activate-sla-policy can send isActive=false) or re-ranking another policy's criteria risks disrupting a live SLA, and no leaf arbitrates cross-policy precedence (predefined: no un-seed path, manual delete only). Both are meant to coexist — the agent otherwise improvises an out-of-scope deactivation/reorder/precedence upsell

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

---

Verification Checklist

• IT Service Management enablement gated (Phase 1a) — exact apiName service-cloud-itsm-setup read ENABLED via live read, or the user explicitly acked an enable (reversible) that a re-read confirms; declined / unexpected status → HALTED before Phase 1b.
• SLA Management gated (Phase 1b) — SLA Management + SLA Versioning both on (two separate writes), only after the permanence ack (separate from the master ack); reported state = a re-read, not the write. Declined / blocked / verify-fail → HALTED before Phase 2/3a, no artifacts.
• Predefined vs Custom offered (Phase 2) — with the feature ON, OOB Standard Support for Incidents offered first; if present, reported not re-seeded; if chosen, seeded (2 MilestoneTypes + 6 milestones + Entitlement), verified, no custom offer after.
• Master Incident Mgmt pref (exact service-cloud-itsm-incident) ENABLED via live read, or delegated when NOT_ENABLED (NOT_AVAILABLE → HALT) — not a user assertion, not a look-alike.
• discover/describe confirmed the SLA Connect ops.
• Incident describe returned 200 with EntitlementId, SlaStartDate, SlaExitDate.
• Active Business Hours resolved and named in the confirmed plan — the user's named schedule / a matching calendar / the org default / a user-selected record, or a create (described calendar or 24×7 when none exist) confirmed at Phase 3c, then SOQL-verified active. Predefined: the seeded policy's Business Hours reported by name (or "none").
• Milestone strategy resolved — Phase 3b skip condition OR AskUserQuestion; Priority-tiered / Custom reconciled every Priority/criteria value against the live picklist before dispatch (dropped/renamed unmatched standard rows and added a milestone for each custom active Priority value).
• Configuration confirmed OR skip condition met (up-front auth / no-op / prior confirmation / "yes"); the resolved plan (org, SLA name, Business Hours by name, engagement model = per-Incident via EntitlementId (no Account), per-milestone list) narrated before Phase 4A.
• Writes delegated to the SLA leaves in order — the four core writes: MilestoneType(s) → Policy → Milestone(s) → activate + auto-Entitlement (the optional org-wide auto-apply criterion only if explicitly requested); any milestone-create failure halted (no partial attach). Trivial on no-op.
• Milestone actions (Phase 5) — if requested, attached to every named milestone; each confirmed from body.success + actionMappings, not the 201; full set narrated before write.
• SLA Policy verified via SOQL, not the create response (no-op: the Phase-3a read is the verification).
• Test Incident has ≥1 EntityMilestone on the correct tier with a TargetDate (the engagement proof; Priority matched for Priority-tiered); expected milestone(s) present. Matrix off / still order-1 after one retry → reported "other tiers not checked" + pointed to service-itsm-incident-priority-configure, no recreate loop. SlaStartDate populated confirms it too, but may be null when the Entitlement is auto-applied via criteria — not a failure. Skip on no-op.
• No record Id in any message — interim narration and final report; artifacts by name, test Incident by IncidentNumber (see Output contract).
• Before/after + summary shown; no-op states the pre-existing config verbatim + "no changes made".

---

Output Format

Use the examples/output-templates.md templates; fill placeholders as-is. The success report must carry, unambiguously: the SLA Policy; every milestone by MilestoneType name + time + criteria; the Entitlement (auto-provisioned, no Account — Incident has no Account field); every requested action by milestone tier/MilestoneType name (never a milestone Id) + Warning/Violation role + offset + how confirmed; a Verification section (SOQL-confirmed policy + test-Incident SlaStartDate/EntityMilestones, or an honest partial note); created-vs-reused per artifact; a scope line (only the Incident SLA). No record Id anywhere. If another Incident policy is already active, state the coexistence plainly (both stay active; the existing/predefined policy stays the broad org-wide one; the custom is targeted per-Incident via EntitlementId) and do not offer to deactivate or reorder it, to broaden the custom policy to auto-apply to all Incidents, or to "decide precedence" across policies.

---

Reference File Index

File	When to read
references/workflow.md	Executing — the full step-by-step Phase 1–6 detail (per-phase reads, delegated writes, API quirks); the constraints table + verification checklist stay in this SKILL.md body
references/mcp-invocation.md	Every phase — call shapes, templates, response envelope, discovery, gotchas
examples/milestone-patterns.md	Phase 3b — the five strategies: times, criteria, MilestoneType reuse, filter extensions
assets/attach-milestone.json	Phase 4A step 4 — milestone POST body; substitute ids/timeTrigger/order; append filterItems
assets/attach-milestone-action.json	Phase 5 — Warn/Escalate action body templates (Field Update); pair with mcp-invocation.md (Milestone Actions)
examples/output-templates.md	Output Format — success/partial report templates; fill placeholders, no record Id

---

Related Skills

The priority matrix (Impact × Urgency → Priority) is separate — service-itsm-incident-priority-configure; if a Priority-tiered strategy is requested but Incident.Priority lacks values, direct the user there first. Other ITSM flows (Major Incident Mgmt, custom fields) are out of scope.