Init Node

Node

Init

Description

This node init node.png pulls contacts for the campaign and sends them into the flow one at a time. Contacts are synchronized in the background using a Customer Filter, while the number of contacts released into the flow is controlled by a configurable query.

Overview

The Init node has two responsibilities:

Contact Synchronization – When the flow is deployed, the node requests the Campaign Backend to start a background synchronization job. This job periodically imports contacts from CX Customers that match the selected Customer Filter.

Contact Delivery – When the node receives an input message, it pulls eligible synchronized contacts and sends them into the flow one at a time.

The synchronization process is independent of flow execution and may already have imported contacts before the node is triggered for the first time.

Category

Inputs

Outputs

Default Label

Contact Operations

1

2

Node name, or "Init" if left blank

Configuration Options

Setting

Default

What it does

Name

(blank)

Optional label for the node

Customer Filter

(required)

Determines which customers from CX Customers are eligible to be synchronized into the campaign

Order

Oldest First (FIFO)

Controls contact selection order (FIFO / LIFO)

Query

(required)

PromQL expression that defines how many contacts are pulled per execution

Query (Contact Pull Logic)

The Query field controls how many contacts are pulled from the synchronized pool per execution of the node.

It can be configured in two ways:

  • Static value (e.g., 1, 5, 10)

    • Acts as a fixed batch size per execution

    • Commonly used for progressive or power-style pacing

  • Dynamic PromQL expression

    • Used for adaptive or predictive dialing behavior

    • Batch size changes based on real-time system metrics

Example Query

scalar(
  sum(
    clamp_min(
      (
        (
          1 /
          clamp_max(
            (
              (
                clamp_min(
                  (sum(increase(ob_call_human_detected_total{flowId="<campaign-flow-id>"}[2h])) OR on() vector(0)),
                  1
                )
              )
              /
              clamp_min(
                (sum(increase(ob_contacts_sent_for_dialing_total{flowId="<campaign-flow-id>"}[2h])) OR on() vector(0)),
                1
              )
            ),
            1
          )
        )
        *
        (
          1 - (
            (
              (sum(increase(ob_abandoned_calls_total{flowId="<campaign-flow-id>"}[2h])) OR on() vector(0))
              /
              clamp_min(
                (sum(increase(ob_call_human_detected_total{flowId="<campaign-flow-id>"}[2h])) OR on() vector(0)),
                1
              )
            )
            / 0.03
          )
        )
      ),
      0
    )
  )
)

init node config.png


What This Query Does (High Level)

  • Dynamically controls contact throughput per execution

  • Reduces load when human detection increases

  • Applies penalty when abandonment rate exceeds threshold (3%)

  • Acts as a real-time campaign pacing / throttling mechanism


Contact Synchronization

When Synchronization Starts

As soon as the flow is deployed, the Init node requests the Campaign Backend to start a synchronization job for the selected Customer Filter.

This happens without waiting for the Start node or any other trigger.

Campaign State Requirement

Synchronization only imports contacts when the campaign is in Published state.

If deployed while unpublished:

  • Sync job is registered

  • Initial sync is skipped

  • Contacts are only imported after a later sync cycle once the campaign is published

Synchronization Schedule

The backend runs periodic sync based on:

CX_CUSTOMER_SYNC_INTERVAL_IN_MINUTES

What Gets Synchronized

Only customers matching the selected Customer Filter are synchronized into the campaign.


What Happens When This Node Runs

When an input message reaches the Init node:

  1. The PromQL query is executed

  2. Result is rounded up to a whole number

  3. This defines batch size for contact delivery

  4. Eligible synchronized contacts are selected

  5. Ordering is applied (FIFO / LIFO)

  6. Each contact is emitted as a separate message

The node never pulls directly from CX Customers — only from synchronized campaign contacts.


Filter Changes and Existing Contacts

Changing the Customer Filter does not reset or recreate existing campaign contacts.

Contacts that were already synchronized retain their current campaign state, for example:

  • DELIVERED

  • UNDELIVERED

  • Other campaign-specific statuses

These existing states are preserved after a filter change; only the syncVersion is updated, ensuring that contacts which no longer satisfy the new filter are not considered again for this flow.


Runtime Eligibility Check

Even if a contact was previously synchronized, the Init node re-validates eligibility before sending.

If a customer no longer matches the active filter due to:

  • filter definition update

  • customer attribute change

then the contact is excluded from being sent into the flow.


Status Indicators

Status

Meaning

🔵 Blue ring

Waiting for input

🟡 Yellow ring

Query evaluated to 0 contacts

🟢 Green dot

Contacts being processed/sent

🔴 Red ring

Missing configuration or runtime error