Service De Channel Consent 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.

1. 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

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:

{"ok": true, "noop": true, "consentType": "ImplicitOptIn|ExplicitOptIn|DoubleOptIn", "languageKeywordIds": ["3Or..."], "message": "Consent already configured and activation-ready"}

Success — consent configured:

{"ok": true, "consentType": "ExplicitOptIn", "channelFieldsSet": ["ConsentType","OptInPrompt"],
 "languageKeywordId": "3Or...", "language": "en_US", "created": true|false, "activationReady": true}

Precondition / validation not met:

{"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:

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

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):

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):

¹ 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:

Opt-in prompt (sent when a reply doesn't match an opt-in keyword):

For DoubleOptIn, also:

Double-opt-in prompt (sent when a reply doesn't match a double-opt-in keyword):