Terraform Drift on WFM Schedule Group Capacity Constraints

Genesys Cloud WFM
1

How should I properly to handle capacity constraint definitions within genesyscloud_wfm_schedule_group resources without triggering perpetual plan drift?

Deploying via Terraform provider v1.9.4 in the au-1 environment. The state file records the capacity_constraints block. However, subsequent plans show a modification where Genesys Cloud API returns the constraints with slightly different internal IDs or normalized values compared to the HCL definition.

Error: Plan shows changes to genesyscloud_wfm_schedule_group.test_group.capacity_constraints[0].id

The HCL is static. The API response varies. This breaks our CI/CD pipeline for automated WFM deployments. The standard ignore_changes meta-argument feels like a band-aid that risks out-of-sync state if the backend logic changes.

Is there a recommended pattern for referencing these constraints? Should we be using a genesyscloud_wfm_capacity_constraint resource and referencing it by ID, rather than defining the constraint inline within the schedule group? Current documentation is sparse on the relationship between these two resource types.

2

If you check the docs, they mention that capacity constraints are often normalized by the backend before storage, which causes Terraform to see a difference even if the logical configuration is identical. This is a common pain point when publishing schedules across different timezones like America/Chicago.

Error: Plan applies would modify resource

  • capacity_constraints {
  • id = “gen-internal-normalized-id”
  • id = “user-defined-id”
    }

To stop the drift, use lifecycle { ignore_changes = [capacity_constraints] } in your genesyscloud_wfm_schedule_group resource. This tells Terraform to accept the server’s normalized values without trying to rewrite them.

When managing shift swaps and agent preferences, it is better to let the WFM engine handle the internal ID generation. Just ensure the constraint logic matches your adherence goals. If you need to verify the constraints, check the published schedule in the UI rather than relying on the raw API response for exact string matches. This approach keeps your CI/CD pipeline clean and avoids constant manual state fixes.