Quick question about a persistent deployment failure with the genesyscloud_predictive_outbound_campaign resource.
Context:
Running automated deployments via GitHub Actions to an AU-1 BYOC environment. The Terraform plan succeeds without errors. However, the apply step fails consistently when creating the predictive outbound campaign.
Environment details:
- Provider Version: 1.68.0
- Terraform Version: 1.7.4
- Environment: AU-1 BYOC (Genesys Cloud)
- Resource:
genesyscloud_predictive_outbound_campaign
The error returned is a 422 Unprocessable Entity. The API response body indicates:
{
"message": "The segment id 'seg-12345-abcde' is not valid or does not belong to this organization."
}
The segment ID exists and is active in the target environment. It is created in a previous step of the same Terraform configuration using genesyscloud_segment. The dependency is handled via the standard depends_on attribute in the campaign resource.
HCL Snippet:
resource "genesyscloud_segment" "outbound_target" {
name = "Outbound Target Group"
description = "Test segment for predictive routing"
type = "CONTACT"
query {
type = "OR"
clauses = [
{
field = "phone_number"
operator = "exists"
}
]
}
}
resource "genesyscloud_predictive_outbound_campaign" "test_campaign" {
depends_on = [genesyscloud_segment.outbound_target]
name = "Test Predictive Campaign"
description = "Automated test campaign"
enabled = true
campaign_type = "PREDICTIVE"
dialing_config {
type = "PREDICTIVE"
predictiveness = 0.5
}
contact_list {
id = genesyscloud_segment.outbound_target.id
}
}
The segment is confirmed to be in the same organization as the campaign. No cross-org issues. The error suggests the API does not recognize the segment ID at the time of campaign creation, despite the dependency.
Question:
Is there a known delay or propagation issue with segment availability in AU-1 BYOC environments? Or is there a specific attribute required in the genesyscloud_predictive_outbound_campaign resource to ensure the segment is fully indexed before the campaign creation request is sent? The depends_on should handle this, but the 422 error persists across multiple runs.