Terraform 422 on genesyscloud_flow during IVR prompt binding in EU1 prod

Architect & Flows
1

resource “genesyscloud_flow” “ivr_main_eu1” {
name = “Berlin IVR Gateway”
description = “Primary routing orchestration”
enabled = true
type = “IVR”
}

Executed against terraform 1.6.4 and genesyscloud 1.38.0 on EU1 prod. The deployment throws a 422 validation block during the audio prompt binding. It’s flagging a workspace hierarchy conflict but the division IDs match. The orchestration handshake just fails. Staging accepted the exact same payload. The Architect console marks the media assets as detached. State refresh keeps looping. Don’t see a trace ID in the logs.

2

The 422 usually trips when the prompt resource lives in a different division scope than the flow itself. Even if the IDs look identical in the console, Terraform resolves them against the provider default unless you explicitly set division_id on both resources. The EU1 prod environment is stricter about cross-division references during the initial handshake.

Try adding the division_id attribute directly to the prompt resource and reference it inside the flow configuration. A bare genesyscloud_flow resource won’t bind audio without the nested structure. The flow needs to know exactly where to pull the greeting from. Here is how the structure should look:

resource "genesyscloud_prompt" "ivr_intro" {
 name = "Berlin IVR Intro"
 description = "Initial greeting for containment"
 division_id = var.eu1_main_division_id
 prompt {
 language = "en-GB"
 file_path = "assets/intro.wav"
 }
}

resource "genesyscloud_flow" "ivr_main_eu1" {
 name = "Berlin IVR Gateway"
 description = "Primary routing orchestration"
 enabled = true
 type = "IVR"
 division_id = var.eu1_main_division_id
}

The community thread on prompt scope mismatches last month showed the same exact 422 pattern. The API rejects the payload because it cannot verify the asset exists within the requested workspace boundary. Push the division variable through explicitly. Also check if the prompt is actually published. Unpublished prompts block the flow save even when the syntax looks fine. The user experience drops immediately if the greeting fails to load anyway. Containment metrics suffer when callers hit dead air instead of a proper DTMF menu. A creative IVR path falls apart if the first node is just empty space. Verifying the asset state saves a lot of troubleshooting later. The queue just hangs if the asset isn’t live.

1 Like