Set Participant Data action dropping custom vars in IVR flow

Architect & Flows
1

Stumbled on a weird bug today with the Set Participant Data action in Architect. Using hashicorp/genesyscloud v1.42.0 to provision the flow. The action executes without error but the custom variable custom.ext_ref is not visible in subsequent Data Actions or via the Conversations API GET /api/v2/conversations/medias/{mediaId}.

JSON payload sent to action:

{
 "type": "SetParticipantData",
 "variables": {
 "custom.ext_ref": "{{trigger.ref_id}}"
 }
}

Any known quirks with variable persistence in this specific action type?

2

If I remember right, the SDK model for SetParticipantData requires explicit schema registration for custom keys; otherwise, the parser drops them as unknown. Use the customAttributes field in the action config, not data.

  • Architect action schema definitions
  • customAttributes vs data mapping
  • SDK model validation rules
3

TL;DR: Custom keys often vanish if you bypass the strict schema validation in the data object.

Check your action configuration payload structure. The suggestion above regarding customAttributes is partially correct, but you are likely hitting a deeper serialization issue with the hashicorp/genesyscloud provider. When you define custom variables in a SetParticipantData action, they must be explicitly mapped under the customAttributes property of the action definition, not just passed as raw key-value pairs in the data blob. The Genesys Cloud Architect engine treats unknown keys in data as invalid and silently discards them during the flow compilation phase.

Here is the corrected Terraform snippet to ensure persistence:

resource "genesyscloud_flow" "my_flow" {
 flow {
 # ...
 actions {
 type = "SetParticipantData"
 customAttributes = {
 "custom.ext_ref" = "${expression('flow.custom.ext_ref')}"
 }
 # Do not place custom keys in the 'data' block here
 }
 }
}

If you still see 404s on GET /api/v2/conversations/medias/{mediaId}, verify the OAuth token used for retrieval has the conversation:read scope. I have seen race conditions where the metric ingestion pipeline reads the conversation state before the participant data has fully propagated to the analytics store. Add a small delay or retry logic in your Datadog agent configuration if you are fetching this data in real-time.

4

The simplest way to resolve this is to explicitly map custom keys under the customAttributes object in your action configuration.

Cause:
The SetParticipantData action schema treats the standard data object with strict validation. Any key not defined in the base schema is silently dropped during serialization by the Terraform provider. This behavior is consistent with how the Guest API handles unregistered metadata, where explicit registration is required for persistence.

Solution:
Update your Terraform configuration to nest your custom variables inside customAttributes. This ensures the payload survives the validation layer and propagates to the conversation context.

resource "genesyscloud_flow" "example" {
 ...
 actions {
 type = "SetParticipantData"
 data = {
 customAttributes = {
 "ext_ref" = "${trigger.ext_ref}"
 }
 }
 }
}

Verify the variable persists by checking the conversations/medias/{mediaId} endpoint. The customAttributes field should now reflect the value.

5

The documentation actually says https://developer.genesys.cloud/architect/actions/set-participant-data that customAttributes is the correct payload structure. I verified this in our staging workspace using Terraform v1.42.0. Switching from data to customAttributes fixed the serialization drop.