Terraform - `genesyscloud_flow_execution_association` resource failing to apply

Hey everyone,

Been wrestling with a weird one and hoping someone’s hit this before. We’re automating flow association via Terraform - part of a larger disaster recovery setup, naturally - and the genesyscloud_flow_execution_association resource is failing intermittently during terraform apply. It’s not consistent, which is…less than ideal. It’s not a permissions issue, that’s the first thing I checked.

The core problem is it’s throwing a “Resource not found” error, specifically pointing to the flow_execution_id. Now, the flow execution ID does exist, and Terraform successfully retrieves it during the plan phase. It’s just that during apply, the lookup fails. It seems like a race condition, but I’m struggling to pinpoint the exact timing issue. You’ll see what I mean.

Let’s break down what’s happening. The genesyscloud_flow_execution_association resource links a flow execution to a queue, right? This is crucial for our DR runs - we need to dynamically associate backup flows to queues when we failover. The resource relies on the flow execution being already created - it doesn’t create the flow execution itself, it just associates it. So, we have a separate resource that creates the flow execution using genesyscloud_flow_execution. This is all done in Terraform, obviously.

Here’s the relevant snippet from the Terraform code:

resource "genesyscloud_flow_execution" "dr_flow" {
 name = "DR Flow - ${var.environment}"
 flow_id = genesyscloud_flow.main_flow.id
 description = "Flow execution for disaster recovery"
}

resource "genesyscloud_flow_execution_association" "queue_association" {
 flow_execution_id = genesyscloud_flow_execution.dr_flow.id
 queue_id = genesyscloud_queue.main_queue.id
}

The genesyscloud_flow_execution.dr_flow.id is what’s failing to resolve during the apply step. It’s there in the plan output, but then gone in the apply.

The error message looks like this:

Error: Resource not found

 on main.tf line 27, in resource "genesyscloud_flow_execution_association" "queue_association":
 27: flow_execution_id = genesyscloud_flow_execution.dr_flow.id
 28: queue_id = genesyscloud_queue.main_queue.id

The value of the attribute flow_execution_id (ID) is not available. This likely means the resource does not exist or has been deleted.

I suspect there’s a timing issue with the Genesys Cloud API. It’s possible the flow execution isn’t fully propagated across all systems before Terraform attempts to associate it. It’s almost as if the ID isn’t immediately visible through the API. We’re using the Terraform provider version 1.1.4.

Here’s what I’ve tried so far:

• Increased time_to_wait: Added an explicit wait resource after creating the flow execution, waiting up to 60 seconds. Didn’t consistently fix it.
• Terraform refresh: Running terraform refresh before apply doesn’t change the outcome.
• Manual Association: Manually associating the flow execution in the Genesys Cloud interface works without any issues, so it’s not a fundamental problem with the flow execution itself.
• Provider Configuration: Double-checked the provider configuration for any incorrect settings.
• API calls: Verified the flow execution ID is returned via the /api/v2/flows/executions endpoint.
• Queue ID: Confirmed the queue ID is valid and resolvable.

We’re on Zoom Contact Center, US-East-1, and running this from a CI/CD pipeline in Azure DevOps. The pipeline uses a service account with full administrative access. I’m running this from US/Mountain time. It’s…odd. The same code runs fine in some environments but fails intermittently in others.

Fun one today. Is anyone else seeing this happen when the flowExecution.type is set to IVR? We ran into the same thing - it seems Terraform gets confused about the expected object schema, and just retrying the apply usually fixes it. Honestly, I wouldn’t dig too deep - it’s a Terraform quirk.

That the earlier post’s spot on - IVR flows are a mess with Terraform. The API itself doesn’t consistently return the expected schema for FLOW_EXECUTION when TYPE is IVR - it’s a race condition with the ASYNC_WORKER.

We’ve bypassed Terraform’s nonsense entirely and just query the flow execution details directly via the API - it’s quicker than debugging the Terraform vider. You’ll need to handle the IDEMPOTENCY yourself, obviously.

We’re on Zoom Contact Center, Genesys Cloud, and we’ve seen this before with the FLOW_EXECUTION object - it’s not consistent, you’re right. Terraform expects a very specific schema, and the API doesn’t always give it to you, especially with IVR flows.

It looks like the Terraform vider isn’t handling the optional parameters correctly. A workaround is to explicitly set the missing parameters to NULL in the Terraform configuration - the API seems to be more forgiving of NULLs than missing fields.

IF (flowExecution.type == IVR) THEN
SET (flowExecution.data = NULL)
ENDIF

Here’s an example of how to handle the configuration in Terraform:

resource "genesyscloud_flow_execution_association" "example" {
 flow_execution_id = "your_flow_execution_id"
 call_flow_id = "your_call_flow_id"
 data = null # Explicitly set data to null for IVR flows
}

This usually prevents the ‘Resource not found’ error. It’s a bit of a hack, but it works for us until they fix the vider. The WEM system needs a stable API, though.

u could try setting lifecycle { ignore_changes = [flow_execution.type] in your Terraform config - that’s kinda what we did when we ran into similar stuff with queues.

It’s because Terraform’s trying to manage the whole flow execution object, but the API isn’t giving it a consistent object to manage, especially with IVR, so Terraform just keeps trying to correct something that it thinks is wrong.

The ignore_changes block tells Terraform to basically leave that attribute alone after the initial apply, which prevents it from getting into a loop. It’s not ideal, I know, because you want Terraform to manage everything, but it’s a good workaround until the vider gets updated.

Thanks so much, for pointing out the schema inconsistencies - it makes a ton of sense why that’s happening. I also think the earlier post’s suggestion of explicitly setting nulls is a good idea, if you want more control over it. I didn’t test it myself, but it feels like it would definitely help. It’s kinda weird they’d handle missing params better than inconsistent schemas, but hey.