Service De Headless Channel Configure

Headless Channel Setup (type-agnostic)

What this skill does

Takes a channel type (WhatsApp | Line | AppleBusinessChat | Facebook | Text) plus its type-specific inputs and drives it to an activated MessagingChannel. It first gates on the Enhanced Messaging Terms and Conditions, then runs four steps:

1. Accept Terms and Conditions — renders the Enhanced Messaging disclaimer and requires the user to certify they have authority to bind their org, mirroring the in-org "Add a Channel" wizard. Blocking — a decline ends the run before any org work. (Stage 0.5, in this skill)
2. Insert the channel — invokes service-de-channel-create, which handles the per-type third-party prereq internally (e.g. WhatsApp's service-de-waba-integrate runs inside service-de-channel-create). (skill: `service-de-channel-create`)
3. Configure routing — sets SessionHandlerId to an Omni-Channel Queue (pick existing or create new). Message-type-agnostic. (skill: `service-de-channel-routing-configure`)
4. Configure consent — ensures a valid ConsentType + matching MsgChannelLanguageKeyword record. The Connect insert auto-seeds a default ConsentType=ImplicitOptIn + opt-out keyword, so on a fresh channel this step is frequently a no-op — or an upgrade if the caller wants ExplicitOptIn/DoubleOptIn. Activation's readiness check requires both routing AND consent, so this runs before activation. (skill: `service-de-channel-settings-configure`)
5. Activate — PATCHes MessagingChannelUsage.DeploymentStatus to Provisioning via REST; the server-side save-hook drives the full observer chain synchronously and returns 204 once the MCU reaches Active and MessagingChannel.IsActive=true. Message-type-agnostic. (skill: `service-de-channel-activate`)

Resume-by-default. Each step is idempotent — if you re-run after a failure, the orchestrator detects existing state and skips steps that already succeeded.

Prompt mid-flow. If {MESSAGE_TYPE} isn't in the initial request, the orchestrator asks upfront. Routing choices (pick queue / create new) are prompted when step 2 runs, not upfront — keeps leaf skills self-contained.

Reference File Index

Critical execution rule

This orchestrator MUST run all stages (0-5) in a SINGLE response without stopping between stages.

When you invoke a leaf skill (service-de-channel-create, service-de-channel-routing-configure, service-de-channel-settings-configure, service-de-channel-activate) and it returns via function_results:

• DO: Immediately parse the function_results return value and continue to the next stage
• DO: Run Stage 0.5 → Stage 1 → Stage 2 → Stage 3 → Stage 3.5 → Stage 4 → Stage 5 consecutively in ONE response
• DO NOT: Stop and report back to the user between stages
• DO NOT: Wait for user confirmation between stages
• DO NOT: Treat each stage as a separate turn in the conversation

Why this matters: The user invoked THIS orchestrator skill to get an end-to-end activated channel. They did NOT invoke the individual leaf skills. Your job is to run the entire pipeline autonomously and report the final result. Stopping mid-flow breaks the orchestrator pattern and forces the user to manually resume each stage.

Exception: Only stop mid-flow if a leaf skill returns ok: false with a terminal error (not a recoverable prompt), or if the user declines the Stage 0.5 Terms and Conditions gate (emit terms-not-accepted and halt). Then report the failure immediately with context about which stage failed and what state was reached.

Stage 0.5 is a required blocking prompt. The Terms and Conditions gate is the one prompt that must be answered affirmatively before any org work. It is not optional and must not be auto-accepted. A no/decline ends the run per the exception above; a yes continues to Stage 1 in the same response.

Leaf skill prompts: Some leaf skills (like service-de-waba-integrate or service-de-channel-routing-configure) may prompt the user for input mid-execution. That's fine — answer those prompts as they come up, but then CONTINUE to the next stage immediately after the prompt is answered. Don't stop just because a prompt was involved.

When NOT to use this skill

• You only want one step. Invoke the leaf skill directly (service-de-channel-create, service-de-channel-routing-configure, service-de-channel-activate). This orchestrator is for the full automated path from nothing → activated channel.
• You want to run stages independently in separate conversation turns. This orchestrator runs all stages consecutively in one response. If you need manual control between stages, invoke the leaf skills individually.
• You want a message type outside `WhatsApp` / `Line` / `AppleBusinessChat` / `Facebook` / `Text`. The dispatcher will return unsupported-type. WeChat / MsCopilot / Alexa would need their own leaves + a dispatcher update.
• The prereq hasn't been met (WABA not shared, LINE channel not created, Apple account not registered, SMS number not provisioned). The per-type insert skill's Stage 2-equivalent surfaces this clearly and returns; no orchestration fixes it. (For SMS/Text the number-provisioning prereq isn't checked at insert — an unprovisioned number surfaces later as an activation-time provisioning-error.)

Inputs (from user)

{MESSAGE_TYPE} (prompted if omitted) and {ORG_ALIAS} (optional), plus type-specific fields for WhatsApp, LINE, AppleBusinessChat, Facebook, and Text (SMS) forwarded to the dispatcher. Load `references/inputs.md` and follow it for the full field list and the omitted-type prompt text.

Output (to user)

Three top-level outcomes: success, step-annotated failure, and terms-declined. Load `references/output-envelopes.md` and follow it for the exact JSON shapes.

Stage 0: Resolve {MESSAGE_TYPE} and type-specific key

If {MESSAGE_TYPE} is omitted, prompt the user (see "Inputs" above). Refuse to proceed without one — there's no sensible default.

Once known, determine the preflight key — the field we'll filter the MessagingChannel SOQL on to detect existing state. It's always MessagingPlatformKey, but what that value is varies by type: