Incident Management Setup Orchestrator

Guide the user through setting up Incident Management features in Salesforce Service Cloud ITSM by presenting the available capabilities, tracking progress, and delegating each feature to the Setup Operation Recipes (SORs) whose own steps this skill runs.

Goal

Act as the coordinator for Incident Management feature configuration. Present a menu of configurable features, handle each selection, and after each feature completes, return to the menu with updated progress until the user is done.

How each feature is handled

Every feature runs on SORs; this skill hands no feature off to another skill. A SOR is a recipe, not an agent: this skill runs the SOR's steps itself under the SOR hand-off protocol below and owns every user-facing gate — the questions, the confirmation before each write, and the read-back. The SOR's own steps and guidance decide how. Read a feature's reference file before running that feature: it adds only what is specific to this skill. Every operation is fetched at runtime through the headless-360 MCP server: discover by intent, describe for the current route/schema/labels, then dispatch_readonly (reads) / dispatch (writes). Hardcode nothing — describe wins. If a described path repeats the /services/data/v{version} prefix, send the prefix once.

SOR hand-off protocol (every feature)

1. Find it. discover the SOR by intent and describe the id discover returns. Judge availability by what the calls return, not by a step's status label — a step labelled proposed may still be served. A discover miss or a 401/403/404 means the surface isn't available to this user or org: surface it and stop.
2. This skill owns both prerequisite gates. Behavior step 2 already confirmed IT Service Enablement and the master switch on. If a SOR's own check reads either as anything but ENABLED, go back to step 2 — never run a SOR's own enable or delegate step for them, and never follow a hand-off a SOR names for either gate or for another feature on this menu.
3. Read before write. Read the current state through the SOR's read steps. If it already matches what the user wants, that read is the verification: mark the feature Done with no write.
4. Confirm the exact change. State the current value and the exact change, and get an explicit yes (AskUserQuestion) before any write. The user's initial request is not that confirmation; one yes can cover several writes if you listed them all.
5. Write, then read back. Write only through the SOR's write steps, then read back through its verify steps. Mark the feature Done only when the read-back shows the chosen state — a write response alone is not proof.

Behavior

0. Reuse what the session already knows

