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 → mcpheadless-360dispatchreadonly, writes → mcpheadless-360dispatch. Both take raw HTTP: {"url","method","body"?,"queryparams"?} — not {operationid, arguments}. Response envelope: standard REST — read body from {statuscode, 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 mcpheadless-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).

1. 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).

dispatchreadonly 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; NOTAVAILABLE (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).

1. Discover the Connect operations — (skip if already verified this session — see Phase 0).

mcpheadless-360discover(query="sla-management milestone") to confirm the SLA Management Connect API is indexed, then mcpheadless-360describe(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.

1. 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.

1. Find default BusinessHours — *(skip if BusinessHoursId for the current org's default is

already captured this session)*. Otherwise dispatchreadonly on GET /services/data/v67.0/query with queryparams.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.

1. 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.

1. 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

1. 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)

1. 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.

1. 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.

1. 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. Each milestoneCriteria[] item needs milestoneAgreementType (SLA/OLA) and filterType: RuleFilter. Do not put slaProcessId in the body — carried by the path. Multi-milestone strategies dispatch once per milestone; on any milestone POST failure, halt and surface the raw error — do not continue with a half-attached policy.

1. 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.

Phase 2-OOB — Seed the Predefined Incident Policy

Reached only from Phase 0.6 Predefined (replaces Phase 1.4/1.5/2). Follow the seed recipe in references/mcp-invocation.md (Predefined Incident Policy) with the template in assets/predefined-incident-policy.json — it uses the Phase 2 routes (2 MilestoneTypes → SLA Policy active:true → 8 priority-tiered milestones → Entitlement), validates each Priority/Status against the live picklist, and avoids the Connect activate PATCH. Then run Phase 2.5 (if actions requested), then Phase 3 (Critical test Incident), and STOP — no proactive custom offer.

Phase 2.5 — Milestone Actions (optional: Warn / Escalate)

After milestones exist (Phase 2 or 2-OOB), only if the user asked to warn/escalate/notify: apply the requested checkpoint(s) to every milestone the user named (not just one), computing each offset from that milestone's own target. Map "warn at X%" → an offset before target, "on breach" → at/after it; confirm the full set before writing (up-front auth waives the re-ask; narrate it regardless — no headless delete), then, per milestone, delegate to headless create-milestone-action (discover → describe → dispatch). Confirm each from the response body (success + non-empty actionMappings; a timed checkpoint also returns a triggerId), never the 201. Formula, roles, proven body, defaults, and the IST business-hours note: references/mcp-invocation.md (Milestone Actions).

Phase 3 — Verify

1. Verify the SLA Policy — SOQL on SlaProcess (do not trust the create response).
2. Create a test Incident with EntitlementId set to the new Entitlement. For Priority-tiered

strategies, set a Priority that matches at least one milestone's criteria (or one test Incident per Priority) — otherwise no EntityMilestone spawns even with the policy wired correctly.

1. Verify engagement — SOQL confirming Incident.SlaStartDate is populated and the expected

EntityMilestone row(s) exist with correct TargetDate(s) — one per milestone whose criteria the Incident satisfies.

1. Report results using the output format below.

Rules / Constraints

Additional API quirks (payload rules, operator enum, missing-criteria error): references/mcp-invocation.md.

Verification Checklist

• SLA Management gated (Phase 0.5) — feature + SLA Versioning both on, only after the permanence ack (separate from the master ack); reported state matches a re-read, not the write. If it couldn't be enabled (declined / blocked / verify-fail), the run HALTED before Phase 0.6/1 — no artifacts.
• Predefined vs Custom offered (Phase 0.6) — with the feature ON, the OOB Standard Support for Incidents policy was offered first; if it existed, reported not re-seeded; if chosen, seeded (2 MilestoneTypes + 8 tiered milestones + Entitlement), verified, no custom offer followed.
• Master Incident Mgmt pref (exact service-cloud-itsm-incident) confirmed ENABLED via a live read, or delegated to service-itsm-incident-mgmt-configure when NOTENABLED (NOTAVAILABLE → HALT) — not a user assertion, not a look-alike.
• discover/describe (or the Incident describe) confirmed the SLA Connect operations.
• Incident describe returned 200 with EntitlementId, SlaStartDate, SlaExitDate.
• Default BusinessHours found.
• Milestone strategy resolved — via a Phase 1.4 skip condition OR AskUserQuestion; 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 / prior confirmation / explicit "yes"); the resolved plan (org, SLA name, account, entitlement range, per-milestone list) was narrated before Phase 2.
• Artifacts created in order (MilestoneType(s) → Policy → Milestone(s) → Entitlement); each POST 201; any milestone POST failure halted the run (no partial attach). Trivial on no-op runs.
• Milestone actions (Phase 2.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 (on no-op, the Phase-1 read is the verification).
• Test Incident has SlaStartDate populated (Priority chosen to match a criterion for Priority-tiered) and ≥1 EntityMilestone with the correct TargetDate; expected milestone(s) present for multi-milestone. Skip on no-op.
• Before/after + summary shown; on no-op, the summary states the pre-existing configuration verbatim and reports "no changes made".

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 files are produced — the skill mutates org configuration in place through headless-360 MCP dispatch.

Reference File Index

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 is missing values, direct the user there first. Other adjacent ITSM flows (Major Incident Mgmt, custom fields on Incident/Problem/ChangeRequest) are out of scope.