Service Itsm Incident Priority Configure

Configuring the Incident Priority Matrix (sf CLI)

Configures the Incident Priority Matrix for Salesforce ITSM — the grid that derives an Incident's Priority from its Impact and Urgency. Covers viewing the matrix, enabling / disabling it, adding / changing / removing / seeding cells, toggling the manual-override preference, and reading / setting the default (fallback) priority.

Every read and write dispatches through the `sf` CLI, so this skill works on any org with the Incident Management license enabled.

Writes are idempotent (skipped when the current state already matches the target), the skill always reads before it writes, and an explicit confirm-to-write checkpoint is required before any mutation.

Scope

• In scope (Incident only): view the matrix; enable / disable it; add, change, remove, or seed matrix cells; toggle manual override; read / set the default (fallback) priority.
• Out of scope: Problem and ChangeRequest matrices; non-ITSM Priority pickers; SLA / milestone / entitlement setup; enabling Incident Management itself. If the user asks about Problem or ChangeRequest, stop and say so.

Preconditions

1. sf CLI ≥ 2.60 (verify with sf --version).
2. The target org is authenticated with sf — one of sf org list should show it as Connected.
3. Incident Management is enabled on the org — the master pref for the Service Cloud ITSM Incident feature (Setup Discovery apiName = service-cloud-itsm-incident). Read directly at preflight time via GET /services/data/v67.0/connect/setup/discovery/features and filter to apiName == "service-cloud-itsm-incident" (the setup-org-preferences endpoint for the master is not exposed on this surface — IncidentMgmtEnabled / ITSMIncidentMgmtEnabled both 404). If status != "ENABLED", delegate to service-itsm-incident-mgmt-configure inline to enable it (that skill runs its own read-before-write + confirm-to-write against the same route), then resume Phase 1.
4. The calling user has CustomizeApplication (View Setup + Setup Admin).

If any precondition is unmet, the CLI surfaces the raw error verbatim — do not fabricate state, surface the raw error and stop.

Routes at a glance

Every route is called through the sf CLI. Full method / path / body / response details, the picklist extraction recipe, and gotchas live in references/sf-cli-invocation.md.

Path prefixes are load-bearing — do NOT strip them. Setup Connect API paths MUST start with /services/data/v67.0/. Tooling REST paths MUST start with /services/data/v67.0/tooling/.

Clarifying Questions

Ask only what you cannot infer:

• Which org? sf CLI alias or username (--target-org <alias>). Default: the org's default target.
• What operation? View; enable / disable the matrix; toggle manual override; set the default priority; add / change / remove a cell; seed a full matrix.
• For add / change: the Impact + Urgency coordinates and the resulting Priority (validated against the fetched picklist values).
• For set-default-priority: the target Priority value. If the user did not name one, dispatch AskUserQuestion with the org's active Incident.Priority picklist values as options — never guess.

Workflow

All steps are sequential. Always read before you write. All calls go through sf CLI.

Phase 0 — Reuse what the session already knows

Each Phase 1 / Phase 2 read below carries a skip-if-already-known clause. Before calling any sf command, check whether an earlier turn in this session already produced the same fact from a successful `sf` invocation tied to the current `--target-org` (a prior run of this skill, or an earlier sf call in the same conversation). Session context here is per --target-org <alias>, so a different alias is a different session. An explicit user statement is NOT cache-eligible — the picklist values, pref booleans, matrix rows, and fallback priority all drive client-side validation and duplicate prevention on Phase-4 mutations, so a mistaken or stale user assertion can bypass those safeguards and create invalid or duplicate rows. When the only source is a user statement (or you cannot identify a specific prior sf response), re-read.

• `sf --version` — if the CLI version was already reported this session, skip step 1.
• Incident `describe` (active `Impact` / `Urgency` / `Priority` picklists) — if the Incident describe was already read for the current --target-org this session and the three picklists are in context, skip step 2 and reuse them.
• `IncPriorityMatrixEnabled` / `IncPriorityOverrideEnabled` pref values — if either was already read this session AND has not been PATCHed since, skip its Phase-2 read.
• `ServiceOpPriorityConfig` rows — if the current-org Incident rows were already read this session AND no POST / PATCH / delete on ServiceOpPriorityConfig has been dispatched since, skip step 5 and reuse the row list.
• `StandardValueSet:IncidentPriority` default — if the fallback priority was already read this session AND no StandardValueSet:IncidentPriority deploy has run since, skip step 6.

When in doubt, re-check. Skip only when the fact is unambiguously in context, the --target-org alias is unchanged, and no Phase-4 write since (a pref PATCH, a ServiceOpPriorityConfig POST/PATCH/delete, or a StandardValueSet:IncidentPriority deploy) could have invalidated it. A wrong skip on a live org is worse than a re-read.

Phase 1 — Preflight

1. (Skip if `sf --version` was already reported this session — see Phase 0.) sf --version to confirm the CLI is available.
2. Master Incident Management pref — direct read *(Skip only if the master pref was already read this session for the current --target-org AND the value was ENABLED