What is the reason this setting causes a deployment failure when the flow ID is already referenced in the campaign resource block?
Attempting to automate the provisioning of an outbound campaign using Terraform provider version 1.65.0. The environment is Genesys Cloud US-East. The goal is to link a specific Architect flow to the campaign via the flow_id attribute within the genesyscloud_outbound_campaign resource. However, the apply step fails consistently with a 409 Conflict error. The API response indicates that the flow is already in use or locked, despite the flow being newly created in the same state file and not yet deployed to production. The flow ID f-abc-123 is valid and exists in the organization. The error message from the provider is: “Error updating Outbound Campaign: 409 Conflict: Flow with ID f-abc-123 is currently referenced by another campaign or is locked for editing.”
The Terraform configuration snippet is as follows:
resource "genesyscloud_outbound_campaign" "test_campaign" {
name = "Test Auto Campaign"
description = "Automated via Terraform"
status = "PENDING"
rules {
campaign_id = genesyscloud_outbound_campaign.test_campaign.id
# other rules omitted
}
flow {
id = genesyscloud_architect_flow.test_flow.id
}
}
resource "genesyscloud_architect_flow" "test_flow" {
name = "Test Flow"
description = "Associated flow"
# flow definition omitted
}
The issue seems to be related to the order of operations or a race condition in the provider’s handling of dependencies. The flow is created first, but when the campaign tries to bind to it, the API rejects the link. This happens even when adding depends_on explicitly. Is there a specific attribute or workaround to force the provider to wait for the flow to fully initialize before attempting the campaign association? Also, does the status of the flow need to be PUBLISHED before the campaign can reference it in the HCL code, or should the provider handle the draft state automatically? Current behavior suggests the latter is failing. Any insights on stabilizing this dependency chain in the state management would be appreciated. Timezone context is Sydney, but the API region is US-East, so latency is not the primary suspect here.