The API returns 400 Bad Request with message ‘Invalid queue configuration’ when linking to a queue migrated from Zendesk.
We are in the final stages of migrating our outbound dialing operations from Zendesk Talk to Genesys Cloud, and I have hit a wall with the predictive outbound campaign activation in the EU-West region. The setup involved mapping our Zendesk agent groups to Genesys Cloud business units and creating corresponding queues using the Terraform Provider v1.12.0. The initial resource creation was successful, and the queues appear correctly in the Admin console with the expected skills and agent assignments. However, when attempting to activate a new predictive outbound campaign via the API, the response consistently fails with the 400 error mentioned above.
The specific endpoint being called is POST /api/v2/outbound/campaigns, and the payload includes the campaignId, campaignType set to ‘PREDICTIVE’, and the queueId that was migrated. The error details in the response body point to a validation failure on the queue configuration, specifically mentioning that the queue does not support the required dialing strategy. In Zendesk, we handled outbound calls through a simple tag-based assignment, but in Genesys, I understand that predictive dialing requires specific queue settings, such as a non-zero max concurrent calls value and proper agent availability rules. I have verified that the queue settings in Genesys match the recommended configuration for predictive dialing, including setting the wrap-up time and ensuring agents are properly provisioned with the necessary skills.
The SDK version in use is v3.2.0, and the environment is eu-west-1. I have also checked the Architect flow associated with the campaign, and it seems to be correctly linked to the queue. The issue persists even after deleting and recreating the queue manually through the UI, which suggests that the problem might be related to how the queue metadata is being interpreted during the migration process. Has anyone encountered similar issues when migrating outbound campaigns from Zendesk to Genesys Cloud? Any insights into what specific queue configuration attributes might be missing or incorrectly set would be greatly appreciated. We are under pressure to complete this migration, and this error is blocking our final testing phase.
You might want to look at the queue skill mappings. this is a super common trip-up when moving from Zendesk to Genesys, especially if you’re using Terraform to spin things up. the 400 error usually means the campaign expects a specific skill on the queue that isn’t there, or the skill name has a subtle casing difference.
i’ve seen this happen when the old Zendesk groups didn’t map 1:1 to Genesys skills. the predictive campaign engine is strict about this. it needs to know exactly which agents can take which calls. here’s what usually fixes it:
- check the skill names. go to Admin > Routing > Skills. make sure the skill assigned to the campaign matches the skill on the queue exactly. Genesys is case-sensitive. “Outbound_Sales” is not the same as “outbound_sales”.
- verify agent enrollment. even if the queue has the skill, the agents need to be enrolled in that skill. if you used Terraform, check your
genesys_cloud_routing_skill_group resources. did you map the Zendesk agent IDs correctly?
- review the campaign config. in the campaign settings, under “Routing”, ensure the “Queue” dropdown actually shows the skills you think it does. sometimes the API cache lags. try toggling the campaign off and on again.
- check for hidden skills. Zendesk uses tags, Genesys uses skills. if you migrated tags to skills, make sure no extra skills were created that are conflicting.
it’s easy to overlook because the UI looks fine, but the API is rigid. also, since you’re in EU-West, double-check that the queue’s business unit matches the campaign’s BU. mismatched BUs can also throw weird 400s that look like config errors.
try clearing your browser cache too. sometimes the Genesys Cloud desktop app holds onto old queue configs. if that doesn’t work, check the logs for the specific skill ID mismatch. it’s usually right there in the trace.
The API returns 400 Bad Request with message ‘Invalid queue configuration’ when linking to a queue migrated from Zendesk.
Have you tried forcing a refresh on the queue definition in terraform state? sometimes the provider caches the old zendesk structure. run terraform refresh then apply again.
2 Likes
that 400 is almost certainly a metadata mismatch in the queue definition itself, not just skills. when migrating from zendesk, the queue often inherits routingType: LONGEST_AVAILABLE_AGENT or similar defaults that predictive outbound rejects. predictive campaigns require routingType: SKILL and utilization set to PERCENT or NONE.
check the queue config via api. if you’re using terraform, the block should look like this:
resource "genesyscloud_routing_queue" "outbound_campaign_queue" {
name = "Migrated Outbound Queue"
description = "Queue for predictive dialer"
routing_type = "SKILL" # critical for predictive
utilization = "PERCENT"
# ensure skills are actually attached
skills = ["outbound_sales"]
# warning: don't enable 'talk_time' or 'hold_time' limits here if you want pure predictive behavior
# they can cause the campaign engine to drop calls unexpectedly
}
also verify the enabled flag is true. sometimes the terraform state applies the config but leaves the queue disabled during migration. if the queue is disabled, the campaign api throws that exact 400.
another gotcha i’ve seen in eu-west specifically: check the timeout settings. if the queue has a very short wrapup_time or talk_time limit, the campaign engine might flag it as invalid for predictive use. set them to high values or remove the limits temporarily to test.
1 Like
hold up. terraform might say it’s applied, but if the queue still has wrapUpTimeout set to something high, predictive outbound will reject it. check the raw json via /api/v2/queues/{queueId}. it needs to be 0 or null.
1 Like