Service De Channel Create

Inserting Messaging Channels

Reference File Index

What this skill does

Given a {MESSAGE_TYPE} and its inputs, creates a MessagingChannel record with PlatformType=Enhanced, IsActive=false. The same server-side path (LiveMessageSetupServiceImpl.addChannel → LiveMessageChannelsUtil.findOrCreateCsotMessagingChannel) also inserts a MessagingChannelUsage row (DeploymentType=Conversation, DeploymentStatus=New on fresh insert — Disabled on a channel that was previously activated then deactivated) — we get it for free.

One primary path for every type: Connect REST API. POST /services/data/v{V}/connect/livemessage/channels with an org OAuth session managed by sf api request rest. Public, sanctioned, live since API v66+. No Aura session, no token extracted into shell state.

Idempotent on (MessagingPlatformKey, MessageType) — re-firing with the same platform key returns the existing channel's id. This matters because MessagingChannel records are not deletable via standard means, so the preflight (Stage 1) is the practical idempotency guard.

All types return the same envelope shape, so callers don't branch on type after insert: {ok, channelId, mcuId, developerName, isActive:false, messageType, messagingPlatformKey, path, created, durationMs}.

Supported types (the only branch point)

Unsupported (would need their own leaf logic, not yet built): WeChat, MsCopilot, Alexa. For these, emit the unsupported-type envelope (Stage 0).

When NOT to use this skill

• End-to-end setup. If the user wants insert → route → activate, invoke service-de-headless-channel-configure — it orchestrates this skill plus routing, consent, and activation. This skill only handles the insertion step (see Stage 0).
• The channel already exists and you only want to re-route / activate it. Skip insertion; call service-de-channel-routing-configure / service-de-channel-activate with the existing channelId.

Inputs (from caller)

• {MESSAGE_TYPE} — one of WhatsApp, Line, AppleBusinessChat, Facebook, Text. Case-sensitive (matches the SF picklist). Text is the enum value for SMS — there is no SMS type.
• {ORG_ALIAS} — optional; sf CLI target-org alias. Default: sf config get target-org.
• {API_VERSION} — optional; Connect API version. Default: the org's current API version (sf org display --json | jq -r '.result.apiVersion'). Always use the org's native version to avoid 404s.
• {CHANNEL_NAME} — display name shown in Setup → Messaging Settings. Required for AppleBusinessChat (no phone/screen-name fallback); prompted if omitted for others.

Type-specific inputs:

