Plain Message

Overview

When a contact reaches the Plain Message node (typically from the Init node), the node:

1. Reads the contact from msg.outboundMetadata.contact.cxCustomer

2. Resolves the customer's channel identifier (e.g. phone number, email) using Customer Identifier and Identifier Index

3. Personalizes content by replacing {{fieldName}} placeholders with contact data

4. For WhatsApp, builds an approved message template body (with mapped parameters) instead of plain text

5. Schedules the message for delivery via the Scheduler (POST /scheduled-activities)

6. Optionally forwards delivery notifications and customer responses to a downstream node when wired

If the contact is missing or has no valid identifier for the selected channel, the message is not sent and the contact is skipped.

Supported Digital Channels

The Channel dropdown is populated from CCM at edit time. Voice channels (CX_VOICE, CISCO_CC) are excluded — this node is for digital messaging only.

Prerequisite: The channel must be configured in CCM before it appears. If no digital channels are configured, the node editor shows an error.

Configuration Options

Plain Message configuration setup

1. Open the node editor — channels and contact fields load from CCM and the contact schema.

2. Select the Channel (WhatsApp, SMPP, Email, etc.).

3. Set Customer Identifier to the destination field (e.g. mobileNumber for WhatsApp/SMPP, email for Email).

4. If contacts can have multiple values for that field, set Identifier Index (1 = first, 2 = second, …).

5. For Email, fill in Subject.

6. For WhatsApp:

   • Select a WhatsApp Template (approved templates for that service).

   • If the template has placeholders, use Template Parameters to map each {{n}} to a customer attribute.

7. Write your Message using {{placeholder}} syntax (and/or @ attribute picker).

WhatsApp Templates

When templates are used

Templates are loaded from CCM (/get-whatsapp-templates?serviceIdentifier=...) for the selected WhatsApp channel.

Placeholders and parameter mapping

• CCM provides a parameters array (component + index). The UI shows one row per unique index (e.g. {{1}} shared by HEADER and BODY).

• If parameters is empty, the template has no mappable placeholders → schedule components: [].

• At send time, mapped attributes are resolved from the contact and sent in CIM format (parameterType + additionalParameterDetails).

• Footer text is part of the approved template on Meta; the scheduler does not send a footer component (only header, body, button).

Example schedule body (TEMPLATE)

{
  "type": "TEMPLATE",
  "namespace": "null",
  "name": "ef_campaign_full_test",
  "language": {
    "code": "en_US",
    "policy": "deterministic"
  },
  "components": [
    {
      "type": "header",
      "parameters": [
        {
          "parameterType": "text",
          "additionalParameterDetails": { "text": "Nasir Hussain" }
        }
      ]
    },
    {
      "type": "body",
      "parameters": [
        {
          "parameterType": "text",
          "additionalParameterDetails": { "text": "Nasir Hussain" }
        },
        {
          "parameterType": "text",
          "additionalParameterDetails": { "text": "923165392101" }
        }
      ]
    }
  ]
}

When Does It Send?

The node runs each time it receives a message from an upstream node (usually Init, one message per contact).

Normal send path

1. Contact exists in msg.outboundMetadata.contact.cxCustomer with a valid _id

2. The configured Customer Identifier has a non-empty value at the selected Identifier Index

3. The node builds a schedule request and posts it to the Scheduler

4. The Scheduler delivers on the selected channel (for WhatsApp templates, via the WhatsApp connector / Meta)

Skipped (no send)

• Contact missing, or missing _id

• Customer identifier missing or empty at the selected index
  → Counted in metrics as MISSING_CONTACT

Pass-through path (no re-send)

If msg.type is DELIVERY_NOTIFICATION or CUSTOMER_RESPONSE, the node forwards the message to its output without scheduling again. Use a downstream Post Attempt Decision (or similar) to branch on status / response.

Output

On successful schedule

The node does not emit a new message on the normal send path — it schedules and completes. Wire a delivery-notification path if you need post-send branching.

On delivery notification / customer response (when wired)

{
  "payload": {
    "body": {
      "status": "DELIVERED",
      "type": "DELIVERYNOTIFICATION"
    },
    "channelType": {
      "name": "WHATSAPP"
    }
  },
  "outboundMetadata": {
    "contact": {},
    "schedulingNodeId": "<plain-message-node-id>",
    "flowId": "<flow-id>"
  },
  "type": "DELIVERY_NOTIFICATION"
}

Message Personalization

Use double curly braces in Message and Subject (Email):

Hello {{firstName}}, your appointment is confirmed.

Type @ in the Message / Subject editors to pick a customer attribute from the schema.

Missing values: If a placeholder has no matching value, it is replaced with an empty string (not left as {{fieldName}}).

Labels: Customer records store label IDs. When Message/Subject contains {{labels}}, or a WhatsApp template parameter is mapped to labels, the node resolves labels[0] to its name via GET {CX_CUSTOMER_URL}/label. Results are cached using CACHE_TTL_MINS (same as other studio caches).

Channel-Specific Behavior