@salesforce/afv-skills 1.59.0 → 1.61.0

package/skills/service-de-channel-consent-configure/SKILL.md

@@ -1,230 +0,0 @@
----
-name: service-de-channel-consent-configure
-description: "Configure consent (opt-in/opt-out) on an Enhanced `MessagingChannel` so activation will accept it. Given a `{CHANNEL_ID}`, sets the channel's `ConsentType` (ImplicitOptIn / ExplicitOptIn / DoubleOptIn) and the `OptInPrompt` / `DoubleOptInPrompt` prompt fields, then creates or updates one `MsgChannelLanguageKeyword` record per language holding the opt-in / double-opt-in / opt-out / help / custom keywords and confirmation messages. Use between channel insertion and activation — activation fails the consent-readiness check unless a valid ConsentType and at least one matching language-keyword record exist."
-metadata:
-  version: "1.0"
-  minApiVersion: "67.0"
-  domains: ["Service"]
-  cliTools:
-    - tool: ["sf"]
-      semver: ">=2.0.0"
-  relatedSkills:
-    - "service-de-channel-activate"
-    - "service-de-channel-routing-configure"
-    - "service-de-headless-channel-configure"
----
-
-# Configuring Channel Consent
-
-## What this skill does
-
-Ensures an Enhanced `MessagingChannel` has valid **consent** configured before activation. Consent has two parts, and both are checked by the server-side activation-readiness gate (`MessagingChannelReadinessChecker.isConsentConfiguredForChannel`):
-
-1. **Channel-level fields** on `MessagingChannel`:
-   - `ConsentType` — static enum: `ImplicitOptIn`, `ExplicitOptIn`, or `DoubleOptIn`.
-   - `OptInPrompt` — message sent when an end-user reply doesn't match an opt-in keyword (required for ExplicitOptIn/DoubleOptIn, except on Unified SMS / WhatsApp / RCS where it's optional).
-   - `DoubleOptInPrompt` — message sent when a reply doesn't match a double-opt-in keyword (required for DoubleOptIn).
-   - `IsRequireDoubleOptIn` — boolean flag; set true alongside `ConsentType=DoubleOptIn`.
-
-2. **Per-language keyword records** — one or more `MsgChannelLanguageKeyword` child rows (master-detail to `MessagingChannel`, key prefix `3Or`). Each holds the keywords an end-user sends (opt-in, double-opt-in, opt-out, help, custom) and the confirmation replies, **for one language**. Keyword fields are **comma-separated strings** (e.g. `"STOP,UNSUBSCRIBE,CANCEL"`).
-
-**Consent is never a no-op for activation.** Even `ImplicitOptIn` requires at least one `MsgChannelLanguageKeyword` with an opt-out keyword + opt-out confirmation. (The one exception is an outbound-only channel, which the readiness check passes automatically.)
-
-Consent settings apply only to **Enhanced** channels (`PlatformType=Enhanced`) of a supported message type. On a Standard channel these fields aren't used; this skill only touches Enhanced channels.
-
-## Where this fits
-
-This skill runs between routing and activation in the Enhanced-channel setup pipeline. `service-de-channel-routing-configure` sets the channel's `SessionHandler`; this skill configures consent; then `service-de-channel-activate` flips the channel live. The activation readiness check requires **both** routing and consent, so run this before activating. The `service-de-headless-channel-configure` orchestrator sequences all three automatically — invoke this skill directly only when you want to configure consent on its own.
-
-## Reference File Index
-
-| Reference file | Load when |
-| --- | --- |
-| `references/language-keywords.md` | Creating or updating the per-language `MsgChannelLanguageKeyword` records — full field list, CSV keyword semantics, create-vs-update logic, and the Unified-SMS help/custom-keyword rules. |
-| `references/gotchas.md` | Troubleshooting an unexpected result, or before modifying this skill. |
-| `references/worked-examples.md` | You want a reference run of the ImplicitOptIn, ExplicitOptIn, or DoubleOptIn paths. |
-
-## When NOT to use this skill
-
-- **The channel isn't Enhanced.** Consent fields apply to Enhanced channels only. This skill confirms `PlatformType=Enhanced` and stops otherwise.
-- **The channel is outbound-only.** Outbound-only channels pass the consent-readiness check automatically; there's nothing to configure.
-- **The channel doesn't exist yet.** Run the insertion skill first; this skill expects a real `MessagingChannel.Id`.
-
-## Inputs (from caller)
-
-- `{CHANNEL_ID}` — a 15- or 18-char `MessagingChannel.Id` (prefix `0Mj`). Must already exist and be Enhanced.
-- `{CONSENT_TYPE}` — optional; one of `ImplicitOptIn` | `ExplicitOptIn` | `DoubleOptIn`. If omitted, the skill prompts.
-- `{LANGUAGE}` — optional; the `MasterLanguage` for the keyword record (e.g. `en_US`). Defaults to `en_US` if not provided.
-- `{ORG_ALIAS}` — optional; `sf` CLI target-org alias. Default: whatever `sf config get target-org` returns.
-
-The individual keyword/confirmation/prompt values are collected interactively in Stage 3–4 (or accepted from the caller if pre-supplied).
-
-## Output (to caller)
-
-**Success — no change needed:**
-```json
-{"ok": true, "noop": true, "consentType": "ImplicitOptIn|ExplicitOptIn|DoubleOptIn", "languageKeywordIds": ["3Or..."], "message": "Consent already configured and activation-ready"}
-```
-
-**Success — consent configured:**
-```json
-{"ok": true, "consentType": "ExplicitOptIn", "channelFieldsSet": ["ConsentType","OptInPrompt"],
- "languageKeywordId": "3Or...", "language": "en_US", "created": true|false, "activationReady": true}
-```
-
-**Precondition / validation not met:**
-```json
-{"ok": false, "kind": "not-enhanced", "hint": "consent fields apply to Enhanced channels only; this channel is PlatformType=<x>"}
-{"ok": false, "kind": "missing-consent-input", "hint": "<which required keyword/prompt for the chosen ConsentType is missing>"}
-```
-
-**Failure:**
-```json
-{"ok": false, "kind": "channel-patch-failed", "message": "..."}
-{"ok": false, "kind": "keyword-record-failed", "message": "..."}
-{"ok": false, "kind": "verify-failed", "hint": "writes returned success but a re-read shows the channel is still not consent-ready"}
-```
-
----
-
-## Stage 1: Read current consent state
-
-Read the channel's consent fields and any existing language-keyword records.
-
-```bash
-sf data query --target-org '{ORG_ALIAS}' \
-  --query "SELECT Id, DeveloperName, PlatformType, MessageType, MessagingPlatformKey, ConsentType, OptInPrompt, DoubleOptInPrompt, IsRequireDoubleOptIn FROM MessagingChannel WHERE Id = '{CHANNEL_ID}'" \
-  --json > /tmp/cc-channel.json
-
-sf data query --target-org '{ORG_ALIAS}' \
-  --query "SELECT Id, MasterLanguage, OptInKeywords, DoubleOptInKeywords, OptInConfirmation, OptOutKeywords, OptOutConfirmation, HelpKeywords, HelpResponse, CustomKeywords, CustomResponse FROM MsgChannelLanguageKeyword WHERE MessagingChannelId = '{CHANNEL_ID}'" \
-  --json > /tmp/cc-keywords.json
-```
-
-If the channel record is missing — halt with `Error: Channel {CHANNEL_ID} not found — check the id, or run the insertion skill first.`
-
-If `PlatformType != 'Enhanced'` — emit `{ok:false, kind:"not-enhanced", ...}` and stop.
-
-**No-op check:** if `ConsentType` is non-null AND the existing language-keyword records already satisfy the readiness matrix for that ConsentType (see Stage 5), emit the `noop:true` envelope and return. Don't re-prompt or overwrite a channel that is already activation-ready.
-
----
-
-## Stage 2: Choose the ConsentType
-
-If `{CONSENT_TYPE}` wasn't supplied, prompt (do NOT auto-pick):
-
-```text
-Channel '{developerName}' ({CHANNEL_ID}) — choose a consent model:
-
-  1) ImplicitOptIn  — end users are opted in by default; you only handle opt-OUT (STOP) keywords.
-  2) ExplicitOptIn  — end users must send an opt-in keyword before you can message them.
-  3) DoubleOptIn    — explicit opt-in plus a second confirming keyword.
-
-Pick [1-3]:
-```
-
-Record `{CONSENT_TYPE}`. Note the field checks that follow (this is the exact server-side activation-readiness contract — see `references/gotchas.md` for the source):
-
-| ConsentType | MessagingChannel fields | `MsgChannelLanguageKeyword` (≥1 record) |
-| --- | --- | --- |
-| ImplicitOptIn | (none required) | `OptOutKeywords` + `OptOutConfirmation` |
-| ExplicitOptIn | `OptInPrompt`¹ | above + `OptInKeywords` |
-| DoubleOptIn | `OptInPrompt`¹ + `DoubleOptInPrompt` + `IsRequireDoubleOptIn=true` | above + `DoubleOptInKeywords` |
-
-¹ `OptInPrompt` is optional (not required for readiness) on Unified SMS / WhatsApp / RCS channels — detect via `MessageType IN ('Text','WhatsApp','Rcs')` on an Enhanced channel (the queryable proxy for the server's `isUnifiedSMSOrWhatsappOrRCS`). Still recommend setting it for a good end-user experience.
-
----
-
-## Stage 3: Collect channel-level prompt values
-
-Only prompt for the fields the chosen ConsentType requires (see the matrix above). Skip this stage entirely for `ImplicitOptIn` — it needs no channel-level prompt fields.
-
-For `ExplicitOptIn` / `DoubleOptIn`:
-
-```text
-Opt-in prompt (sent when a reply doesn't match an opt-in keyword):
-```
-For `DoubleOptIn`, also:
-```text
-Double-opt-in prompt (sent when a reply doesn't match a double-opt-in keyword):
-```
-
-Trim whitespace. If a required prompt is empty after trimming, re-prompt once; on a second empty, emit `{ok:false, kind:"missing-consent-input", hint:"..."}`.
-
----
-
-## Stage 4: Configure the per-language keyword record
-
-Collect the keyword lists and confirmation replies for `{LANGUAGE}` (default `en_US`), then create or update the `MsgChannelLanguageKeyword` record.
-
-**Load `references/language-keywords.md` and follow it** — it holds the full field list, the comma-separated-keyword semantics, the create-vs-update decision (reuse an existing record for the same language rather than duplicating), and the Unified-SMS help/custom-keyword rules.
-
-The minimum per ConsentType (again, from the readiness contract):
-- **ImplicitOptIn:** `OptOutKeywords` (e.g. `STOP,UNSUBSCRIBE`) + `OptOutConfirmation`.
-- **ExplicitOptIn:** the above + `OptInKeywords` (e.g. `START,YES`).
-- **DoubleOptIn:** the above + `DoubleOptInKeywords` (e.g. `CONFIRM`).
-
-`OptInConfirmation`, `HelpKeywords`/`HelpResponse`, and `CustomKeywords`/`CustomResponse` are optional for the base readiness check (help/custom are only *required* on Unified SMS — see the reference), but collect them if the user wants them.
-
----
-
-## Stage 5: Write channel fields + keyword record
-
-Write the channel-level fields in one PATCH (only the fields the ConsentType requires).
-
-**Quoting rule (load-bearing):** `sf data update record --values` splits on spaces, so any value containing a space **must be wrapped in single quotes inside the double-quoted `--values` string** — e.g. `OptInPrompt='Reply YES to receive messages'`. An unquoted `OptInPrompt=Reply YES ...` fails with `Malformed key=value pair` (verified live on sdb6c). Prompts almost always contain spaces, so always quote them.
-
-```bash
-# ImplicitOptIn — ConsentType only
-sf data update record --target-org '{ORG_ALIAS}' --sobject MessagingChannel \
-  --record-id '{CHANNEL_ID}' --values "ConsentType=ImplicitOptIn" --json > /tmp/cc-patch.json
-
-# ExplicitOptIn
-sf data update record --target-org '{ORG_ALIAS}' --sobject MessagingChannel \
-  --record-id '{CHANNEL_ID}' --values "ConsentType=ExplicitOptIn OptInPrompt='{OPT_IN_PROMPT}'" --json > /tmp/cc-patch.json
-
-# DoubleOptIn
-sf data update record --target-org '{ORG_ALIAS}' --sobject MessagingChannel \
-  --record-id '{CHANNEL_ID}' \
-  --values "ConsentType=DoubleOptIn OptInPrompt='{OPT_IN_PROMPT}' DoubleOptInPrompt='{DBL_PROMPT}' IsRequireDoubleOptIn=true" --json > /tmp/cc-patch.json
-```
-
-If `status !== 0`: emit `{ok:false, kind:"channel-patch-failed", message: ...}` and return.
-
-Then create or update the `MsgChannelLanguageKeyword` record per `references/language-keywords.md`. If it fails: `{ok:false, kind:"keyword-record-failed", message: ...}`.
-
----
-
-## Stage 6: Verify activation readiness
-
-Re-read both the channel and its keyword records (same two queries as Stage 1). Confirm, per the chosen ConsentType's row in the Stage 2 matrix, that every required field is now non-null on the channel AND on at least one keyword record for the configured language.
-
-If any required field is still null: emit `{ok:false, kind:"verify-failed", hint:"<which requirement is unmet>"}`.
-
-Otherwise emit the success envelope with `activationReady: true`.
-
----
-
-## Stage 7: Report to caller
-
-Report the JSON envelope. If this skill is the leaf (user invoked it directly), render:
-
-- `Success — Consent configured — channel {CHANNEL_ID} is now {CONSENT_TYPE} with a {LANGUAGE} keyword record. Activation-ready.`
-- `Info: Consent already configured — {CONSENT_TYPE}, {N} language record(s). No changes.` (no-op path)
-- `Warning: This channel is PlatformType={x}, not Enhanced — consent fields don't apply here.` (not-enhanced)
-- `Warning: Missing required consent input for {CONSENT_TYPE}: {what}. Re-run and provide it.` (missing-consent-input)
-- `Error: {kind}: {message}` (other failures)
-
----
-
-## Worked examples
-
-For reference runs of the ImplicitOptIn (opt-out only), ExplicitOptIn, and DoubleOptIn paths, see `references/worked-examples.md`.
-
----
-
-## Gotchas
-
-Known gotchas — the exact per-ConsentType activation-readiness contract (and its source), comma-separated keyword storage, the "ImplicitOptIn still needs a keyword record" trap, one-record-per-language uniqueness, the Unified-SMS help/French-custom rules, and the OptInPrompt Unified-SMS/WhatsApp/RCS exemption.
-
-**When troubleshooting an unexpected result, or before modifying this skill, load `references/gotchas.md` and follow it.**

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."
-  }
-}