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 it (to a specialized child skill, or to a Setup Operation Recipe (SOR) whose own steps this skill follows), or executing it inline from this skill's reference file over its 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
7	Audit Tracking	Delegate → FieldHistoryTracking (the Field History Tracking SOR)

Delegated features hand off to their child skill or SOR. A child skill runs its own confirmations and read-backs, so this skill only coordinates. A SOR is a recipe, not an agent: for a SOR hand-off this skill runs the SOR's steps itself and owns the confirmation and read-back (see the master switch and Audit Tracking below). 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.

Audit Tracking is delegated to the Field History Tracking SOR. This skill has no reference file for it and re-derives none of its steps — the SOR's own steps and guidance decide how. This skill runs them and owns the user-facing gates:

1. discover the SOR by intent (e.g. "field history tracking") and describe the id discover returns (FieldHistoryTracking). 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. Use the Incident fields the user already named, or ask which fields to track if the choice is missing or ambiguous, plus anything else describe says it needs. If the user chooses no fields, leave the feature Not done and stop; do not treat an empty choice as already configured.
3. Through the SOR, check Setup access, read Incident with get-single-entity-data-with-metadata, and get its per-object tracked-field limit. Use the returned tracking flag, field labels, canBeTracked values, current tracked set, and fieldEnumOrId keys to resolve the user's choices; do not guess field keys.
4. The save replaces the object's whole tracked-field set, so send the union of what's already tracked and the chosen fields using their returned keys, with Incident's object-level tracking flag on — never drop an already-tracked field unless the user asks. If a chosen field can't be tracked, or the union would exceed the limit, say so plainly; never untrack another field to make room. Report it as done with no write only if the nonempty chosen set is already tracked and Incident's object-level tracking is on. If the fields are selected but that flag is off, the change still needs a save.
5. Show the exact final tracked-field list by field label (disambiguate matching labels) in either case. Before any save, also show that object-level tracking will be enabled and get an explicit yes (AskUserQuestion) for that plan; when the user already named the fields, this confirms the selection.
6. After any save, read Incident's tracked fields back through the SOR. Mark the feature Done only when the live read (for the no-write case) or post-save read-back shows Incident's object-level tracking on, the chosen fields tracked, and no field dropped that the user didn't ask to drop — a save 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 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, discover the IncidentMgmt SOR by intent and describe its master-feature steps (read-itsm-incident-feature-status, enable-itsm-incident-feature, verify-itsm-incident-feature-status). Follow its current invocation and prefix the stored path as its version note says (v67.0 is the minimum and a safe default). A 404 from a version above the org's maximum is a version mismatch: retry once at v67.0 before treating 404 as unavailable. Do not use the Service-Foundation IncidentManagement look-alike or its broadcast toggles. Read the master status via dispatch_readonly and decide on status first: ENABLED is an idempotent no-op even if enableBlockedReasons is non-empty; NOT_AVAILABLE means halt (do not attempt enable); for NOT_ENABLED, surface any enableBlockedReasons as plain text (their messages are HTML-escaped markup) and halt if present. Otherwise show the exact off → on change and ask for explicit confirmation before running the SOR's enable step via dispatch. Re-read via the SOR's verify step and require ENABLED before continuing. On a declined confirmation, unexpected status, 401/403/404, failed write, or read-back mismatch, stop without showing the menu; never infer success from the write response. 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 live read.

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, hand off to its child skill — or, for Audit Tracking, run the Field History Tracking SOR through the six steps above; if it is an inline feature, read its reference file and execute it there. Whenever this skill itself writes (inline, or a SOR hand-off), 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; the Everywhere rules also apply to the Audit Tracking SOR hand-off. 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.
• 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]
7. Audit Tracking              (field history on chosen Incident fields)   [delegated]

---

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 a live status read already confirmed the switch ENABLED on this org earlier in this session
• 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
• For Audit Tracking, ALWAYS keep every already-tracked Incident field in the save unless the user asked to stop tracking it, confirm the exact final field list before the save, and verify by read-back before marking it Done (or verify the already-configured state by live read with no write) — the SOR asks the user nothing itself
• 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 the IncidentMgmt SOR status/verify steps) before the menu, unless a live read already confirmed it ENABLED on this org earlier in this session
• 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 (or, for Audit Tracking, the Field History Tracking SOR) was used, not configured inline
• For Audit Tracking: a live metadata read resolved the fields and complete labeled set; any save kept every already-tracked field the user didn't ask to drop, was confirmed before it ran, and was verified by read-back; a no-write Done also had Incident's object-level tracking confirmed on
• 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