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 SLA Management for IT Service setup item (the Phase 0.5 gate). Four parts: MilestoneType (what you measure) → SLA Policy (SlaProcess, Incident-scoped, entry/exit criteria) → Milestone (time trigger + criteria) → Entitlement (Account-wired, so Incidents engage the SLA).

Scope

• In scope: the four artifacts above + verifying SLA engagement on Incident records; gating SLA Management for IT Service (Phase 0.5); offering the OOB Standard Support for Incidents policy vs a custom one (Phase 0.6, 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…) — 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. 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 3, 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 0.5 gate first. Then: which org? (headless-360 binds to the current OAuth session — confirm before mutating); milestone strategy? (Phase 1.4); target Account? (for the Entitlement); milestone criteria? (default Status != Closed + 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 (2). When in doubt, re-check.

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 first / recommended: Salesforce's predefined Incident policy (Standard Support for Incidents — priority-tiered) or a custom one. One-way: 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.

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/token). 403 → user perm OR ITSM Incident Management license/pref missing. 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).
2. 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>)