Agent Scripting resource failing validation in Terraform apply

Why does this config cause a 400 error when applying genesyscloud_script? The HCL defines flow_version but the API returns Field: flow_version, Error: invalid flow reference. Environment is ap-southeast-2 using provider v1.68.0. The flow exists and is published. CLI genesys cloud script:show works fine. Is there a mismatch in how Terraform resolves the flow ID versus the API? Logs attached.

Have you tried checking the flow ID format?

In Zendesk, ticket references were straightforward. Genesys Cloud scripts require the full resource ID, not just the name. Terraform might be resolving a partial match. Ensure the flow_version attribute points to the exact published version ID from the API response, not the generic flow ID. This mismatch often causes 400 errors during IaC migrations.

This looks like a scope alignment issue rather than a simple ID format error.

Is there a mismatch in how Terraform resolves the flow ID versus the API?

The script resource must reside in the same organization unit as the referenced flow. If the flow is published in a different OU, the validation fails. Verify the OU context in your Terraform configuration.

This looks like a scope alignment issue rather than a simple ID format error. The script resource must reside in the same organization unit as the referenced flow. Verify the OU context in your Terraform configuration.

It’s worth reviewing at the OU alignment first, as that’s the most common culprit for these validation errors. While the previous suggestions about ID formats are solid, I’ve seen this exact 400 error pop up when the script and flow live in different organizational units, even if the IDs are technically correct.

Here are a few things to check:

  • Verify OU Context: Ensure the genesyscloud_script resource is explicitly assigned to the same OU as the referenced flow. If the flow is in a child OU and the script is in the parent (or vice versa), the API rejects it.
  • Check Flow Version ID: Double-check that you’re using the specific version ID of the published flow, not just the base flow ID. The provider sometimes struggles to resolve the latest version automatically.
  • Review Permissions: Make sure the Terraform service account has read access to the flow’s OU. A 400 error can sometimes mask a permission issue where the provider can’t validate the reference.

Since I spend my days wrestling with WFM schedule publishing and agent self-service permissions, I know how finicky Genesys Cloud can be with cross-resource references. It’s frustrating, but usually a quick OU check solves it. If the OUs match, try forcing a refresh of the state file to ensure the provider isn’t holding onto stale data.