@salesforce/afv-skills 1.44.0 → 1.45.0

package/skills/service-itsm-agentic-setup-incident-sla-configure/assets/predefined-incident-policy.json

@@ -0,0 +1,120 @@
+{
+  "_comment": "Out-of-box 'Standard Support for Incidents' predefined SLA policy — the exact template Salesforce ITSM seeds when a customer clicks 'Create Predefined Policies' in Setup (Incident process type only). Source of truth for Phase 2-OOB. This is a DATA template, not a ready-to-POST body: substitute <businessHoursId> / <AccountId> at runtime and translate the criteria per the recipe in references/mcp-invocation.md (Predefined Incident Policy). Modeled on core service-itsm-impl default-sla-policies/incident.json + shared_core_ui_labels/incident-management.xml (DefaultSeededSla). The core template groups Moderate+Low into one Priority In[Moderate,Low] tier (6 milestones); this template expresses it as 8 milestones (Moderate and Low as separate Priority Equals rows) because the public /connect/sla-management milestone-criteria route has no In operator — behavior-equivalent, and this is the shape the headless seed produces.",
+
+  "policy": {
+    "name": "Standard Support for Incidents",
+    "description": "Standard Support for Incidents",
+    "processType": "Incident",
+    "businessHourId": "<default active BusinessHours Id>",
+    "createdDateEntryCriteria": true,
+    "closedExitCriteria": true,
+    "versionDefault": true,
+    "active": true,
+    "_recordTypeApplied": false,
+    "_slaType": "SLA",
+    "_activeNote": "The OOB backend creates the SlaProcess with active:false, then flips it active:true during auto-entitlement activation. When replicating via the public /connect/sla-management/sla-policies POST, create it directly with active:true (same as the custom Phase 2 flow) to avoid the Connect activate PATCH, which can 500 headless."
+  },
+
+  "_milestoneTypesNote": "DETECT BEFORE CREATE. Enabling the SLA Management feature pre-seeds a default MilestoneType catalog (commonly First Response, Follow Up, Periodic Update, and Resolve Within). A blind POST for a name that already exists returns HTTP 500 ('already exists') and half-seeds the policy. First read the catalog (SOQL SELECT Id, Name FROM MilestoneType WHERE Name IN ('Acknowledge Within','Resolve Within'), or GET .../milestone-types), reuse any match by id, and POST only the missing name(s). See references/mcp-invocation.md (Predefined Incident Policy, seed step 1).",
+  "milestoneTypes": [
+    { "name": "Acknowledge Within", "description": "Acknowledge Within", "recurrenceType": "OneTime" },
+    { "name": "Resolve Within",     "description": "Resolve Within",     "recurrenceType": "OneTime" }
+  ],
+
+  "milestones": [
+    {
+      "order": 1,
+      "milestoneType": "Acknowledge Within",
+      "timeTrigger": 30,
+      "priorityTier": "Critical",
+      "activeWhen":     { "field": "Priority", "operator": "Equals",   "value": "Critical" },
+      "completeWhen":   { "field": "Status",   "operator": "NotEqual", "value": "New" },
+      "cancelWhen":     { "field": "Priority", "operator": "NotEqual", "value": "Critical" }
+    },
+    {
+      "order": 2,
+      "milestoneType": "Resolve Within",
+      "timeTrigger": 120,
+      "priorityTier": "Critical",
+      "activeWhen":     { "field": "Priority", "operator": "Equals", "value": "Critical" },
+      "completeWhen":   { "field": "Status",   "filterLogic": "1 OR 2 OR 3", "rows": [ { "operator": "Equals", "value": "Resolved" }, { "operator": "Equals", "value": "Completed" }, { "operator": "Equals", "value": "Closed" } ] },
+      "cancelWhen":     { "field": "Priority", "operator": "NotEqual", "value": "Critical" }
+    },
+    {
+      "order": 3,
+      "milestoneType": "Acknowledge Within",
+      "timeTrigger": 60,
+      "priorityTier": "High",
+      "activeWhen":     { "field": "Priority", "operator": "Equals",   "value": "High" },
+      "completeWhen":   { "field": "Status",   "operator": "NotEqual", "value": "New" },
+      "cancelWhen":     { "field": "Priority", "operator": "NotEqual", "value": "High" }
+    },
+    {
+      "order": 4,
+      "milestoneType": "Resolve Within",
+      "timeTrigger": 240,
+      "priorityTier": "High",
+      "activeWhen":     { "field": "Priority", "operator": "Equals", "value": "High" },
+      "completeWhen":   { "field": "Status",   "filterLogic": "1 OR 2 OR 3", "rows": [ { "operator": "Equals", "value": "Resolved" }, { "operator": "Equals", "value": "Completed" }, { "operator": "Equals", "value": "Closed" } ] },
+      "cancelWhen":     { "field": "Priority", "operator": "NotEqual", "value": "High" }
+    },
+    {
+      "order": 5,
+      "milestoneType": "Acknowledge Within",
+      "timeTrigger": 240,
+      "priorityTier": "Moderate",
+      "activeWhen":     { "field": "Priority", "operator": "Equals",   "value": "Moderate" },
+      "completeWhen":   { "field": "Status",   "operator": "NotEqual", "value": "New" },
+      "cancelWhen":     { "field": "Priority", "operator": "NotEqual", "value": "Moderate" }
+    },
+    {
+      "order": 6,
+      "milestoneType": "Resolve Within",
+      "timeTrigger": 960,
+      "priorityTier": "Moderate",
+      "activeWhen":     { "field": "Priority", "operator": "Equals", "value": "Moderate" },
+      "completeWhen":   { "field": "Status",   "filterLogic": "1 OR 2 OR 3", "rows": [ { "operator": "Equals", "value": "Resolved" }, { "operator": "Equals", "value": "Completed" }, { "operator": "Equals", "value": "Closed" } ] },
+      "cancelWhen":     { "field": "Priority", "operator": "NotEqual", "value": "Moderate" }
+    },
+    {
+      "order": 7,
+      "milestoneType": "Acknowledge Within",
+      "timeTrigger": 240,
+      "priorityTier": "Low",
+      "activeWhen":     { "field": "Priority", "operator": "Equals",   "value": "Low" },
+      "completeWhen":   { "field": "Status",   "operator": "NotEqual", "value": "New" },
+      "cancelWhen":     { "field": "Priority", "operator": "NotEqual", "value": "Low" }
+    },
+    {
+      "order": 8,
+      "milestoneType": "Resolve Within",
+      "timeTrigger": 960,
+      "priorityTier": "Low",
+      "activeWhen":     { "field": "Priority", "operator": "Equals", "value": "Low" },
+      "completeWhen":   { "field": "Status",   "filterLogic": "1 OR 2 OR 3", "rows": [ { "operator": "Equals", "value": "Resolved" }, { "operator": "Equals", "value": "Completed" }, { "operator": "Equals", "value": "Closed" } ] },
+      "cancelWhen":     { "field": "Priority", "operator": "NotEqual", "value": "Low" }
+    }
+  ],
+
+  "entitlement": {
+    "_note": "The OOB backend auto-creates the Entitlement during activation. When replicating headless, create it via POST /sobjects/Entitlement on the resolved Account (same as the custom Phase 2 flow), SlaProcessId = the seeded policy, backdated StartDate for immediate engagement.",
+    "name": "Standard Support for Incidents",
+    "matchAllCriterion": {
+      "_note": "The OOB seeds an always-true entitlement criterion so every Incident matches automatically. ATTEMPT to replicate it via POST /connect/sla-management/entitlement-criteria: `describe` the route FIRST and send its exact input fields — it rejects `filterType`, and a wrong body returns a 400 (a wrong-payload error, NOT a platform gap). Only if the create still 400s after using the described schema, fall back to the date-windowed Entitlement alone and REPORT only the engagement-scope consequence: the policy then engages on Incidents wired to this Entitlement (EntitlementId set), not automatically on every Incident. Do NOT tell the user the route is 'unreachable' or 'undiscoverable' — it works; the body just needs its correct fields. The date-windowed Entitlement + the milestone criteria above are still sufficient to engage the Phase 3 test Incident.",
+      "field": "Subject",
+      "operator": "NotEqual",
+      "value": "!iw6vnffW1Pt:CQbS/0cwh!17G,Gj##H",
+      "priorityOrder": 98,
+      "criteriaType": "AND"
+    }
+  },
+
+  "_replicationNotes": {
+    "table": "Every criterion filters the Incident table (filterItems[].table = \"Incident\").",
+    "activeCriterion": "The public Attach-Milestone route's milestoneCriteria carries the ACTIVE criterion — filterType RuleFilter, milestoneState Active, milestoneAgreementType SLA (customer-facing; OLA is the internal alternative — W-23959162). The priority-tier row IS this active criterion.",
+    "completionAndCancel": "The OOB completion (Status In resolved-set) and cancel (Priority NotEqual tier) criteria use milestoneState Complete / Cancel. Confirm the public milestone-criteria route accepts those states in the live smoke test; if it accepts only the Active criterion, seeding the priority-tiered Active criterion still engages each milestone (matches examples/milestone-patterns.md Pattern 3).",
+    "orClause": "The core OOB template groups Moderate+Low into one Priority In[Moderate,Low] tier. Because the public route's filterItems AND by default and Priority has no In operator, this template already splits that tier into separate Priority Equals Moderate (orders 5-6) and Priority Equals Low (orders 7-8) milestones with the same timeTriggers — behavior-equivalent to the merged core tier. Seed all 8 as listed.",
+    "statusIn": "Status 'In [Resolved, Completed, Closed]' has no single-row In operator, so each completeWhen above is already PRE-SPLIT into a filterLogic ('1 OR 2 OR 3') across three Status Equals rows — the data file never carries a route-rejected In operator. If the route rejects filterLogic, split into one Status Equals row per value (behavior-equivalent). Validate each Status/Priority value against the live Incident picklist before seeding.",
+    "midTier": "Map the mid tier to the org's ACTUAL mid-priority label — 'Moderate' on the standard ITSM picklist, but many orgs label it 'Medium'. Seed orders 5-6 with whichever the live Incident.Priority picklist carries rather than dropping the tier; drop a row only when its value is genuinely absent, and note any dropped/relabeled tier in the report."
+  }
+}

