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 — per feature — either delegating to a specialized child skill or executing the feature inline over its system of record (SOR).

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

Delegated features invoke their child skill (this skill only coordinates). Inline features are run by this skill directly through the headless-360 MCP server — read the matching reference file before executing that feature and follow it. Every inline operation is fetched at runtime: discover by intent, describe for the current route/schema/labels, then dispatch_readonly (reads) / dispatch (writes). Hardcode nothing — describe wins.

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 master switch state (reuse 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. Ensure the Incident Management master switch is on (prerequisite)

Every feature below depends on the org-level service-cloud-itsm-incident master switch being enabled. Before showing the menu, delegate to service-itsm-incident-mgmt-configure to read current state; if on, it is a no-op — otherwise it confirms with the user before flipping it. Skip only when the master switch was already confirmed enabled in this session (see step 0). A cached "off"/unknown state MUST fall through to the delegation.

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: if it is a delegated feature, invoke its child skill; if it is an inline feature, read its reference file and execute it there — 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 inline-execution invariants (load-bearing — full detail in each reference)

Apply these whenever an inline feature runs. They are irreversible or silently-wrong if missed.

• Resolve the right node (Preferences). Target the ITSM Incident Management org-preferences node (controller IPCManagementSetupController), not the Service-Foundation look-alike (IncidentMgmtSetupController, broadcast channels + a 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.
• License, not assignment (Major Incident Management). MIM is the approval group + two preferences on top of base Incident Management. The Major Incident Manager grant is a LICENSE (PermissionSetLicenseAssign), never a PermissionSetAssignment. License before group membership; validate group users before designating a group; remove before reassign. Only two preference names are valid: AutoCreationOfProblem, AutoClosureChildIncidents.
• 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.
• 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. The Enable Privilege Assignment master toggle is the UI entry gate (reversible; the controller does not re-check it), so enable it first as workflow ordering, not a hard precondition. No public API substitute exists — a 404 / discover-miss means the surface isn't served on this org yet; 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

1. SLA & Milestones            (time-based commitments on incidents)      [delegated]
2. Priority Matrix             (Impact × Urgency → Incident.Priority)      [delegated]
3. Incident Preferences        (the six per-feature setup toggles)         [inline]
4. Major Incident Management   (approval group + two MIM preferences)      [inline]
5. Incident Persona PSG        (Fulfiller / Manager persona for a user)    [inline]
6. Service Management Privilege (escalation level + privilege assignments) [inline]

Rules

• ALWAYS show "(via service-itsm-agentic-setup-incident-management)" in the setup header
• ALWAYS run the master-switch prerequisite (Behavior step 2) before showing the menu, unless the user already confirmed the switch is on earlier in this conversation
• 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
• For an inline feature, ALWAYS read its reference file first and follow the SOR at runtime — never hardcode a route, body, or preference name
• 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 master switch was confirmed on (via service-itsm-incident-mgmt-configure) before the menu, unless already confirmed earlier in this conversation
• 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 an inline feature: its reference file was read; live state was read before any write; each write was confirmed and verified by read-back; one-way / license-ordering invariants were honored
• For a delegated feature: the child skill was invoked, not configured inline
• No Salesforce record IDs appear in the output — human-readable names only

Reference File Index