@salesforce/afv-skills 1.66.0 → 1.67.0

package/skills/service-itsm-agentic-setup-incident-management/references/broadcast-communications.md

@@ -0,0 +1,23 @@
+# Feature: Broadcast Communications (delegated to the `service-itsm-broadcast-communications-setup` SOR)
+
+How the orchestrator runs the **Broadcast Communications** feature over the
+`service-itsm-broadcast-communications-setup` SOR — never the Service-Foundation `IncidentManagement`
+look-alike's broadcast toggles. The SOR's own steps and guidance decide *how*; the orchestrator runs them
+itself under its **SOR hand-off protocol** and owns every user-facing gate. This file adds what is specific
+to Broadcast Communications.
+
+1. `discover` the SOR by intent (e.g. "set up ITSM broadcast communications") and `describe` the id
+   `discover` returns. Its own prerequisite checks fall under protocol step 2.
+2. **Phase 1 — turn it on, before asking about anything else.** Read the feature (`get-feature-status`).
+   Already on → Phase 2 with no question. Non-empty `enableBlockedReasons` or `dependencyStatuses` → name
+   the unmet prerequisite in plain language and stop. Otherwise say it's off and that turning it on **can't
+   be undone** (Salesforce Go has no way to turn it off), get an explicit yes, run `enable-feature`, and
+   require `verify-enabled` to read it on. Never turn the feature off, even when asked — offer to turn off a
+   channel or object, or to revoke sender access, instead.
+3. **Phase 2 — configure only what the user picks** (`AskUserQuestion`, multi-select; never everything by
+   default): **sender access** for the users they name (resolve each name, username, or email to exactly
+   one user, or ask; the license goes on before the *Broadcast Communication Sender* permission set, a
+   duplicate is success, and only that permission set is ever assigned), **channels** (Email, In-app,
+   Slack, Microsoft Teams — Slack delivers only with a connected Slack org), and **objects** (Incident,
+   Change Request). For each: read, skip it if already set, confirm, write, and read back.
+4. This is setup only — it sends no broadcast.

package/skills/service-itsm-agentic-setup-incident-management/references/email-to-incident.md