package/skills/service-itsm-agentic-setup-incident-sla-configure/examples/milestone-patterns.md

@@ -35,9 +35,9 @@ All strategies share these defaults unless overridden:
 
 - `businessHoursId`: the default BusinessHours resolved in Phase 1 step 4
 - `startTimeBasedOn`: `SlaProcessCreatedDate`
-- `milestoneState`: `Active`
-- `milestoneAgreementType`: `Warning`
-- `filterType`: `RuleFilter`
+- `milestoneAgreementType`: `SLA` — inside each `milestoneCriteria[]` item (mandatory per the UI). Valid UI values are `SLA` (customer-facing) or `OLA` (internal); the API accepts any string because the underlying field is `Text(40)` with no server-side picklist, but the UI renders unrecognized values as blank (W-23959162)
+- `milestoneState`: `Active` (inside `milestoneCriteria[]`)
+- `filterType`: `RuleFilter` (inside `milestoneCriteria[]`)
 - Base filter row: `Incident.Status NotEqual Closed` (keeps every milestone alive until the
   Incident closes; ANDs with pattern-specific criteria below)
 
@@ -143,8 +143,10 @@ Incident create (e.g. via the Priority Matrix), the milestone re-evaluates on th
 | 3 | Incident Executive Escalation | 480 | *(none)* |
 
 All three run concurrently from `SlaProcessCreatedDate` — the "ladder" is enforced by the timers,
