What is the standard approach to structure the campaign start payload via genesyscloud_outbound_campaign? The CLI returns a 400 error stating invalid campaign state transition when attempting to move from paused to active.
{
"name": "Sydney_Test_Campaign",
"state": "active",
"dialingMode": "progressive"
}
The flow is valid. Is there a specific sequence required in the HCL definition before triggering the start action?
This happens because the strict state machine enforcement within the Outbound Campaign API. The Genesys Cloud platform does not allow a direct transition from paused to active without explicitly acknowledging the previous state in the request payload or ensuring the resource identifier is correctly targeted in the PUT operation.
When using the genesyscloud_outbound_campaign resource in Terraform, the state argument alone is often insufficient for resuming a campaign that has been explicitly paused. The API expects a specific set of attributes to remain consistent with the existing campaign definition to prevent data corruption during the transition. If the dialingMode or other critical configuration fields are omitted or mismatched in the update payload, the system interprets this as an invalid mutation rather than a simple state change, resulting in the 400 error.
Ensure that the id of the campaign is explicitly referenced in the update call. For a REST API approach, the payload should mirror the full current configuration while only changing the state field. In Terraform, you might need to refresh the state file or ensure no other concurrent updates are locking the resource.
A common workaround in scripting environments is to first perform a GET request to retrieve the full campaign object, modify only the state field to active, and then submit that complete object via PUT. This ensures all required fields like name, dialingMode, and wrapUpCode are present and valid.
{
"id": "campaign-uuid-here",
"name": "Sydney_Test_Campaign",
"state": "active",
"dialingMode": "progressive",
"wrapUpCode": "default"
}
Additionally, verify that the user or service account making the API call has the outbound:campaign:edit permission. Without this, the system may return ambiguous errors that look like state transition failures. Check the audit logs for the specific campaign to see if a lock is currently held by another process.
Yep, this is a known issue. From a WFM perspective, ensure the agent pool isn’t locked during schedule publishing. If the outbound campaign targets agents currently in a shift swap window, the API might reject the state change due to availability conflicts. Check the genesyscloud_wfm:schedule status before triggering the campaign activation.
Have you tried verifying the campaign ID in the PUT request?
version tag for optimistic locking.