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

#	Feature	Handled by
1	SLA & Milestones	Delegate → service-itsm-agentic-setup-incident-sla-configure
2	Priority Matrix	Delegate → service-itsm-incident-priority-configure
3	Incident Preferences	Inline over SOR → references/incident-preferences.md
4	Major Incident Management	Inline over SOR → references/major-incident-management.md
5	Incident Persona PSG	Inline over SOR → references/incident-persona-psg.md
6	Service Management Privilege	Inline over SOR → references/service-mgmt-privilege.md

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

File	When to read
examples/output-templates.md	Behavior steps 3, 5, 6 — feature menu (multi-select), post-feature progress, completion summary
references/incident-preferences.md	Before executing the Incident Preferences feature — the six preferences, the one-way rules, the SOR delegation map, invariants, and failure taxonomy
references/major-incident-management.md	Before executing the Major Incident Management feature — the two surfaces (approval group + preferences), licensing preconditions, ordering, invariants
references/incident-persona-psg.md	Before executing the Incident Persona PSG feature — the two persona PSGs, PSL-before-PSG ordering, resolution rules, invariants
references/service-mgmt-privilege.md	Before executing the Service Management Privilege feature — the Enable Privilege Assignment toggle, escalation level, privilege CRUD (destructive delete), bulk assignments (no read-back), and the SOR step map