-not by chaining. Strictly sequential escalation requires workflow SLA actions
-(`POST /connect/workflow-sla-actions/execute-actions`), which is out of scope for this skill.
+not by chaining. To fire automation at a milestone's warning/violation checkpoint (warn before
+target, escalate on breach), attach a **milestone action** in Phase 2.5 — see
+`references/mcp-invocation.md` (Milestone Actions). (Strictly *sequential* chaining across separate
+milestones is a different mechanism — workflow SLA actions — and remains out of scope.)
 
 ---
 
@@ -182,6 +184,27 @@ before creating the MilestoneType or attaching the milestone.
 
 ---
 
+## Predefined preset — "Standard Support for Incidents" (OOB)
+
+This is Salesforce's out-of-box predefined Incident SLA policy — a fixed priority-tiered preset offered
+at the Phase 0.6 fork (not one of the Phase 1.4 custom options above). It pairs an **Acknowledge Within**
+and a **Resolve Within** milestone per priority tier:
+
+| tier | Acknowledge Within | Resolve Within |
+|------|--------------------|----------------|
+| Critical        | 30 min  | 120 min |
+| High            | 60 min  | 240 min |
+| Moderate or Low | 240 min | 960 min |
+
+Seed it verbatim from `assets/predefined-incident-policy.json` following the recipe in
+`references/mcp-invocation.md` (Predefined Incident Policy) — detect-before-seed (the policy AND the
+pre-seeded MilestoneType catalog: reuse `Resolve Within` etc. by name, create only what is missing),
+`active: true` on create, validate Priority/Status against the live picklist, and map the mid tier to
+the org's real label (`Moderate` or `Medium`). Unlike the custom patterns above, when the user picks
+this at the fork the skill seeds → verifies → **stops** (no custom milestone offer after).
+
+---
+
 ## Gotchas across all patterns
 
 | Issue | Detail |

package/skills/service-itsm-agentic-setup-incident-sla-configure/examples/output-templates.md

@@ -54,4 +54,22 @@ Verification:
 Chain: MilestoneTypes > SLA Policy > Milestones > Entitlement > Incident > EntityMilestones
 ```
 
-No record IDs in user-facing output. No files are produced — the skill mutates org configuration in place through headless-360 MCP dispatch.
+## Success — milestone actions (Phase 2.5, when Warn/Escalate was requested)
+
+```text
+Milestone Actions attached:
+  <MilestoneType name>:
+    - Warning:   fires <X> min before target  ->  <action summary, e.g. set Priority = High>
+    - Violation: fires at breach               ->  <action summary, e.g. set Priority = Critical>
+  <MilestoneType name>:
+    - Warning:   fires <Y> min before target  ->  <action summary>
+    - Violation: fires at breach               ->  <action summary>
+
+Confirmation: each action was confirmed from its create response (success + action mapping
+returned). The attached warning/escalation settings can't be independently queried after creation,
+so that create-response confirmation is the verification.
+```
+
+No record IDs in user-facing output — this applies to **every interim progress/narration message too**, not just these final templates: refer to the test Incident by its **`IncidentNumber`** and to milestones by their **`MilestoneType` name**, never the 15/18-char record Id.
+
+**No implementation/MCP jargon in user-facing text.** Terms like "headless", "read-back", "dispatch", "Connect API", or operation ids are internal — never surface them in the report or narration. Say "the settings can't be independently queried after creation", **not** "no headless read-back". No files are produced — the skill mutates org configuration in place through headless-360 MCP dispatch.