@salesforce/afv-skills 1.65.0 → 1.65.1

package/skills/automation-flow-coordinate/references/elements/action-call/conversation-messaging.md

@@ -1,96 +0,0 @@
----
-name: flow-element-action-call-conversation-messaging
-license: LICENSE.txt has complete terms
-description: "Load when authoring a Send Conversation Messages (`sendConversationMessages`) action call — the Enhanced Messaging / Digital Engagement invocable that sends a ConversationMessageDefinition to MessagingEndUser recipients. Covers the builder traits that differ from the E360 mobile actions (no callout, no transaction control, no generic types), the describe-driven input parameters, the save-time consent cross-validation, and the worked example. DO NOT load for the E360 mobile push/in-app actions or any other action call."
-metadata:
-  version: "1.0"
-  related-skills: flow-element-action-call
----
-
-# Conversation Messaging Action
-
-Load this when authoring a **Send Conversation Messages** action call. The base `action-call.md` carries only the routing stub; this is the complete build guide for the action.
-
-**Send Conversation Messages** (`sendConversationMessages`) is a standard platform invocable action owned by **Messaging Core - Digital Engagement**. It sends a `ConversationMessageDefinition` (a messaging component) to `MessagingEndUser` recipients in Enhanced Messaging channels as automated outbound notifications. The action itself is **channel-agnostic**: the delivery channel and message type (WhatsApp, SMS, and other Enhanced channel message types) are determined by how the referenced `ConversationMessageDefinition` is configured, not by the action or any input parameter. It is the messaging-session analog of the E360 mobile actions (see [`action-call.md` § Mobile App Messaging Actions](action-call.md#mobile-app-messaging-actions-e360)), but its builder traits differ — read the differences before authoring.
-
-| Action | `actionName` (emit verbatim) | Enum (`InvocableActionType`) | Min API | Category |
-|---|---|---|---|---|
-| **Send Conversation Messages** | `sendConversationMessages` | `SEND_CONVERSATION_MESSAGES` | 246 | Messaging |
-
-## How it differs from the E360 mobile actions
-
-These come from the **live describe** (`/actions/standard/sendConversationMessages`), not just source — they change the metadata shape versus `sendMobileAppMessage` / `sendMobileAppInAppMessage`:
-
-| Trait | Mobile push / in-app | `sendConversationMessages` | Consequence for the `actionCalls[]` entry |
-|---|---|---|---|
-| `hasCallout` | `true` | **`false`** | **No** record-triggered scheduled-path restriction. The action may sit on the immediate path of a `RecordAfterSave` flow, and it is **not** blocked in `RecordBeforeSave` on the callout rule. |
-| `allowsTransactionControl` | `true` | **`false`** | **Do not emit `flowTransactionModel`.** (The mobile examples emit it *because* they set this true; this action does not support it.) |
-| Declared outputs | none | **`requestId` (ID), `messageIdentifiers` (String ≤100)** | `storeOutputAutomatically: true` with `outputParameters: []` is valid and idiomatic — reference `{!Send_Conversation_Messages.requestId}` downstream. |
-| `genericTypes` | `ContentSchema` present | **`null`** | **No `dataTypeMappings[]`.** There is no generic type to resolve. |
-
-Both are synchronous, so — like the mobile actions — do **not** emit `timeoutConnector` / `timeoutPathUsage`. **Wire a `faultConnector`, except in a marketing flow**: although `hasCallout: false`, the action throws `ApiException` at runtime on invalid input, missing message definition, or limit-exceeded. In a marketing flow, wire one only when the user asks for error handling (`../../shared/fault-paths/fault-paths.md` § Marketing Flows — Fault Paths Only When Asked).
-
-Each action declares a Custom Property Editor (`scrt_setup-send-conversation-messages-editor`); as with any CPE it replaces the parameter UI in the builder but does not change the saved `inputParameters[]` shape — resolve parameters from `GET /services/data/vXX.0/flowbuilder/action/invocable-action-details` when authoring metadata directly.
-
-## Input parameters
-
-Describe-driven — always fetch the live set with `GET /services/data/vXX.0/flowbuilder/action/invocable-action-details` before authoring. Verified shape:
-
-| Param | Type | Required | Notes |
-|---|---|---|---|
-| `messageDefinitionName` | String | yes | API name of a `ConversationMessageDefinition` record |
-| `requestType` | Picklist | yes | Only active value is `SendNotificationMessages` |
-| `isEnforceMessagingChannelConsent` | Boolean | yes | Gates the two consent params below (see cross-validation) |
-| `allowedSessionStatus` | Picklist | yes | `Any` / `NonActive` / `Closed` |
-| `messagingEndUserIds` | ID (list ≤100) | yes | `MessagingEndUser` record IDs |
-| `channelConsentType` | Picklist | conditional¹ | `MessagingEndUser` / `CommunicationSubscription` |
-| `communicationSubscriptionId` | ID (`CommSubscription`) | conditional¹ | The communication subscription to apply for consent |
-| `sessionLongevityPreference` | Picklist | no | `EndSession` / `KeepSessionOpen` / `KeepSessionOpenOrAppend` |
-| `messagingDefinitionInputParameters` | Apex `RichMessaging__MessageDefinitionInputParameter` (list) | no | Merge-field values for the message definition. Describe `maxOccurs` is 2000, but the action enforces a **runtime cap of 10** parameters — exceeding it fails with `LIMIT_EXCEEDED`. |
-
-¹ **Consent cross-validation (save-time, API ≥ 252).** Not surfaced in the describe, but enforced on save:
-- `isEnforceMessagingChannelConsent: true` ⇒ `channelConsentType` is **required**.
-- `channelConsentType: "CommunicationSubscription"` ⇒ `communicationSubscriptionId` is **required**; any other type ⇒ `communicationSubscriptionId` must be **absent**.
-- `isEnforceMessagingChannelConsent: false` ⇒ **both** `channelConsentType` and `communicationSubscriptionId` must be absent.
-
-This mirrors the Send Email template/subject cross-parameter validation noted under [`action-call.md` § Validation Rules and Constraints](action-call.md#validation-rules-and-constraints).
-
-## Worked example
-
-`examples/send-conversation-messages.json` — full `actionCalls[]` entry: required inputs plus a consistent consent pair (`isEnforceMessagingChannelConsent: true` + `channelConsentType: "MessagingEndUser"`, `communicationSubscriptionId` omitted), `messagingEndUserIds` bound to an upstream lookup, `storeOutputAutomatically: true`, and a `faultConnector` (the default rule; in a marketing flow, keep it only when the user asks for error handling).
-
-> **Note:** The example is an `actionCalls[]` fragment, not a complete flow. It references an upstream `Get_Messaging_End_Users` element (supplying recipient IDs) and a `Log_Send_Error` fault-path target that must exist elsewhere in the flow.
-
-## Anti-patterns (agent should reject / flag)
-
-```jsonc
-// WRONG #1 — emitting flowTransactionModel. allowsTransactionControl is false.
-{ "actionName": "sendConversationMessages", "flowTransactionModel": "Automatic" }
-
-// WRONG #2 — no fault path in a non-marketing flow, or in a marketing flow when the user asked for
-// error handling. The action throws ApiException on invalid input / limit exceeded.
-{ "actionName": "sendConversationMessages", "connector": { "targetReference": "END_Flow" } }
-// (missing faultConnector)
-
-// WRONG #3 — enforcing consent without a consent type. Save-time validation rejects this.
-{ "actionName": "sendConversationMessages", "inputParameters": [
-  { "name": "isEnforceMessagingChannelConsent", "value": { "booleanValue": true } }
-  // missing channelConsentType
-] }
-
-// WRONG #4 — communicationSubscriptionId set when the consent type isn't CommunicationSubscription.
-{ "inputParameters": [
-  { "name": "channelConsentType", "value": { "stringValue": "MessagingEndUser" } },
-  { "name": "communicationSubscriptionId", "value": { "stringValue": "0n3..." } }  // must be absent
-] }
-```
-
-> **Verification note.** Metadata above verified against a **live describe** of
-> `/services/data/vXX.0/actions/standard/sendConversationMessages` on a Digital Engagement org
-> (v69.0, test1, 2026-08), cross-checked against `SendConversationMessagesAction.java`,
-> `InvocableActionType.java` (`SEND_CONVERSATION_MESSAGES`, name-segment `sendConversationMessages`),
-> and the four picklist enums (`ConvMsgSendRequestType`, `ConvMsgSendRequestAllowedSessionStatus`,
-> `ConvMsgSendRequestConsentType`, `ConvMsgSendRequestSessionLongevityPreference`). Live describe
-> confirmed `hasCallout: false`, `allowsTransactionControl: false`, `genericTypes: null`, and the
-> `requestId` / `messageIdentifiers` outputs. Per-org, confirm the action's available process/trigger
-> types live via `GET /services/data/vXX.0/flowbuilder/action/invocable-action-details` before relying on them.

package/skills/automation-flow-coordinate/references/elements/action-call/examples/send-sms-message.json

@@ -1,23 +0,0 @@
-{
-  "_comment": "Observed in a hand-built Segment-triggered flow saved as a Draft through Flow Builder; activation was not verified. Preserve storeOutputAutomatically:true, outputParameters:[], dataTypeMappings:[], and flowTransactionModel:CurrentTransaction when reproducing this action shape. No faultConnector: this is a marketing (Segment) flow, which adds a fault path only when the user asks for error handling. Bind senderId and subscription IDs as exact literal org record IDs discovered live; never use senderSmsCode or an elementReference. The Id values below (0Mj.../0Xl.../0eB...) and <API_NAME> are placeholders: look each one up in the target org (action-call.md § Send SMS Message Action, Discovery workflow).",
-  "name": "SendSms",
-  "label": "SendSms",
-  "locationX": 0,
-  "locationY": 0,
-  "actionType": "sendSmsMessage",
-  "actionName": "sendSmsMessage",
-  "nameSegment": "sendSmsMessage",
-  "flowTransactionModel": "CurrentTransaction",
-  "dataTypeMappings": [],
-  "storeOutputAutomatically": true,
-  "inputParameters": [
-    { "name": "contentId", "value": { "stringValue": "marketing--Default_Content_Workspace.sfdc_cms__sms--<API_NAME>" } },
-    { "name": "senderId", "value": { "stringValue": "0MjXXXXXXXXXXXXXXX" } },
-    { "name": "clickTracking", "value": { "booleanValue": true } },
-    { "name": "communicationSubscriptionId", "value": { "stringValue": "0XlXXXXXXXXXXXXXXX" } },
-    { "name": "commSubscriptionChannelTypeId", "value": { "stringValue": "0eBXXXXXXXXXXXXXXX" } },
-    { "name": "blockoutWindowBehaviour", "value": { "stringValue": "doNotSend" } }
-  ],
-  "outputParameters": [],
-  "connector": { "targetReference": "END_Flow" }
-}

package/skills/automation-flow-coordinate/references/elements/action-call/examples/send-to-journey-no-fields.json

@@ -1,31 +0,0 @@
-{
-  "name": "Send_To_Journey",
-  "label": "Send to Journey",
-  "locationX": 0,
-  "locationY": 0,
-  "actionName": "sendToJourney",
-  "actionType": "sendToJourney",
-  "nameSegment": "sendToJourney",
-  "flowTransactionModel": "CurrentTransaction",
-  "inputParameters": [
-    {
-      "name": "mceBuSelector",
-      "value": {
-        "stringValue": "<EID>-<MID>"
-      }
-    },
-    {
-      "name": "mceJourneySelector",
-      "value": {
-        "stringValue": "<JOURNEY_ID>"
-      }
-    }
-  ],
-  "dataTypeMappings": [
-    {
-      "typeName": "JourneyDataExtensionSchema",
-      "schemaUri": "InputAutomationSchema:schemaOnlyJourneyDataExtension/<JOURNEY_ID>"
-    }
-  ],
-  "outputParameters": []
-}

package/skills/automation-flow-coordinate/references/elements/action-call/send-to-journey.md

@@ -1,179 +0,0 @@
-# Send to Journey (`sendToJourney`)
-Add this element to `metadata.actionCalls[]`. Never emit the legacy
-`triggerJourney` action.
-
-Set `processType: "AutoLaunchedFlow"` and build the Start for the flow's trigger:
-
-| Trigger | Start | Person's fields |
-|---|---|---|
-| `Segment` (the default) | `../start/segment-triggered.md` | `$Record.<field>` |
-| `OnDemandNoTrigger` (an On-Demand Flow) | `../start/start.md` § On-Demand | `$SelectedIndividual.<field>` (needs `start.dataGraph`) |
-| `IndivRelatedRecord` (a CRM-triggered marketing flow, e.g. "when a Lead's Status is Nurturing, send it to a journey") | `../start/start.md` § Engagement / Journey-Triggered | `$Input.<field>` (the triggering record) |
-
-The rest of this file applies to all three; only a Segment flow has a Segment to
-re-read in Plan And Pre-Save Checks. Stop for other trigger variants because they
-are outside this MVP, not unsupported by the platform. A no-trigger autolaunched
-Flow fails with `ACTIONCALL_NOT_SUPPORTED_FOR_PROCESSTYPE`.
-
-## Resolve Dependencies
-
-Load `send-to-journey-discovery.md`. Complete its Business Unit, Journey, and DE
-schema procedures before emitting the action. Use its selected
-`mceBuSelector`, `mceJourneySelector`, `metadata.dataSpace`, schema URI, and field
-mappings without reconstructing or substituting values.
-
-## Emit The Action
-
-Before emitting either the required-field or no-field action shape, emit these
-two entries in top-level `metadata.processMetadataValues`:
-
-```json
-[
-  { "name": "BuilderType", "value": { "stringValue": "LightningFlowBuilder" } },
-  { "name": "CanvasMode", "value": { "stringValue": "AUTO_LAYOUT_CANVAS" } }
-]
-```
-
-Never omit `processMetadataValues` from a generated Send-to-Journey flow. The
-flow can save as valid JSON without these entries, but Flow Builder then treats
-the `locationX: 0` / `locationY: 0` elements as free-form coordinates and
-renders them on top of one another instead of applying auto-layout. Apply this
-requirement to both field-mapped and no-field Journeys.
-
-Use the persisted no-field evidence for the fixed action envelope:
-
-- Set `actionName`, `actionType`, and `nameSegment` to `sendToJourney`.
-- Set `flowTransactionModel: "CurrentTransaction"`.
-- Set `outputParameters: []`.
-- Omit `faultConnector` unless the user asks for error handling. A Segment flow
-  is a marketing flow; see `../../shared/fault-paths/fault-paths.md`
-  § Marketing Flows — Fault Paths Only When Asked.
-- Omit `storeOutputAutomatically` and `isWaitUntilCompleted` only when
-  reproducing the verified no-field Draft shape. Do not generalize that
-  omission to a field-mapped action.
-- Bind `mceBuSelector` and `mceJourneySelector` as string literals.
-- Emit one `dataTypeMappings[]` entry with
-  `typeName: "JourneyDataExtensionSchema"` and the resolved `schemaUri`.
-- Omit `connector` when this action is terminal. Otherwise, target the real next
-  element. Do not invent an `ends[]` node for a terminal action.
-
-**Hard rule: the journey type mapping uses `schemaUri`.** The describe lists
-`JourneyDataExtensionSchema` with `superType: "NAMED_AUTOMATION_SCHEMA"`; its value
-is a schema URI, so it goes in `schemaUri` (`action-call.md` § Generic-Type Placeholders, the `superType`
-table). Putting the same URI in `typeValue` fails activation:
-`In Apex action "<element name>", type mapping "InputAutomationSchema:schemaOnlyJourneyDataExtension/<journey id>" is not a supported type.`
-
-```jsonc
-// correct
-"dataTypeMappings": [
-  { "typeName": "JourneyDataExtensionSchema",
-    "schemaUri": "InputAutomationSchema:schemaOnlyJourneyDataExtension/<journey id>" }
-]
-// WRONG: fails activation with "... is not a supported type."
-"dataTypeMappings": [
-  { "typeName": "JourneyDataExtensionSchema",
-    "typeValue": "InputAutomationSchema:schemaOnlyJourneyDataExtension/<journey id>" }
-]
-```
-
-When at least one field is mapped, add this input. Wire a `faultConnector` to a
-real handler only when the user asks for error handling. If you wire one, remove
-it only if `POST /services/data/vXX.0/flowbuilder/flow/actions/save` rejects it
-for that exact field-mapped action contract.
-
-```json
-{
-  "name": "journeyDataExtensionSchemaParameter",
-  "value": {
-    "inputConfiguratorMode": "Custom",
-    "transform": {
-      "isCollection": false,
-      "schemaUri": "<resolved URI>",
-      "transformValues": [
-        {
-          "transformValueActions": [
-            {
-              "outputFieldApiName": "<exact Journey field name>",
-              "transformType": "Map",
-              "value": { "elementReference": "<compatible Flow resource>" }
-            }
-          ]
-        }
-      ]
-    }
-  }
-}
-```
-
-Add one `transformValueActions[]` entry per mapped field. Omit the entire input
-when no fields are mapped and none are required. Never emit an empty Transform.
-
-**Do not conclude "no fields" from a single empty schema read.** An unprimed
-Journey can also return `parameters: []` and therefore look field-less. Emit the
-no-field shape only after the prime-then-re-resolve procedure in
-`send-to-journey-discovery.md` step 6 still returns `parameters: []`.
-
-Use `examples/send-to-journey-no-fields.json` for the verified no-field action
-fragment. Replace its illustrative selectors and Journey values with live
-values. A live save verified this no-field action in a Segment-triggered Flow
-whose status reached `Draft`. Do not claim that save validation proves runtime
-Journey delivery.
-
-## Plan And Pre-Save Checks
-
-- Show the business unit as `<Business Unit Name> (MID: <MID>)` and show the
-  mapped Data Space separately. Do not show only the MID or selector.
-- Re-read the live business-unit mapping, Segment, generic schema, and DE fields
-  immediately before every save.
-- **Re-prime the Journey immediately before saving.** Call
-  `dispatch(method: "POST", url: "/services/data/vXX.0/connect/e360mcetransformation/journey/upsert", body: { mceBuSelector: "<EID>-<MID>", journeyId: "<journey id>" })`
-  so its API-event registration is fresh at save time.
-  - The Journey field is **`journeyId`**, not `mceJourneySelector` or
-    `journeyKey`. `<journey id>` is the same selected `id` bound to
-    `mceJourneySelector`.
-  - This is a raw Connect REST resource invoked through the authenticated
-    Headless 360 `dispatch` tool. It is not a `/flowbuilder/...` endpoint or a
-    `d360_*` operation; do not invent another tool for it.
-  - A 500 does not by itself mean the prime failed. Confirm by re-resolving the
-    DE schema before treating the response as a failure.
-  - Priming sends no messages and enrolls no contacts. It is idempotent, so
-    re-priming an already-primed Journey is a no-op re-registration.
-  - Priming runs once at discovery time when the schema resolves empty and
-    again here. Disclose the discovery-time prime as an already-performed
-    prerequisite. Surface this pre-save re-prime in the approved plan summary
-    as a prerequisite write.
-  - If the call is unauthorized or the schema still does not resolve after a
-    real prime attempt, use the manual fallback in
-    `send-to-journey-recovery.md` step 2.
-- Call `dispatch(method: "POST", url: "/services/data/vXX.0/flowbuilder/flow/actions/save", body: { builderType: "JourneyBuilder" })`. Use
-   `saveType: "createNewFlow"` for a new Flow. Use `saveType: "saveDraft"` with
-   the latest returned `flowId` as `currentFlowId` to revalidate an existing
-   draft after an org-side prerequisite changes. `saveDraft` updates the current
-   Draft version in place. Treat the response's `flowId` as authoritative, but
-   do not claim that this save type creates or rotates a version ID.
-- Require the schema URI suffix to match `mceJourneySelector`, in `schemaUri`
-  with no `typeValue`.
-- Require every mandatory DE field to have a compatible mapping.
-- Verify one inline mapping per mapped field, or omit the schema input for a
-  confirmed no-field Journey.
-- Require `metadata.processMetadataValues` to contain exact
-  `BuilderType: LightningFlowBuilder` and `CanvasMode: AUTO_LAYOUT_CANVAS`
-  entries. Stop before `POST /services/data/vXX.0/flowbuilder/flow/actions/save` if either entry is absent or has another
-  value.
-- Reject `InvalidDraft` and activation-blocking warnings even when
-  `isSuccess: true`.
-- Before saving, load `../../shared/preview-renderer.md`. After a clean Draft
-  save, stop and return its Journey Builder deep link for the latest returned
-  version ID. Do
-  not call `POST /services/data/vXX.0/flowbuilder/flow/{flowId}/actions/activate` (activateFlow),
-  `POST /services/data/vXX.0/flowbuilder/flow/{flowId}/actions/deactivate` (deactivateFlow), or
-  `POST /services/data/vXX.0/flowbuilder/flow/{flowId}/actions/submit-for-activation` (submitFlowForActivation).
-  Preserve `processType: "AutoLaunchedFlow"`;
-  activation endpoint 404s do not imply that Segment flows use another
-  persisted process type.
-
-## Resolve Journey-Not-Found Validation
-
-Load and follow `send-to-journey-recovery.md` when `POST /services/data/vXX.0/flowbuilder/flow/actions/save` returns
-`ACTIONCALL_INPUT_VALIDATION_FAILED` with "Can't find the journey. Check whether
-it was renamed or deleted in Marketing Cloud."

package/skills/automation-flow-coordinate/references/elements/exit-rule/examples/event-email-link-click.json

@@ -1,13 +0,0 @@
-{
-  "_comment": "One item of exitRules[]: exit when the individual clicks any link in an email. Event-triggered variant: no conditions. associatedContent is the email's ManagedContent Id (20Y...), as a stringValue. specificLink is required; ANY means any link. Replace the associatedContent placeholder with this org's ManagedContent Id for the email (SELECT Id FROM ManagedContent WHERE Name = '<email title>' AND ContentTypeFullyQualifiedName = 'sfdc_cms__email').",
-  "name": "Exit_On_First_Email_Click",
-  "label": "Exit On First Email Click",
-  "ruleOrder": 1,
-  "logicalOperator": "and",
-  "automationEventName": "default__trgrOnEmailLinkClickEngagement",
-  "automationEventType": "trgrOnEmailLinkClickEngagement",
-  "inputParameters": [
-    { "name": "associatedContent", "value": { "stringValue": "<ManagedContent Id of the email, 20Y…>" } },
-    { "name": "specificLink", "value": { "stringValue": "ANY" } }
-  ]
-}

package/skills/automation-flow-coordinate/references/elements/exit-rule/exit-rule.md

@@ -1,83 +0,0 @@
----
-name: flow-element-exit-rule
-license: LICENSE.txt has complete terms
-description: "Use this skill when a user wants to create, configure, or troubleshoot an Exit Rule (FlowExitRule) in a Salesforce Flow — a condition that ends a flow interview early for an individual. TRIGGER when: user asks to exit, stop, or remove an individual from a flow/journey/segment/on-demand/digital-form/data-graph-change/activation flow based on a condition or automation event, or configure an Exit Rule. DO NOT TRIGGER for record-triggered or default-trigger flows — Exit Rule is not valid there; use flow-element-decision or an entry filter instead."
-metadata:
-  version: "1.0"
-  related-skills: flow-conditions, flow-element-start-segment-triggered
----
-
-# Exit Rule
-
-## Reference File Index
-
-| File | Purpose |
-|---|---|
-| `validators.md` | Save/activation constraints derived from platform validators |
-| `examples/basic.json` | One condition-based exit rule |
-| `examples/event-email-link-click.json` | One event-triggered exit rule (email link click) |
-
-## Overview
-
-An Exit Rule ends a flow interview early for an individual when its conditions match. It has no canvas position — it is not a `Start → Exit Rule → End` chain. It lives in the top-level `metadata.exitRules[]` array, evaluated alongside the flow's Start, not dropped between elements.
-
-## When to Use
-
-Use Exit Rule when an individual should stop mid-journey based on a condition (opted out, unsubscribed, already converted). Do not use it to branch flow logic mid-flow — use Decision for that. Do not use it on record-triggered or default-trigger flows — save fails or the rule is silently ineligible.
-
-## Valid Flow Types
-
-Exit Rule is allowed ONLY in:
-- `AutoLaunchedFlow` with `triggerType`: `Segment`, `DataGraphDataChange`, `FormSubmissionEvent`, `Activation`, `BroadcastNoTrigger`, `OnDemandNoTrigger`, or `MarketingSobject`. In a Segment flow, reference member fields as `$Record.<field>` (`../start/segment-triggered.md`). In an On-Demand flow, reference the person's fields as `$SelectedIndividual.<field>`, which needs a `start.dataGraph` (`../start/start.md` § On-Demand).
-- `DigitalForm`
-- `Journey` (deprecated process type)
-
-It is blocked on the default trigger type and every custom process type (Prompt, FSCLending, Appointments, Evaluation, UserProvisioning, ContactRequestFlows, ActionableEventManagement, UnifiedScheduling, RecommendationStrategy) and on record-triggered flows. If the user asks for an Exit Rule on one of these, tell them it isn't supported and suggest a Decision element or an entry filter on Start instead — do not force the save.
-
-## Metadata Shape (FlowExitRule)
-
-Extends `FlowElement`, not `FlowNode` — no `locationX`/`locationY`. Serializes to `metadata.exitRules[]` (sibling of `metadata.start`, not nested inside it).
-
-| Key | Type | Required | Notes |
-|---|---|---|---|
-| `name` | string | yes | Dev-name; unique within the flow (inherited from `FlowElement`) |
-| `label` | string | yes | Display label |
-| `ruleOrder` | int | yes | Evaluation order among multiple exit rules on the same flow; lower runs first |
-| `conditions` | [Condition](../../shared/conditions/conditions.md)[] | yes\* | At least one condition — zero conditions blocks activation (flow still saves). \*Required for condition-based variant; omit for event-triggered variant (see below) |
-| `logicalOperator` | string | yes | `"and"` or `"or"` only — custom-logic expressions (e.g. `"1 AND (2 OR 3)"`) are NOT supported here, unlike Decision's `conditionLogic`. **Required even with exactly one condition** — omitting it fails save with a null-field error |
-| `automationEventName` | string | no | Event-triggered variant only |
-| `automationEventType` | InvocableActionType | no | Event-triggered variant only |
-| `inputParameters` | FlowExitEventInputParameter[] | no | `{ name, value }`; event-triggered variant only |
-| `outputParameters` | FlowExitEventOutputParameter[] | no | `{ name, assignToReference }`; event-triggered variant only |
-
-Condition shape matches [FlowCondition](../../shared/conditions/conditions.md). Look up field/entity/operator values with `GET /services/data/vXX.0/flowbuilder/platform/entities`, `GET /services/data/vXX.0/flowbuilder/platform/entity/{apiName}/fields`, `GET /services/data/vXX.0/flowbuilder/schema/flow-capabilities` (read `.operators`).
-
-## Event-Triggered Variant
-
-Set `automationEventName`/`automationEventType` to exit when an invocable automation event fires, instead of a condition match — omit `conditions` entirely; setting both blocks activation. Discover candidates with `dispatch_readonly(method: "GET", url: "/services/data/vXX.0/flowbuilder/action/invocable-events", queryParams: { processType })`, then bind the selected descriptor's `name` to `automationEventName` and `type` to `automationEventType`. Call `dispatch_readonly(method: "GET", url: "/services/data/vXX.0/flowbuilder/action/invocable-action-details", queryParams: { actionType: type, actionName: name })` before setting `inputParameters`/`outputParameters`. `GET /services/data/vXX.0/flowbuilder/platform/event-types` is the platform-event catalog and does not provide the `InvocableActionType` required here.
-
-**Input values.** Each `inputParameters` entry is `{ "name": …, "value": { "stringValue": … } }`: the value is always wrapped in a typed value object, never bare text. For the email engagement events:
-
-| Input | Value |
-|---|---|
-| `associatedContent` | The email's **ManagedContent Id** (`20Y…`) as a `stringValue`. Not the content FQN (`marketing--…sfdc_cms__email--…`), not the bare content key (`MC…`), and not an element reference to the send. Look it up with SOQL: `SELECT Id FROM ManagedContent WHERE Name = '<email title>' AND ContentTypeFullyQualifiedName = 'sfdc_cms__email'` (or `WHERE ContentKey = '<MC… key>'`). |
-| `specificLink` | Required for link click. `ANY` = any link in the email. |
-
-Exit when the individual clicks any link in an email: `examples/event-email-link-click.json`.
-
-This is a different shape from the same event on a Wait Until Event, where `associatedContent` is an element reference to the send (`../wait/wait.md`). On an exit rule, an element reference fails activation.
-
-## Example
-
-See `examples/basic.json`. Each entry is one item of `exitRules[]` — not the whole flow. Multiple rules: give each a distinct `ruleOrder` (1, 2, …) and its own `conditions`/`logicalOperator` — rules don't share condition state.
-
-## Common Failures
-
-- **`Unrecognized field "conditionLogic" (Class FlowExitRule), not marked as ignorable`** → wrong field name. Use `logicalOperator`.
-- **`The field logicalOperator can't be "null".`** → `logicalOperator` omitted. Set it even for one condition.
-- **`FLOW_EXITRULE_WITH_NO_CONDITION`** → `conditions[]` is empty. Blocks activation (flow still saves). Exit Rule requires at least one condition for the condition-based variant; there is no unconditional exit — use a Decision default path instead if that's the intent.
-- **`The field associatedContent can't be "<automationEventName>". Enter a different value and try again.`** → an event exit rule's `associatedContent` is not a ManagedContent Id `stringValue` (bare text, the content FQN or bare content key, or an element reference). The message names the event, not the bad value. Use the `20Y…` Id as a `stringValue`.
-- **`The "<field>" element doesn't exist. Remove references to the element in all conditions.`** → a condition uses a bare field name or a DMO-qualified name. In a Segment flow write `$Record.<field>` (`../start/segment-triggered.md`); in an On-Demand flow write `$SelectedIndividual.<field>` and set `start.dataGraph` (`../start/start.md` § On-Demand).
-- **`Enter a value for the specificLink input parameter.`** → a link-click exit rule without `specificLink`. Set it (`ANY` for any link).
-- **`TRIGGER_TYPE_CONTEXT_OBJECT_NOT_SUPPORTED`** or a silently ineligible rule → flow's process/trigger type isn't in the valid list above. Do not retry with a different trigger type or process type as a workaround. State the constraint again in your final response to the user, even if you flagged it earlier in the conversation — never let the flow save with the exit rule dropped or replaced without saying so in the last message.
-- **`WARNING_BLOCK_ACTIVATION` on a condition field reference** → `leftValueReference` doesn't resolve against the flow's bound DMO/Individual object. Confirm the field exists on the object the flow is bound to (via `GET /services/data/vXX.0/flowbuilder/platform/entity/{apiName}/fields`) — a field that's valid on `Account`/`Contact` may not exist on the Individual/DMO object a segment flow is scoped to.

package/skills/automation-flow-coordinate/references/elements/forward-to-bot-or-agent/examples/forward-to-bot-or-agent.json

@@ -1,69 +0,0 @@
-{
-  "_comment": "Fragment: WaitUntilEvent (email response) + forwardToBotOrAgent ActionCall. Not a complete flow. References upstream Send_Marketing_Email element and downstream End / Handle_No_Reply elements that must exist in the full flow. No faultConnector: this fragment is for a marketing flow, which adds a fault path only when the user asks for error handling. In any other flow type, wire one.",
-
-  "waitElements": [
-    {
-      "name": "Wait_For_Email_Reply",
-      "label": "Wait for Email Reply",
-      "locationX": 400,
-      "locationY": 300,
-      "elementSubtype": "WaitUntilEvent",
-      "defaultConnectorLabel": "Default",
-      "waitEvents": [
-        {
-          "name": "Email_Reply_Event",
-          "label": "Email Reply Received",
-          "connector": { "targetReference": "Forward_To_Agent" },
-          "automationEventType": "trgrOnEmailResponseEngagement",
-          "automationEventName": "trgrOnEmailResponseEngagement",
-          "recordTriggerType": "Create",
-          "conditions": [],
-          "inputParameters": [
-            {
-              "name": "associatedContent",
-              "value": { "elementReference": "Send_Marketing_Email" }
-            }
-          ],
-          "outputParameters": []
-        },
-        {
-          "name": "Email_Reply_Timeout",
-          "label": "No Reply (3 Days)",
-          "connector": { "targetReference": "Handle_No_Reply" },
-          "offset": 3,
-          "offsetUnit": "Days",
-          "conditions": [],
-          "inputParameters": [],
-          "outputParameters": []
-        }
-      ]
-    }
-  ],
-
-  "actionCalls": [
-    {
-      "name": "Forward_To_Agent",
-      "label": "Forward to Agent",
-      "locationX": 400,
-      "locationY": 450,
-      "actionType": "forwardToBotOrAgent",
-      "actionName": "forwardToBotOrAgent",
-      "storeOutputAutomatically": true,
-      "connector": { "targetReference": "End" },
-      "inputParameters": [
-        {
-          "name": "channel",
-          "value": { "stringValue": "Email" }
-        },
-        {
-          "name": "associatedWaitConfiguration",
-          "value": { "stringValue": "Wait_For_Email_Reply" }
-        },
-        {
-          "name": "agentId",
-          "value": { "stringValue": "<replace-with-agent-id>" }
-        }
-      ]
-    }
-  ]
-}