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 address) using Customer Identifier and Identifier Index

3. Personalizes the message body by replacing {fieldName} placeholders with contact data

4. Schedules the message for delivery via the Scheduler

5. Optionally forwards delivery notifications back into the flow when wired to a downstream node

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

Category

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 in the Plain Message node. If no digital channels are configured, the node editor will show an error.

Configuration Options

Plain Message configuration setup

• Open the node editor — channels and contact fields are loaded automatically from CCM and the contact schema.

• Select the Channel that matches how you want to reach the customer (WhatsApp, SMPP, Email, etc.).

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

• If contacts can have multiple values for that field, set Identifier Index to pick the correct one (1 = first, 2 = second, and so on).

• For Email, fill in Subject — this field only appears when an Email channel is selected.

• Write your Message using {placeholder} syntax for personalization.

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 field has a non-empty value at the selected Identifier Index

3. The node builds a schedule request and posts it to the Scheduler (POST /scheduled-activities)

4. The Scheduler delivers the message on the selected channel

Skipped (no send):

• Customer identifier field is missing or empty at the selected index

• Skipped contacts are counted in metrics as MISSING_CONTACT

Delivery notification path:

If the Scheduler returns a delivery result and the flow is wired for it, a message with type: "DELIVERY_NOTIFICATION" arrives back at this node. The node passes it through to its output without re-sending — use a downstream Post Attempt Decision node to branch on delivery status.

Output

On successful schedule (no downstream wire required)

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

On delivery notification (when wired)

When a DELIVERY_NOTIFICATION arrives (from the Scheduler webhook loop), the node forwards the message to its output:

{
  "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 curly-brace placeholders in the Message (and Subject for Email):

Hello {firstName}, your appointment is confirmed.

If a placeholder has no matching value, it is left as-is in the message.

Channel-Specific Behavior