@salesforce/afv-skills 1.58.0 → 1.60.0

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

@@ -1,102 +0,0 @@
-{
-  "_comment": "Out-of-box 'Standard Support for Incidents' predefined SLA policy — a faithful replica of what Salesforce ITSM seeds when a customer clicks the Incident checkbox under '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). Byte-for-byte modeled on core service-itsm-impl default-sla-policies/incident.json (the resource DefaultSlaServiceImpl reads and seeds) + shared_core_ui_labels/incident-management.xml (DefaultSeededSla): 6 milestones — Critical (30/120) and High (60/240) each Priority Equals, plus a MERGED Moderate-or-Low tier (240/960) whose ACTIVE criterion is a Priority OR (filterLogic '1 OR 2' over two Equals rows, Moderate + Low). NOTE: the core template also carries a per-tier CANCEL criterion, but the public /connect/sla-management route has NO 'CANCEL' milestoneState (valid states: ACTIVE, COMPLETE, PAUSE, UNPAUSE) — so this replica OMITS cancelWhen. The ACTIVE Priority criterion alone gates engagement (an off-tier Incident never matches), making CANCEL redundant. Every milestone uses startTimeBasedOn MILESTONE_CRITERIA (the OOB timer starts when the milestone criteria first match, NOT from the SLA-process created date). WHY REPLICATE INSTEAD OF CALLING THE UI'S OWN API: the checkbox invokes DefaultSlaPolicyController.saveSelectedOptions, an @AuraEnabled controller (core/ui-service-itsm-components) whose only caller of DefaultSlaService.createDefaultSlaPolicies is that Aura action — there is NO public REST/Connect wrapper, so the headless MCP (which dispatches REST/Connect) cannot invoke the seeder directly; it reproduces the seeder's exact output via the public /connect/sla-management routes.",
-
-  "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",
-      "startTimeBasedOn": "MILESTONE_CRITERIA",
-      "activeWhen":     { "field": "Priority", "operator": "Equals",   "value": "Critical" },
-      "completeWhen":   { "field": "Status",   "operator": "NotEqual", "value": "New" }
-    },
-    {
-      "order": 2,
-      "milestoneType": "Resolve Within",
-      "timeTrigger": 120,
-      "priorityTier": "Critical",
-      "startTimeBasedOn": "MILESTONE_CRITERIA",
-      "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" } ] }
-    },
-    {
-      "order": 3,
-      "milestoneType": "Acknowledge Within",
-      "timeTrigger": 60,
-      "priorityTier": "High",
-      "startTimeBasedOn": "MILESTONE_CRITERIA",
-      "activeWhen":     { "field": "Priority", "operator": "Equals",   "value": "High" },
-      "completeWhen":   { "field": "Status",   "operator": "NotEqual", "value": "New" }
-    },
-    {
-      "order": 4,
-      "milestoneType": "Resolve Within",
-      "timeTrigger": 240,
-      "priorityTier": "High",
-      "startTimeBasedOn": "MILESTONE_CRITERIA",
-      "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" } ] }
-    },
-    {
-      "order": 5,
-      "milestoneType": "Acknowledge Within",
-      "timeTrigger": 240,
-      "priorityTier": "Moderate or Low",
-      "startTimeBasedOn": "MILESTONE_CRITERIA",
-      "activeWhen":     { "field": "Priority", "filterLogic": "1 OR 2", "rows": [ { "operator": "Equals", "value": "Moderate" }, { "operator": "Equals", "value": "Low" } ] },
-      "completeWhen":   { "field": "Status",   "operator": "NotEqual", "value": "New" }
-    },
-    {
-      "order": 6,
-      "milestoneType": "Resolve Within",
-      "timeTrigger": 960,
-      "priorityTier": "Moderate or Low",
-      "startTimeBasedOn": "MILESTONE_CRITERIA",
-      "activeWhen":     { "field": "Priority", "filterLogic": "1 OR 2", "rows": [ { "operator": "Equals", "value": "Moderate" }, { "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" } ] }
-    }
-  ],
-
-  "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 (UPPERCASE — the server matches this case-sensitively; a wrong-case 'Active' returns 201 but silently drops the criterion, collapsing every Incident onto the lowest-order/Critical tier), milestoneAgreementType SLA (customer-facing; OLA is the internal alternative — W-23959162). The priority-tier row IS this active criterion; it is what tiers the policy.",
-    "completion": "The OOB completion (Status In resolved-set) criterion uses milestoneState COMPLETE (UPPERCASE). There is NO CANCEL state on the public route (valid: ACTIVE, COMPLETE, PAUSE, UNPAUSE), so no cancel criterion is sent — the ACTIVE Priority criterion alone gates engagement (matches examples/milestone-patterns.md Pattern 3). Verify tiering by runtime: create a Moderate/Low test Incident and confirm its EntityMilestone lands on the 240/960 tier, not 30/120 (the create response always echoes milestoneCriteria:[] regardless of success, so it cannot confirm persistence).",
-    "orClause": "The core OOB template groups Moderate+Low into ONE tier via an ACTIVE filterLogic '1 OR 2' over two Priority Equals rows (Moderate, Low) — see incident.json orders 5-6. This template mirrors that exactly: orders 5-6 carry activeWhen.filterLogic '1 OR 2' with rows [Priority Equals Moderate, Priority Equals Low]. The public milestone-criteria route accepts this OR via customLogicExpression (the same MilestoneCriteriaInputRepresentation the /connect/sla-management milestones route consumes), so it need NOT be split into separate Equals milestones. Seed 6 milestones as listed. If the live route rejects the OR filterLogic, fall back to two separate Priority Equals milestones (Moderate, Low) with the same timeTriggers — behavior-equivalent. The merged tier has NO cancelWhen, matching the core template (orders 5-6 have ACTIVE + COMPLETE only).",
-    "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'. In the merged orders 5-6 activeWhen.rows, use whichever label the live Incident.Priority picklist carries in place of 'Moderate' (keep the 'Low' row as-is). Drop a row from the OR only when its value is genuinely absent from the picklist, and note any dropped/relabeled tier in the report."
-  }
-}