Set Participant Data action wiping custom variables after first IVR node

Architect & Flows
1

The IVR flow keeps swallowing the custom variables right after the Set Participant Data action. It works fine on the first prompt, but by the time the call hits the second IVR node, the payload is completely wiped. We’re pushing CRM tokens through the flow, and the extension grabs them via chrome.runtime.sendMessage. Everything looks clean in the console until the call routes.

Here’s the JSON we’re feeding into the data action:

{
 "action": "setParticipantData",
 "data": {
 "customFields": {
 "crmTicketId": "{{flow.campaignId}}",
 "priorityLevel": "high",
 "agentOverlayReady": true
 }
 }
}

The Architect runtime logs show a 200 OK on the initial assignment. Downstream WebSocket events drop the customFields object entirely. Checked the client application SDK docs and the getParticipant method returns an empty map after the IVR branch.

We’ve already run through the basics:

  1. Wrapped all values in strings to force strict serialization.
  2. Moved the assignment before the initial IVR prompt node.
  3. Logged the raw participant map via the debug console.

Nothing sticks. The cross-origin request from the extension pulls the correct payload, so the break happens during flow serialization. Documentation just says to pass a flat object. The runtime keeps flattening it into null values after the first conditional. We need the data to persist across the entire IVR tree without rebuilding the map manually at each step.

Checked the schema validator twice. Still returns empty.

2

PureCloudPlatformClientV2 actually enforces strict variable scoping when the flow definition lacks an explicit persistence directive. The runtime engine treats any custom payload pushed through Set Participant Data as a local node variable unless it’s explicitly bound to the conversation context. Here is how the resolution unfolds. First, the JSON payload needs a matching variable definition in the flow schema. Without it, the engine drops the values after the initial node execution because the state manager cannot serialize them across route transitions. Honestly, it’s a common oversight when building flows outside the standard templates.

The deployment configuration usually handles this by declaring the variables upfront. When pushing the flow through the CX-as-Code provider, the variables array requires a scope property set to conversation. Take a look at the structure.

"variables": [
 {
 "name": "crm_token",
 "scope": "conversation",
 "type": "string"
 }
]

Next, the Set Participant Data action itself must reference that exact schema name. The action payload should map the incoming extension data directly to the pre-registered variable. Something along these lines works consistently.

{
 "actionType": "setParticipantData",
 "variable": "crm_token",
 "value": "{{extension.token}}"
}

State drift often occurs when the Terraform module applies a flow update without regenerating the variable registry. The provider won’t silently skip undeclared variables during the diff calculation. Running a terraform plan with -refresh-only usually surfaces the missing schema entries. After that, a standard apply pushes the corrected definition. The routing engine stops wiping the payload because the conversation state object now has a valid reference point. You can verify the persistence by checking the debug logs at the second IVR node. The variable should appear in the context dump without any manual intervention. The extension sync remains untouched throughout the process. Just make sure the flow versioning aligns with the active deployment target. The debug logs will show the payload intact.

3

Scoping isn’t the only issue. Set Participant Data often flushes on node boundaries unless pinned to the conversation object. Old community threads flag this wrecking callback retries too. Swap to Set Flow Data for the CRM token. Keeps the vars alive across hops.

{
 "actionType": "SetFlowData",
 "key": "crm_token",
 "value": "{{trigger.payload.crm_id}}"
}

Check the retry timer config.

4

The suggestion above hits the mark. Set Participant Data acts like a local variable container. It’s flushing the payload the moment the node boundary is crossed. Swapping to Set Flow Data forces the engine to pin the key to the session object, keeping the CRM token alive across hops.

There’s a gotcha with this pattern. If the flow uses a Data Table lookup inside that first IVR node, the lookup module can reset the local scope on a cache miss. This wrecks callback logic frequently. Check the community posts on version 2.3 quirks for similar scope resets.

Verify the binding immediately after the set action.

{
 "key": "crm_token",
 "type": "flow",
 "value": "{{trigger.payload.crm_id}}"
}

Is the org running the latest Architect runtime patch?