Orchestrator skill for setting up Incident Management features in Salesforce Service Cloud ITSM. Use when the user asks to set up incident management, configure ITSM incident features, wants a guided walkthrough of incident management configuration, or asks what incident features are available to co

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 Feature Handled by Reference P Incident Preferences Delegate → IncidentMgmt (its preference steps) references/incident preferences.md 1 Incident Persona PSG Delegate → service itsm incident persona assign references/incident persona psg.md 2 Priority Matrix Delegate → IncidentPriorityMatrix references/priority matrix.md 3 SLA & Milestones Delegate → SLASettings , then sla management setup (custom policy) references/sla milestones.md 4 Incident Dashboards Delegate → itsm incident dashboard enablement (Manager) and itsm incident fulfiller dashboard enablement (Fulfiller) references/incident dashboards.md 5 Email to Incident Delegate → EmailToIncident references/email to incident.md 6 Major Incident Management Delegate → MIM references/major incident management.md 7 Broadcast Communications Delegate → service itsm broadcast communications setup references/broadcast communications.md 8 Manage Incidents with AI Delegate → service itsm manage incidents with ai configure references/manage incidents with ai.md 9 Service Management Privilege Delegate → ServiceMgmtPrivilegeSetup references/service mgmt privilege.md 10 Audit Tracking Delegate → FieldHistoryTracking references/audit tracking.md 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 v

service-itsm-agentic-setup-incident-management