/service-de-headless-channel-configure

name: service-de-headless-channel-configure
description: "Top-level orchestrator: given a messaging channel type and its inputs, produces an activated Enhanced `MessagingChannel` in the target org — without the Meta/LINE/Apple setup popups. Prompts for `{MESSAGE_TYPE}` if not supplied, then sequences insert → route → consent → activate → requested settings (auto-responses, keywords, session inactivity) via the type-agnostic dispatcher (`service-de-channel-create`) plus the shared routing/settings/activation leaves, and reports every requested setting as configured, not applicable, or failed. Resumes from partial state on re-run. Use to set up an Enhanced channel (WhatsApp, Facebook, LINE, Apple, SMS) end-to-end, bypassing in-org setup popups. Do not use for a single stage of an already-inserted channel — use the matching leaf skill (`service-de-channel-activate`, `service-de-channel-settings-configure`, `service-de-channel-routing-configure`) instead."
metadata:
  version: "1.0"
  minApiVersion: "67.0"
  domains: ["Service"]
  cliTools:
    - tool: ["sf"]
      semver: ">=2.0.0"
  relatedSkills:
    - "service-de-channel-activate"
    - "service-de-channel-create"
    - "service-de-channel-routing-configure"
    - "service-de-channel-settings-configure"
    - "service-de-waba-integrate"

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 core steps plus an optional settings step:

0. **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)* 1. **Insert the channel** — invokes `service-de-channel-create`, which handles each type's third-party prereq (e.g. WhatsApp's `service-de-waba-integrate`). *(skill: `service-de-channel-create`)* 2. **Configure routing** — sets `SessionHandlerId` to an Omni-Channel Queue (pick existing or create new). Message-type-agnostic. *(skill: `service-de-channel-routing-configure`)* 3. **Configure consent** — ensures a valid `ConsentType` + matching `MsgChannelLanguageKeyword` record (often a **no-op**: the insert auto-seeds `ImplicitOptIn`). Activation's readiness check needs routing AND consent, so this runs before activation. *(skill: `service-de-channel-settings-configure`)* 4. **Activate** — PATCHes `MessagingChannelUsage.DeploymentStatus` to `Provisioning`; the save-hook runs synchronously and returns 204 once the channel is `IsActive=true`. Message-type-agnostic. *(skill: `service-de-channel-activate`)* 5. **Configure requested settings** — only if the request asked for auto-responses, keywords, or session inactivity. Runs **after** activation and is **non-blocking**: a failure is a warning, never a failed run, and every requested setting is reported as configured, not applicable, or failed. *(skill: `service-de-channel-settings-configure`, Stage 4.5)*

**Resume-by-default.** Each step is idempotent: a re-run detects existing state and skips steps that already succeeded.

**Prompt mid-flow.** A missing `{MESSAGE_TYPE}` is asked upfront; routing choices are prompted when step 2 runs.

Reference File Index

| Reference file | Load when | | --- | --- | | `references/inputs.md` | You need the full input field list — MESSAGE_TYPE/ORG_ALIAS plus per-type fields for WhatsApp, LINE, AppleBusinessChat, Facebook, Text (SMS). | | `references/terms-and-conditions.md` | Rendering the Stage 0.5 disclaimer and certification prompt — verbatim text and per-type label/third-party mappings. | | `references/output-envelopes.md` | Wiring error handling or parsing the canonical success/failure/terms-declined JSON envelope shapes. | | `references/partial-success.md` | The orchestrator fails mid-way and you need to render the partial-success/resume report. | | `references/gotchas.md` | Debugging unexpected behavior — duplicate-key errors, resume/idempotency questions, preflight SOQL shape, unattended/CI usage, dropped settings, missing AuthProvider. | | `references/requested-settings.md` | Running Stage 4.5 (auto-responses, keywords, inactivity) or rendering requested settings in the Stage 5 report. | | `references/worked-examples.md` | You need a reference trace (fresh run, resume, Apple dispatch, unsupported type, requested settings) for exact envelope shapes. |

---

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:** Parse the return value immediately and run Stages 0.5 → 1 → 2 → 3 → 3.5 → 4 → 4.5 → 5 consecutively in ONE response
• **DO NOT:** Stop, report back, or wait for confirmation between stages, or treat each stage as a separate turn

**Why:** the user asked for an end-to-end activated channel; stopping mid-flow forces them to resume each stage by hand.

**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). The WhatsApp OTP prompts in `service-de-channel-activate` are also an allowed pause — wait for the user's input, then continue. Then report the failure immediately with context about which stage failed and what state was reached.

**Stage 0.5 is a required blocking prompt** — never auto-accepted. A decline ends the run; a `yes` continues to Stage 1 in the same response.

**Leaf skill prompts:** leaves like `service-de-waba-integrate