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

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

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

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

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

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

| Constraint | Rationale |

|-----------|-----------|

| Gate on SLA Management for IT Service first (Phase 0.5) — one enable turns on the feature and, one-way, SLA Versioning; two separate acks (master, then permanence) — never merged; decline / blocked / verify-fail → HALT, no fall-through; re-read + report real state | Versioning can't be undone; writes don't confirm state |

| Offer the predefined (OOB) policy first (Phase 0.6, Incident only); detect before seed; if chosen, seed → verify → STOP (no custom upsell) | OOB seed has no server idempotency (re-seeding duplicates) |

| Discover + describe before any mutation | Catches a missing SLA surface / disabled Incident Management early |

| Ask (via AskUserQuestion) which milestone strategy to use — don't silently default to Single | Real ITSM policies usually have >1 milestone; a silent default hides it |

| Reuse one MilestoneType per shared name; create a distinct one per distinct concern | The runtime keys milestones by MilestoneType — sharing collapses distinct concerns |

| For multi-milestone strategies, halt on any milestone POST failure (no half-attached policy) | Partial attach diverges from the confirmed plan |

| Priority-tiered: validate every Priority value against the live Incident picklist before dispatch | The server accepts any string on filterItems.value — an unknown value silently makes the milestone dead code |

| Entitlement is standard sObject DML (not Connect API); StartDate controls status (future = Inactive) | Not part of the /connect/sla-management/ surface |

| Verify SLA Policy via SOQL, not the create response | The create response echoes nulls |

| Never show record IDs in any message, incl. interim narration — the test Incident by IncidentNumber, milestones by MilestoneType name, never the 15/18-char Id; keep AskUserQuestion labels customer-facing (no "demo", "the skill", internal defaults) | Leaked Ids and internal/demo framing look unprofessional |

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 NOT_ENABLED (NOT_AVAILABLE → 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

| File | When to read |

|------|--------------|

| references/mcp-invocation.md | Every phase — exact mcp__headless-360__* call shapes, payload templates, response envelope, discovery, and gotchas (filter-operator enum, v67 routes, entitlement behavior) |

| examples/milestone-patterns.md | Phase 1.4 — the five milestone strategies with default times, criteria, MilestoneType reuse rules, and per-pattern filter-item extensions |

| examples/output-templates.md | Output Format — canonical failure / single-milestone success / multi-milestone success templates |

| assets/attach-milestone.json | Phase 2 step 10 — request-body template for the milestone POST (sla-policies/<slaId>/milestones); substitute milestoneTypeId, businessHoursId, timeTrigger, order; append per-pattern filterItems |

| assets/predefined-incident-policy.json | Phase 0.6 / Phase 2-OOB — the OOB Standard Support for Incidents seed template (policy + 2 MilestoneTypes + 8 priority-tiered milestones) |

| assets/attach-milestone-action.json | Phase 2.5 — Warn/Escalate milestone-action body templates (Field Update); pair with references/mcp-invocation.md (Milestone Actions) |

---

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.