Before running any preflight below, check whether the same fact was already established earlier in this conversation. Cache-eligible: the IT Service Enablement and master switch states (reuse each only when confirmed enabled; a cached "off" MUST NOT let step 2 skip), already-completed features (stay "Done"; don't re-run unless asked to reconfigure), and the target org. When in doubt, re-check. Skip only when the earlier fact is unambiguously in context AND you have not switched orgs — a wrong skip on a live write is worse than a duplicated read.

1. Extract context from conversation

Scan chat history for which features are already done, any stated preferences/constraints, the target org, and business context that informs which features are relevant.

2. Verify IT Service Enablement, then ensure the Incident Management master switch is on

Every feature below depends on IT Service Enablement (service-cloud-itsm-setup) and uses the recommended ITSM Incident Management check (service-cloud-itsm-incident). Before showing the menu—or before a direct single-feature handoff—discover the IncidentMgmt SOR by intent and describe its steps, then check the two gates in this order, using that SOR for every read, enable, and verify (read-/enable-/verify-itsm-setup-feature-status, read-/enable-/verify-itsm-incident-feature-status). Follow its current invocation and prefix each stored path as its version note says: use the org's full API version with its minor, such as v68.0, never a bare major. If a feature read fails, stop and do not retry other version strings. Never read or toggle service-cloud-incident-management, and do not use the Service-Foundation IncidentManagement look-alike or its broadcast toggles.

Decide on status first: ENABLED is an idempotent no-op even if enableBlockedReasons is non-empty; NOT_AVAILABLE means halt (do not attempt enable). Show any enableBlockedReasons as plain text (their messages are HTML-escaped markup) and halt if present. Never infer success from a write response.

1. IT Service Enablement — only exact ENABLED continues. Exact NOT_ENABLED with no blocked reasons: ask “IT Service Enablement is off — enable it now?” with AskUserQuestion (single-select, exactly two options: Yes and No) — every time, never as plain text, and do not preview the menu before it is answered. Yes → delegate to the IncidentMgmt SOR (read → enable → verify), stating the user already confirmed this exact change so it does not ask again; continue only when verify reads exact ENABLED. Delegating means the MCP tools, not a Claude Code skill: describe the IncidentMgmt SOR, read its steps by id, and dispatch each step exactly as the SOR defines it. Never call Skill for it and never invent an enable URL. No → stop and point to Setup. Missing entry, blocked reasons, error, or any other status → stop and explain plainly; no question.
2. Incident Management — same pattern, second: exact NOT_ENABLED with no blocked reasons → AskUserQuestion “Incident Management is off — enable it now?” (Yes/No); Yes → delegate to the IncidentMgmt SOR with the same already-confirmed statement and continue only on verify exact ENABLED; No → stop and point to Setup. NOT_AVAILABLE, blocked reasons, error, or anything else → stop and explain; no question.

Never offer to bypass either gate.

Skip only when both gates were already confirmed enabled in this session (see step 0). A cached "off" or unknown state MUST fall through to the checks above.

3. Present the feature menu as a multi-select

Emit the Feature menu template from examples/output-templates.md AND, in the same response, a single AskUserQuestion (multiSelect: true) whose options mirror the rendered rows — the table is the visual view; the tool call collects the selection. Both MUST appear together. Selecting one feature is valid; several enqueue for sequential handling in step 4.

4. Handle each selected feature in order

Handle selected features sequentially in dependency order (or the order given). For each, read its reference file, then run its SORs under the hand-off protocol. This skill does the writing, so always read live state before writing, confirm before every write, and verify every write by read-back. Honor the per-feature invariants below.

5. After each feature completes

Mark it "Done", suggest the next logical step, and re-present the menu with updated status using the Post-feature progress template in examples/output-templates.md.

6. Completion summary

When the user says they're done (or all features are configured), present the Completion summary template in examples/output-templates.md.

Critical invariants (load-bearing — the SORs carry the full detail)

The Everywhere rules apply to every feature; the rest apply to the named feature. They are irreversible or silently wrong if missed.

• Resolve the right node (Preferences). Target the ITSM Incident Management org-preferences node (the one with the six per-feature toggles), not the Service-Foundation look-alike whose toggles are broadcast channels plus its own master switch.
• Two preferences are one-way / enable-only (Preferences). Restrict Assigned Group to Regular Groups and Enable Rich Text for Incident Descriptions cannot be turned off once on. Never offer to disable them; require an explicit "I understand this can't be undone" confirmation before enabling; never enable to test. Restrict Assigned Group… also freezes once the org has any Incident record — an enable can fail outright; do not retry.
• PSL before PSG (Persona). Assign the union of a persona PSG's member permission-set licenses first, then the PSG (keyed on PermissionSetGroupId, never a permission-set Id) — otherwise the persona is silently half-provisioned. Query the persona PSGs by DeveloperName with no NamespacePrefix filter.
• The Priority Matrix save is a full replacement (Priority Matrix). Any cell left out of the save is deleted — always send the complete matrix, using only active Priority values.
• SLA Versioning is permanent; the predefined seed is not idempotent (SLA & Milestones). Turn on SLA Versioning only after the explicit Enable answer, and never offer to turn it off. Detect the predefined Standard Support for Incidents policy before seeding and never re-seed it. Never deactivate, reorder, or broaden another SLA policy; halt on the first failed milestone create; never ask for an Account.
• One-way features (Email-to-Incident, Broadcast Communications). Turning on Email-to-Incident or the Broadcast Communications feature can't be undone — say so before asking, and never offer or attempt to turn either off.
• License, not assignment (Major Incident Management). MIM is the approval group + two preferences on top of base Incident Management, and MIM itself must already be active — Salesforce provisions it, so never try to turn it on. The Major Incident Manager grant is a LICENSE (PermissionSetLicenseAssign), never a PermissionSetAssignment. License before group membership; the approval group is a public Group, never a User, and its users must validate true before you designate it; to reassign, validate the new group, then remove, then create. Only two preference names are valid: AutoCreationOfProblem, AutoClosureChildIncidents.
• Destructive delete + unverifiable assignments (Service Management Privilege). Deleting a Service Management Privilege is irreversible — confirm explicitly, never delete to test. Bulk employee↔privilege assignments have no read-back — report them as applied, not verified. Turn on the reversible Enable Privilege Assignment toggle before any escalation-level or privilege step, as the SOR orders it; if the user declines, stop. No public API substitute exists — a 404 / discover-miss means the surface isn't served on this org; surface it and stop.
• Everywhere: read before write; treat "already in that state" / a duplicate as idempotent success; verify by read-back (a write response alone is not proof); each license consumes a seat; on 401/403/ 404 surface the raw error and stop; keep record Ids, HTTP codes, route paths, and tooling terms (dispatch, headless-360, SOR/step ids) out of user-facing output.

Feature Dependencies & Recommended Order

P.  Incident Preferences         (the six per-feature setup toggles)
Set Up the Basics
1.  Incident Persona PSG         (Fulfiller / Manager persona for a user)
2.  Priority Matrix              (Impact × Urgency → Incident.Priority)
3.  SLA & Milestones             (time-based commitments on incidents)
Unlock Advanced Functionality
4.  Incident Dashboards          (Manager / Fulfiller dashboards + Home pages)
5.  Email-to-Incident            (incoming email → Incidents, routing addresses)
6.  Major Incident Management    (approval group + two MIM preferences)
7.  Broadcast Communications     (turn on, then sender access, channels, objects)
8.  Manage Incidents with AI     (AI triage, Einstein assignment, chat/voice drafts)
9.  Service Management Privilege (escalation level + privilege assignments)
10. Audit Tracking               (field history on chosen Incident fields)

Features 1–8 follow Salesforce Go's IT Service Incident Management page; Service Management Privilege and Audit Tracking aren't on that page.

A priority-tiered SLA needs the Priority Matrix on: with it off, every Incident gets the default priority, so only that tier's milestones fire.

Rules

• ALWAYS show "(via service-itsm-agentic-setup-incident-management)" in the setup header
• ALWAYS check the IT Service Enablement and master-switch prerequisites (Behavior step 2) through the IncidentMgmt SOR before showing the menu or handing off a named feature, unless both were confirmed enabled earlier in this conversation
• ALWAYS ask each off gate with AskUserQuestion (single-select Yes/No), every time, never as plain text, before delegating the enable; No stops and points to Setup
• ALWAYS require exact ENABLED verification for service-cloud-itsm-setup before the Incident switch; anything else stops. Never read or toggle service-cloud-incident-management
• ALWAYS present the feature menu before configuring any selected feature (the master-switch prerequisite is the only permitted action before the menu) — do not assume which feature the user wants, except when the user named a specific feature, in which case go straight to it (single-select is fine)
• ALWAYS pair the rendered feature-menu table with an AskUserQuestion (multiSelect: true) in the same response — the table is the visual view; the tool call is the selection channel
• ALWAYS read a feature's reference file before executing it, follow its rules, and follow the SOR at runtime — never hardcode a route, body, or preference name
• ALWAYS run a feature's SORs under the hand-off protocol; NEVER hand a feature off to another skill, and never follow a SOR's hand-off for either prerequisite gate or for another feature on this menu
• NEVER set up a feature the user did not select; for "set up everything", walk each feature sequentially in recommended order, confirming between each step
• Track progress across the conversation — do not re-present completed features as "Not done"
• Do not show Salesforce record IDs in any output — human-readable names only

Verification checklist

Before emitting any menu or summary, confirm each; adjust the output before sending if any is unchecked.

• The header line ends with (via service-itsm-agentic-setup-incident-management)
• The IncidentMgmt SOR confirmed both prerequisite gates before the menu or direct feature handoff, unless both were already confirmed enabled earlier in this conversation; each off gate was asked with AskUserQuestion (Yes/No), not plain text, before the enable was delegated
• The exact service-cloud-itsm-setup entry verified exact ENABLED before the Incident-switch sequence; any other result stopped
• The feature menu emitted BOTH the ASCII table AND an AskUserQuestion (multiSelect: true) in the same response (single-select only if the user already named a specific feature)
• Each feature row's Status reflects the actual tracked state (Not done, In progress, Done)
• A feature is being handled only because the user explicitly selected it (or is being walked through sequentially with confirmation under an "all" / "everything" request)
• For each feature: its reference file was read and its checks passed; its SORs ran under the hand-off protocol and no other skill was used; live state was read before any write; each write was confirmed and verified by read-back, and a no-write Done came from a live read; one-way / license-ordering invariants were honored
• No Salesforce record IDs appear in the output — human-readable names only

Reference File Index

Read each references/ file before executing its feature.