• WhatsApp: {WABA_ID} (sent as externalAccountId), {PHONE_NUMBER_ID} (the platform key — must differ from WABA_ID), {ISO_COUNTRY_CODE} (optional, default US).
• Line: {LINE_CHANNEL_ID} (platform key), {LINE_CHANNEL_SECRET}, {LINE_ACCESS_TOKEN}, {VERIFY_TOKEN_FIRST} (optional, default true).
• AppleBusinessChat: {APPLE_BC_ID} (platform key, GUID).
• Facebook: {PAGE_ID} (optional — OAuth fetches/prompts if absent).
• Text (SMS): {SMS_NUMBER} (the platform key — the phone number / short code string, already provisioned to the org), {SMS_PROVIDER} (sent as smsProvider — the smsProvider key must be present in the body or the insert 400s with "SMS provider is missing", but its value is not validated or stored, so an empty string "" works; default to "" when the caller doesn't supply a provider), {ISO_COUNTRY_CODE} (optional, default US). This skill does not provision the number — the caller must already know their number.

Output (to caller)

Success:

{"ok": true, "channelId": "0Mj...", "mcuId": "0gL...", "developerName": "...",
 "isActive": false, "messageType": "{MESSAGE_TYPE}", "messagingPlatformKey": "...",
 "path": "connect" | "preflight", "created": true | false, "durationMs": 1234}

created: false + path: "preflight" means the row already existed and was returned idempotently.

Failure (shared):

{"ok": false, "kind": "wrong-skill", "correctSkill": "service-de-headless-channel-configure", "hint": "..."}
{"ok": false, "kind": "unsupported-type", "supportedTypes": ["WhatsApp","Line","AppleBusinessChat","Facebook","Text"], "hint": "..."}
{"ok": false, "kind": "missing-input", "missing": ["..."], "hint": "caller must provide all required inputs for this type"}
{"ok": false, "kind": "auth",     "hint": "OAuth token invalid / expired — run 'sf org login web'"}
{"ok": false, "kind": "business", "message": "...", "errorCode": "..."}
{"ok": false, "kind": "transport","status": 500, "message": "..."}
{"ok": false, "kind": "verify-failed", "hint": "Connect returned 201 but follow-up SOQL shows no matching channel"}

Type-specific failure kinds (partnership-blocked, user-declined, waba-manage-failed, meta-precondition for WhatsApp; line-token-invalid for LINE; apple-precondition for Apple; oauth-not-complete, oauth-failed for Facebook) are documented in the per-type reference files.

Stage 0: Enforce orchestrator-only invocation

This skill is INTERNAL USE ONLY. It should only be invoked by the service-de-headless-channel-configure orchestrator.

If the user's original request was to "install", "set up", "create", or "activate" a messaging channel (or any phrasing that implies end-to-end setup), immediately return:

{
  "ok": false,
  "kind": "wrong-skill",
  "hint": "This is an internal insertion skill. For end-to-end channel setup (insert → route → activate), invoke 'service-de-headless-channel-configure' instead with the desired MESSAGE_TYPE.",
  "correctSkill": "service-de-headless-channel-configure"
}

And render to the user:

Error: Wrong skill invoked.

This skill (service-de-channel-create) only handles the insertion step.
For complete channel setup, use: /service-de-headless-channel-configure

That orchestrator runs: insert → configure routing → activate in one flow.

Only proceed to Stage 0.1 if:

• This skill was invoked programmatically by service-de-headless-channel-configure
• The user explicitly stated they ONLY want insertion (not routing or activation)
• This is a retry/resume scenario where routing/activation already succeeded

When in doubt, redirect to the orchestrator.

Stage 0.1: Validate type and required inputs

Look up {MESSAGE_TYPE} in the supported-types table. If absent, emit the unsupported-type envelope and return.

Validate the type's required inputs are present (Facebook is the exception — no required inputs; OAuth → page selection → prompts happen inside the Facebook flow). If any are missing, emit missing-input with the list and return.

WhatsApp only: additionally assert {WABA_ID} != {PHONE_NUMBER_ID} — they are distinct Meta entities and reusing one value for both causes cryptic activation failures. If equal, emit {ok:false, kind:"invalid-input", hint:"WABA_ID and PHONE_NUMBER_ID must differ — WABA_ID is the WhatsApp Business Account ID; PHONE_NUMBER_ID is a specific phone number within it. Find both in Meta Business Manager → WhatsApp Accounts."}.

Capture {T0} = Date.now() for durationMs.

Stage 0.2: Establish the scratch directory

Every transient artifact this skill writes (preflight query results, request bodies, Connect responses) goes into a per-run scratch directory rooted inside the harness working area — never a bare absolute /tmp path, which is world-writable and non-portable. Establish it once:

SCRATCH_DIR="$(mktemp -d "${outputDir:-${TMPDIR:-/tmp}}/icc.XXXXXX")"

The base dir is the harness-provided ${outputDir} when set, else the private user-scoped ${TMPDIR}, else /tmp only as a last resort. All later stages (and the reference flows) write under ${SCRATCH_DIR}/; the durable report stays under ${outputDir}.

Stage 1: Preflight — is the channel already here?

SOQL-probe for an existing row first; a hit lets us skip all prerequisites and the insert.

For Facebook without a {PAGE_ID}, skip this stage — the page id isn't known until OAuth → page selection completes (see references/facebook.md). Run the preflight after page selection.

Two queries, not a subquery. The (SELECT ... FROM MessagingChannelUsages) child subquery fails with INVALID_TYPE on orgs where the child relationship is unnameable (verified on wadtesting / PRODDEBUG). The FK-keyed form works everywhere.

sf data query --target-org '{ORG_ALIAS}' \
  --query "SELECT Id, DeveloperName, MasterLabel, IsActive, MessagingPlatformKey FROM MessagingChannel WHERE MessagingPlatformKey = '{PLATFORM_KEY}' AND MessageType = '{MESSAGE_TYPE}'" \
  --json > "${SCRATCH_DIR}/preflight.json"

If records.length === 1:

• Record {CHANNEL_ID}, {DEVELOPER_NAME}, {IS_ACTIVE}.
• Second query for the MCU by FK:

  sf data query --target-org '{ORG_ALIAS}' \
    --query "SELECT Id, DeploymentStatus FROM MessagingChannelUsage WHERE MessagingChannelId = '{CHANNEL_ID}'" \
    --json > "${SCRATCH_DIR}/preflight-mcu.json"

  Record {MCU_ID} (empty MCU: flag, don't fail — the activation skill handles it).
• Emit the success envelope with path: "preflight", created: false. Return.

If records.length > 1: ambiguous (uniqueness should prevent this) — proceed with the first, note a warning in the envelope.

If records.length === 0: proceed to Stage 2.