@@ -0,0 +1,23 @@
+# Feature: Email-to-Incident (delegated to the `EmailToIncident` SOR)
+
+How the orchestrator runs the **Email-to-Incident** feature, which turns incoming email into Incidents. The
+`EmailToIncident` SOR's own steps and guidance decide *how*; the orchestrator runs them itself under its
+**SOR hand-off protocol** and owns every user-facing gate. This file adds what is specific to
+Email-to-Incident.
+
+1. `discover` the SOR by intent (e.g. "email to incident settings routing address") and `describe` the id
+   `discover` returns (`EmailToIncident`).
+2. **Settings.** Read them (`get-email-to-incident-setting`) and ask which to change. Turning on
+   Email-to-Incident itself (`enableEmailToIncident`) **can't be undone** — say so before asking. The save
+   (`save-email-to-incident-setting`) replaces the whole settings map: send back every field the read
+   returned (the set differs by release), changing only what the user chose, and on releases that have
+   them, the draft-email, sender-error-notification, and signature settings each need Email-to-Incident on.
+   Validate any choice-list value against the SOR's value-set reads. Confirm the full before → after
+   change, save, and read back with `verify-save-setting`.
+3. **Routing addresses — only if the user wants them.** List the existing addresses
+   (`get-all-routing-addresses`) and the assignable queues (`get-incident-queue-ids`, the only source for
+   the assignee), then create or update one with the user's routing name, email address, and default
+   Urgency and Impact (the org's picklist values). An update replaces the whole row, so send every field.
+   Read each change back with its `verify-*-routing-address` step. A delete is **irreversible** — confirm
+   it explicitly. Re-sending an address's verification email sends a real email: do it only on an explicit
+   request.

package/skills/service-itsm-agentic-setup-incident-management/references/incident-dashboards.md

@@ -0,0 +1,25 @@
+# Feature: Incident Dashboards (delegated to two SORs, one per persona)
+
+How the orchestrator runs the **Incident Dashboards** feature over `itsm-incident-dashboard-enablement`
+(Incident Manager) and `itsm-incident-fulfiller-dashboard-enablement` (Incident Fulfiller). Each SOR's own
+steps and guidance decide *how*; the orchestrator runs them itself under its **SOR hand-off protocol** and
+owns every user-facing gate. This file adds what is specific to the dashboards.
+
+1. Unless the user already said, ask which (`AskUserQuestion`): the **Incident Manager** dashboards (the
+   Incident Manager dashboards and the Home page dashboards — `itsm-incident-dashboard-enablement`), the
+   **Incident Fulfiller** dashboards (the fulfiller work view and the fulfiller Home page —
+   `itsm-incident-fulfiller-dashboard-enablement`), or both. `discover` and `describe` each chosen SOR
+   (e.g. "turn on incident manager dashboards", "turn on incident fulfiller dashboards").
+2. Each SOR turns on two org preferences, one at a time. `check-dashboard-preference` first confirms that
+   Dynamic Dashboards for IT Service (`service-cloud-itsm-dashboard`) reads exactly `ENABLED`; it turns on
+   with IT Service Enablement, so never enable it or ask about it, and any other result stops the feature.
+   Then read each preference, skip any already on, ask the SOR's question before each write that turns one
+   on (`update-dashboard-preference`), and read each back (`verify-dashboard-preference`). Turn on only the
+   persona the user chose.
+3. After both preferences of a SOR are handled, run its `verify-dashboards-materialized` query. The
+   dashboards deploy asynchronously, so report the titles it finds; if they are still missing after its
+   retries, say the preference is set but the dashboards are not confirmed to exist, give the user the same
+   query, and point them to All Dashboards (App Launcher → Dashboards). A user sees the dashboards only
+   with the ITSM console-view permission (a separate grant). If the write returns a dynamic-dashboard limit
+   error, report it: freeing a slot (converting a dynamic dashboard to static, or deleting an unused one) is
+   a manual admin step — never retry or remediate it here.

package/skills/service-itsm-agentic-setup-incident-management/references/incident-persona-psg.md

@@ -1,118 +1,31 @@
-# Feature: Incident Persona PSG Assignment (inline execution)
-
-How the orchestrator executes the **Persona** feature — granting a **specific user** an ITSM Incident
-Management **persona** by assigning the persona's **permission set group (PSG)** (the **Incident Fulfiller**
-or **Incident Manager** bundle) together with the **backing permission-set licenses** its member permission
-sets require. This runs **inline** through the Salesforce-hosted **`headless-360`** MCP server (server key
-`headless-360`) via its four meta-tools (`discover`, `describe`, `dispatch_readonly`, `dispatch`). The org
-comes from the OAuth JWT on the MCP session — never handle an org id, alias, or credentials. Minimum API
-version **67.0**.
-
-## Delegate to the Setup Operation Recipes
-
-Every operation is delegated to a Setup Operation Recipe (SOR) and its exact shape is fetched at runtime —
-`discover` by intent, `describe` the SOR step for its **current** route, method, and argument schema, then
-`dispatch_readonly` (reads) / `dispatch` (writes). **Hardcode no routes, SOQL, or request bodies; use what
-`describe` returns, and if it disagrees with anything here, `describe` wins.** Discover by intent, not by
-id; a `discover` miss is not proof an operation is unavailable.
-
-| SOR | Owns | Status |
-|-----|------|--------|
-| **`PermSetGroups`** (approved) | Assigning a PSG to a user; listing a user's PSG assignments | Served today |
-| **ITSM incident-persona assignment SOR** | Resolving the incident persona PSGs; resolving the target user; resolving a PSG's member permission sets + their backing licenses; assigning the backing permission-set licenses; the license-seat check; read-back verification | Being onboarded separately. Until served, resolve these via the standard Salesforce Data API **by intent** — the objects and invariants are named below; never via a route written here |
-
-Discover each by intent — e.g. `discover("assign a permission set group to a user")` for the assignment,
-`discover("assign the backing permission-set licenses of an incident persona PSG")` for the license recipe.
-
-> **Load-bearing trap the SOR does not encode.** Assigning the PSG *alone* sticks the assignment, but any
-> permission in a member set whose backing **permission-set license (PSL)** the user lacks **never
-> activates** — the persona is silently half-provisioned, and Salesforce does not auto-assign a PSG's
-> member PSLs. **Assign the union of the member sets' backing PSLs first, then the PSG.** The PSL set
-> differs per PSG and the Ids differ per org, so resolve it at runtime — never hardcode it.
-
-## The two Incident Management persona PSGs
-
-Both are Core-shipped in namespace `force` — query by `DeveloperName` with **no** `NamespacePrefix` filter
-(which would exclude them). Resolve each PSG's Id, its member permission sets, and their backing license Ids
-at **runtime**.
-
-| Persona | PSG (`DeveloperName`) | Grants |
-|---------|-----------------------|--------|
-| Incident Fulfiller | `IncidentFulfillerPSG` | Work incidents as a fulfiller (incident + problem/change/release associators, major-incident proposer) |
-| Incident Manager | `IncidentManagerPSG` | Manage the incident-management process and its records |
-
-The **Major Incident Manager** PSG (`MajorIncidentManagerPSG`) is **out of scope** here (its approver
-licensing is part of the orchestrator's **Major Incident Management** feature).
-
-## Scope
-
-- **In scope**: resolving which incident persona PSG(s) exist on the org; resolving the target user;
-  resolving each chosen PSG's member permission sets and their backing licenses at runtime; checking
-  existing assignments (idempotency); assigning the missing backing PSL(s) and then the PSG; verifying by
-  read-back.
-- **Out of scope**: the **Major Incident Manager** PSG; creating / editing / recalculating a PSG or its
-  membership; enabling ITSM / incident-management features (the `IncidentMgmt` SOR's master-feature steps); the
-  `IncidentFulfiller` permission **set** for the Fulfiller **agent's** access
-  (`service-itsm-agentic-setup-itsm-agentforce-permset-assign`); CMDB access
-  (`service-itsm-agentic-setup-cmdb-access-assign`); generic, non-incident permission-set / PSG assignment
-  (`dx-org-permission-set-assign`).
-
-## Preconditions
-
-- **ITSM Incident Management must be provisioned** — the incident persona PSGs must exist on the org. If
-  neither is found, **stop and report that the personas are not provisioned**; the master-feature
-  prerequisite is handled by the orchestrator, but enabling it does not prove the PSGs exist.
-- **The acting user must be able to assign permission sets** (the SOR gates writes on it). A write that
-  fails with an access error that is not a duplicate → surface it plainly and stop; an admin must do it.
-- **Each backing license consumes a seat.** A seat-exhausted license blocks that persona; report it.
-
-## Operations (shapes come from `describe`)
-
-1. **Resolve which incident persona PSGs exist (read).** Look up the two PSGs by `DeveloperName`
-   (`IncidentFulfillerPSG`, `IncidentManagerPSG`) with **no `NamespacePrefix` filter**. None found →
-   stop and report that the personas are not provisioned. Capture each PSG's Id and status.
-2. **Resolve the target user (read).** To exactly one active user. For "me" / "the current user", read the
-   API root's identity (the running user's `005…` Id) — **not** the `USER_ID()` SOQL function (Apex-only)
-   and **not** the Chatter current-user endpoint (fails when Chatter is off). Zero / multiple → disambiguate.
-3. **Resolve the chosen PSG's member licenses (read).** From the PSG's member permission sets, collect the
-   **distinct, non-null backing permission-set-license Ids** — the link is each member permission set's
-   `LicenseId`. Do **not** traverse the license's `Name`/`DeveloperName` from the member (that relationship
-   rejects); resolve the license label separately by Id. No members → the bundle is empty; surface and stop.
-4. **Check existing assignments (read — idempotency).** Whether the PSG is already assigned, and which
-   backing licenses the user already holds. Write only what is missing.
-5. **Assign the missing backing licenses, then the PSG (write — confirm first).** Assign each **missing
-   backing license first**, then the PSG (keyed on `PermissionSetGroupId`). A duplicate = already-assigned
-   (idempotent success). A seat/limit error on a license = exhausted; stop and report — do not retry.
-6. **Verify (read).** Re-read the PSG assignment and every backing license for the user, and re-read the
-   PSG's status. Provisioned only when all read back. If `Status` is still `Updating`, tell the user
-   effective permissions are settling and will be active shortly.
-
-If the user picks **both** personas, run steps 3–6 once **per PSG** (the bundles have different member
-licenses) and report each.
-
-## Invariants — the contract (these do NOT come from `describe`)
-
-- **Assign the backing licenses before the PSG — correctness ordering, not a platform gate.** The PSG
-  sticks on its own, but any member-set permission whose backing license the user lacks **never activates**.
-  Salesforce neither rejects the PSG assignment for a missing license nor auto-assigns the licenses.
-- **A PSG assignment keys on the permission-set-*group* Id, never a permission-set Id.**
-- **Query the persona PSGs by `DeveloperName` with no `NamespacePrefix` filter** (namespace `force`).
-- **Idempotent** — read before every write; a duplicate is already-assigned success, not a failure.
-- **The PSG recalculates asynchronously** after an assignment; effective permissions can be stale until its
-  status settles.
-- **Verify by read-back** — the write response alone is not proof (half-provisioning / recalculation).
-- **Resolve the backing-license set at runtime** — it differs per PSG and Ids differ per org; never hardcode.
-
-## Clarifying questions
-
-- **Which user?** A username / name / email resolving to exactly one active user; for "me", the running user.
-- **Which persona(s)?** For a generic request, do **not** auto-select — present an `AskUserQuestion` menu of
-  the incident PSGs that **exist on the org** (Fulfiller = work incidents; Manager = manage the process),
-  multi-select (one or both). Never offer the Major Incident Manager PSG.
-- **Which org?** Confirm it and state plainly the org will be **modified** (a PSG + licenses are writes;
-  each license consumes a seat). For production, get explicit confirmation.
-
-## Output expectations
+# Feature: Incident Persona PSG (delegated to the `service-itsm-incident-persona-assign` SOR)
+
+How the orchestrator runs the **Incident Persona PSG** feature: giving one user the **Incident Fulfiller**
+or **Incident Manager** persona — its permission set group (PSG) plus the permission-set licenses its
+member sets need. The `service-itsm-incident-persona-assign` SOR's own steps and guidance decide *how* —
+the PSG lookup, the user and license resolution, licenses before the PSG, and the read-back; the
+orchestrator runs them itself under its **SOR hand-off protocol** and owns every user-facing gate. This file
+adds what is specific to the personas.
+
+1. `discover` the SOR by intent (e.g. "assign the Incident Fulfiller or Incident Manager persona to a
+   user") and `describe` the id `discover` returns (`service-itsm-incident-persona-assign`).
+2. Find the personas (`resolve-incident-persona-psgs`). If neither PSG exists, stop and report that the
+   incident personas aren't provisioned on this org. Don't follow the hand-off that step names for this
+   case: Behavior step 2 already confirmed Incident Management is on, and turning it on doesn't prove the
+   PSGs exist.
+3. Unless the user named one, ask which persona (`AskUserQuestion`, multi-select), offering only the PSGs
+   that exist — Fulfiller works incidents, Manager runs the process. Never auto-select, and never offer the
+   Major Incident Manager PSG (that approver license is part of **Major Incident Management**). Resolve the
+   user to exactly one active user (`resolve-target-user`, or `resolve-current-user` for "me"); on zero or
+   several matches, ask.
+4. For each chosen PSG, separately: resolve its backing licenses, check what the user already has, and check
+   seats only on the licenses still missing — a license the user already holds needs no free seat. If the
+   PSG has no member sets, say so and stop that persona. Confirm the exact grants and that this org is
+   modified (each license uses a seat; explicit confirmation for production), then run
+   `assign-backing-psl`, `assign-persona-psg`, and `verify-persona-assignment`.
+5. Report with the block below — one `Persona:` block per PSG — only what read-back confirmed. If the PSG's
+   status still reads `Updating`, the grant is in place and its permissions are settling: say so rather than
+   failing it. An access error that isn't a duplicate means an admin must make the assignment.
 
 ```text
 Incident Management Persona Assignment
@@ -124,34 +37,5 @@ Persona: <Incident Fulfiller | Incident Manager>
   Effective permissions ............. Active | Recalculating (settles shortly)
 ```
 
-Repeat the `Persona:` block per PSG if both were chosen. Report only what read-back confirmed. If the
-personas are not on the org, say so without claiming master enablement will provision them.
-
-## Common failures (surface in plain language)
-
-| Symptom | Likely cause | What to tell the user |
-|---------|--------------|-----------------------|
-| No incident PSG on the org | Incident persona PSGs not provisioned | The incident personas aren't set up yet — stop and report the missing PSGs |
-| Duplicate on assign | User already has that grant | Not an error — report as already assigned |
-| Seat / limit error on a license | An incident license has no free seats | A seat must free up (or more licenses added); the persona is incomplete without it |
-| PSG assigned but some actions missing | A backing license wasn't assigned, or the PSG is still recalculating | Confirm every backing license is assigned; if it's settling, retry in a moment |
-| Access error on the PSG write (not a duplicate) | Acting user can't assign permission sets | An admin must grant that or perform the assignment |
-| `dispatch*` auth error | headless-360 session not authenticated / expired | Re-authenticate the connection and confirm it points at the intended org |
-
-## Reading `dispatch` results
-
-Responses come back wrapped as `{ status_code, body }`; read what you need from `body`. A write success is a
-created record. A `400` carrying a duplicate code = already-assigned (treat as success). A seat/limit error
-on a license = no free seats (report used-vs-total; do not retry). An access error that is **not** a
-duplicate on the PSG write = the acting user can't assign permission sets (an admin must). A `404` = the
-operation isn't available on this org.
-
-## Dead ends — do NOT do these
-
-- Assign the PSG with a permission-set Id — a PSG assignment keys on the group Id.
-- Assign the PSG without its members' backing licenses — it silently half-provisions the persona.
-- Hardcode the backing-license list, or add a `NamespacePrefix` filter to the PSG lookup.
-- Create, edit, or recalculate the PSG or its membership — this feature only **assigns** the standard
-  incident PSGs.
-- Retry a write that failed with a seat/limit error — the shortage is real; surface it.
-- Write a route, SOQL string, or request body here — delegate to the SOR and let `describe` carry the shape.
+This feature only assigns the two standard persona PSGs — it never creates, edits, or recalculates a PSG,
+and it assigns no other permission set.

package/skills/service-itsm-agentic-setup-incident-management/references/incident-preferences.md

@@ -1,107 +1,35 @@
-# Feature: Incident Management Preferences (inline execution)
-
-How the orchestrator executes the **Preferences** feature — reading and setting the **six per-feature
-Incident Management preferences** (the feature toggles on the Incident Management setup page). This runs
-**inline** through the Salesforce-hosted **`headless-360`** MCP server (server key `headless-360`) via its
-four meta-tools (`discover`, `describe`, `dispatch_readonly`, `dispatch`). The org comes from the OAuth JWT
-on the MCP session — never handle an org id, alias, or credentials. Minimum API version **67.0**.
-
-This is **not** the master Incident Management on/off switch (the master-feature steps of the `IncidentMgmt` SOR) nor
-the Incident Priority Matrix (`service-itsm-incident-priority-configure`).
-
-## Delegate to the Setup Operation Recipe
-
-Every operation is delegated to a Setup Operation Recipe (SOR) and its exact shape is fetched at runtime:
-`discover` the operation by intent, `describe` the SOR for its **current** steps, routes, argument schema,
-the preference list, the on-screen labels, and its `agent_guidance`, then `dispatch_readonly` (reads) /
-`dispatch` (writes). **Hardcode no routes, preference names, labels, or request bodies — use what
-`describe` returns, and if it disagrees with anything here, `describe` wins.** Discover by intent, not by
-id; a `discover` miss is not proof an operation is unavailable.
-
-| SOR | Owns | Status |
-|-----|------|--------|
-| **`IncidentMgmt`** | Read a preference; toggle a preference; verify a preference read-back | Served |
-
-Discover by intent — e.g. `discover("configure ITSM incident management preferences: automatically triage
-incidents, assign incidents with Einstein, enable rich text for incident descriptions")`.
-
-> **Resolve the right node — load-bearing.** Two setup nodes share the "Incident" name. Target the
-> **ITSM Incident Management org-preferences** node whose toggles are the six below — **not** the
-> Service-Foundation "Incident Management" node, whose toggles are broadcast/notification channels
-> (Email/Sites/Alerts/Slack). The `IncidentMgmt` SOR also owns the master on/off switch; a `discover`
-> result about broadcast channels is the wrong node.
-
-## Operations (shapes come from `describe`)
-
-1. **Read a preference (read).** Given a preference name, return its Boolean state. Unknown names are **not
-   validated on read** — they return `false` rather than raising — so only ever read a preference the SOR
-   lists; a `false` read is not proof a name is valid.
-2. **Toggle a preference (write — confirm first).** Set a named preference enabled/disabled. An unknown
-   name raises. The two one-way preferences cannot be set to disabled.
-3. **Verify (read).** Read the changed preference back and expect it to equal the value just set.
-
-## The six preferences (name → label; `describe`/`agent_guidance` is authoritative)
-
-| Preference name | Setup label | One-way |
-|-----------------|-------------|---------|
-| `IncidentValidationsEnabled` | Default Field Validations for Incidents | No |
-| `AutoClosureChildIncidents` | Automatically Close Child Incidents | No |
-| `IncidentTriageAgentEnabled` | Automatically Triage Incidents | No |
-| `IncAssignWithAgentEnabled` | Assign Incidents with Einstein | No |
-| `AssignedGroupValidationEnabled` | Restrict Assigned Group to Regular Groups | **Yes** |
-| `RtaIncidentDescEnabled` | Enable Rich Text for Incident Descriptions | **Yes** |
-
-Read the live list and labels from `describe` at runtime — this table is the authoring snapshot for trigger
-phrasing and the known-name enumeration.
-
-## Invariants — the contract
-
-- **Two preferences are one-way / enable-only:** `RtaIncidentDescEnabled` and
-  `AssignedGroupValidationEnabled`. Once enabled they cannot be disabled. Never offer to disable them;
-  require an explicit "I understand this can't be undone" confirmation before enabling; never enable one
-  merely to test.
-- **`AssignedGroupValidationEnabled` also freezes once the org has any Incident record** — it is settable
-  only while the org has no incidents. An enable can therefore **fail outright** when incidents already
-  exist; surface pre-existing incidents as the likely cause and do **not** retry.
-- **Read does not validate the preference name** (unknown → `false`, no error); only the write is
-  allowlisted (unknown → raises). Enumerate only the six the SOR lists.
-- **Access gate:** the caller needs `IncidentMgmt.userHasITSMSetupAccess` (sysadmin OR Customize
-  Application + Modify All Data + View Setup). Without it every read and write is blocked by the controller.
-- **Idempotent** — read before every write; skip a write when the preference is already in the requested
-  state.
-- **Verify by read-back** — the write response alone is not proof the change persisted.
-
-## Preconditions
-
-- **Setup access**: the caller needs ITSM setup access. Without it every read and write is blocked —
-  surface the raw access error and stop.
-- **Incident Management provisioned**: these preferences are writable only when Incident Management is
-  enabled at the feature/license level. If reads or writes fail with an availability error, say the feature
-  must be enabled first (the `IncidentMgmt` SOR's master-feature steps) and stop.
-
-## Workflow
-
-The SOR's `agent_guidance` (returned by `describe`) carries the detailed flow and current labels; follow
-it. In outline — **read before you write, confirm before every write, verify every write by read-back**,
-and act only on the preferences the user chose:
-
-1. **Read current state** — read each of the six preferences and report which are on and which are off,
-   flagging the two one-way ones.
-2. **Ask which to change** — never infer; for a one-way enable, take the explicit can't-be-undone
-   confirmation here. On any non-yes, stop without writing.
-3. **Apply only the chosen preferences** — skip any already in the requested state (idempotent no-op).
-4. **Verify** — read each changed preference back; report success only when it read back as set.
-
-## Clarifying questions
-
-- **Which preference(s)?** If unstated, present the six (by label, flagging the two one-way) and let the
-  user pick.
-- **Enable or disable?** Required for a change; never infer direction from current state. Disable is not
-  offered for the two one-way preferences.
-- **Which org?** Confirm it and state plainly the org will be **modified**. For production, get explicit
-  confirmation. Enabling a one-way preference is permanent.
-
-## Output expectations
+# Feature: Incident Preferences (delegated to the `IncidentMgmt` SOR)
+
+How the orchestrator runs the **Incident Preferences** feature: the six per-feature toggles on the ITSM
+Incident Management setup page. The `IncidentMgmt` SOR's own steps and guidance decide *how* — the six
+preference names and labels, the two one-way ones, and the read-back; the orchestrator runs them itself
+under its **SOR hand-off protocol** and owns every user-facing gate. This file adds what is specific to the
+preferences.
+
+1. `discover` the SOR by intent (e.g. "configure ITSM incident management preferences: automatically triage
+   incidents, assign incidents with Einstein") and `describe` the id `discover` returns (`IncidentMgmt`) —
+   never the Service-Foundation `IncidentManagement` look-alike, whose toggles are broadcast channels.
+2. Behavior step 2 already ran this SOR's IT Service Enablement and Incident Management steps, so start at
+   its preference flow: read (`getOrgPref_1`), change (`updateOrgPref_2`), read back
+   (`verify-update-org-pref`). Never run its `disable-itsm-incident-feature` /
+   `verify-itsm-incident-feature-disabled` steps (the master switch is not part of this feature) or
+   `delegate-email-to-incident` (that is the **Email-to-Incident** feature).
+3. Read all six and show them with the block below, flagging the two one-way ones. Ask which to change and
+   in which direction (`AskUserQuestion`) — never infer the direction from the current state, and never
+   offer to turn a one-way preference off. Skip any already in the requested state.
+4. Confirm the exact change and that this org is modified (explicit confirmation for production). For
+   *Restrict Assigned Group to Regular Groups* or *Enable Rich Text for Incident Descriptions*, the
+   confirmation must say it can't be undone. Write each chosen preference and read each back; mark the
+   feature `Done` only when every read-back matches.
+5. In plain language: a failed enable of *Restrict Assigned Group…* means the org already has incidents, so
+   it can't be turned on now — don't retry. If *Automatically Triage Incidents* or *Assign Incidents with
+   Einstein* can't be read or turned on, the org lacks that switch's license (*IT Services: Agentforce
+   Features for Employees* for triage, *IT Services: Einstein Features* for Einstein assignment): say so,
+   skip it, and carry on with the others.
+6. *Automatically Triage Incidents* and *Assign Incidents with Einstein* are also two of the three switches
+   of the **Manage Incidents with AI** feature — the same org preferences — so one set in either feature
+   reads as already set in the other. That feature's third switch, *Report Incidents from Chat or Voice
+   Using AI*, is not one of the six.
 
 ```text
   Default Field Validations for Incidents ...... On | Off
@@ -113,35 +41,3 @@ and act only on the preferences the user chose:
 
 Changed: <label> Off → On (SUCCEEDED | ALREADY-ON | FAILED)
 ```
-
-Report only what read-back confirmed. On a failure, stop and say — in plain language — what did not succeed
-and what it means (e.g. "that setting can't be turned on once incidents exist").
-
-## Common failures (surface in plain language)
-
-| Symptom | Likely cause | What to tell the user |
-|---------|--------------|-----------------------|
-| Enable of "Restrict Assigned Group…" fails | The org already has Incident records (server freezes it) | That setting can only be turned on before any incidents exist; it can't be enabled now |
-| Read/write blocked with an access error | Caller lacks ITSM setup access | An admin with setup access must make this change |
-| Read/write unavailable on the org | Incident Management not enabled | Enable Incident Management first through the `IncidentMgmt` SOR's master-feature steps |
-| Change didn't persist on read-back | Write did not take | Report it as failed and show the current state; do not claim success |
-| `dispatch*` auth error | headless-360 session not authenticated / expired | Re-authenticate the connection and confirm it points at the intended org |
-
-## Reading `dispatch` results
-
-Responses come back wrapped as `{ status_code, body }`; read what you need from `body`. A preference read
-returns a Boolean in `body`. A write success persists (no meaningful body). A service error on a write =
-either a preference name outside the six, **or** a one-way freeze (e.g. `AssignedGroupValidationEnabled`
-with incidents already present) — surface the specific cause, do not retry blindly. A `401` / `403` =
-missing setup access or an unauthenticated session. A `404` = the operation is not available on this org
-(feature not enabled).
-
-## Dead ends — do NOT do these
-
-- Write an HTTP route or a request body here — delegate to the SOR and let `describe` carry the shape.
-- Offer to disable a one-way preference, or enable one just to "test" it.
-- Read or write against the Service-Foundation `IncidentManagement` node (broadcast channels) — wrong node.
-- Read or write any preference name the SOR does not list — an unknown name reads as `false` and is
-  rejected on write.
-- Toggle the **master** Incident Management switch as part of this preferences feature (use the orchestrator's prerequisite over the `IncidentMgmt` SOR) or the
-  **Incident Priority Matrix** (`service-itsm-incident-priority-configure`).