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 aPermissionSetAssignment. 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 byDeveloperNamewith noNamespacePrefixfilter. - 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/404surface 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
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
Statusreflects 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