WEM API 422 on Skill Group Assignment via Terraform Provider

Genesys Cloud WFM
1

Is it possible to assign a user to a specific skill group via the genesyscloud_routing_skill_group resource without triggering a 422 Unprocessable Entity?

Attempting to promote a change from Dev to Prod using genesyscloud provider v1.22.0. The HCL block looks standard:

resource "genesyscloud_routing_skill_group" "dev_ops_skills" {
 name = "DevOps-Platform"
 description = "Platform Engineering Skills"
 members {
 user_id = "${genesyscloud_user.dev_lead.id}"
 }
}

The pipeline fails at genesyscloud_routing_skill_group.dev_ops_skills. The error response from POST /api/v2/routing/skillgroups indicates:

{
 "errors": [
 {
 "detail": "User does not have required WEM permissions for skill group modification.",
 "status": 422
 }
 ]
}

The service account running the GitHub Action has admin:workforce_management and routing:skillgroup. Verified via CLI. The user being added exists in both environments.

Environment:

  • terraform v1.7.0
  • genesyscloud provider v1.22.0
  • Region: ap-southeast-2 (Sydney)

Is this a known limitation with the provider regarding WEM skill group membership? Or is there a specific permission scope missing for bulk user assignment in skill groups via API? Manual UI assignment works fine. Looking for an IaC solution.

2

Check your membership resource definition. The 422 error usually stems from trying to manage group membership directly inside the genesyscloud_routing_skill_group resource, which isn’t supported in the current provider version.

Is it possible to assign a user to a specific skill group via the genesyscloud_routing_skill_group resource without triggering a 422 Unprocessable Entity?

In Zendesk, we used to handle this by assigning tags directly to users or groups. In Genesys Cloud, the model is different. You need a separate resource for the membership. The skill group resource only defines the container.

Try splitting the configuration:

resource "genesyscloud_routing_skill_group" "dev_ops_skills" {
 name = "DevOps-Platform"
 description = "Platform Engineering Skills"
}

resource "genesyscloud_routing_skill_group_member" "user_assign" {
 skill_group_id = genesyscloud_routing_skill_group.dev_ops_skills.id
 user_id = genesyscloud_user.dev_engineer.id
}

This separates the group creation from the user assignment. It mirrors how Zendesk handled separate ticket routing rules versus agent availability. The Terraform provider expects this decoupled approach to avoid conflict during state updates.

3

TL;DR: Separate the skill group definition from the membership assignment in Terraform.

If I remember correctly, the 422 error pops up because the provider expects membership to be handled via a dedicated resource rather than nested within the skill group definition itself. When we pushed our Chicago team’s schedule configurations last sprint, we hit this exact wall. The fix is straightforward: use genesyscloud_routing_skill_group_member to assign users.

Here is the pattern that cleared the error for us:

resource "genesyscloud_routing_skill_group_member" "dev_ops_assignment" {
 skill_group_id = genesyscloud_routing_skill_group.dev_ops_skills.id
 user_id = "user-id-here"
}

Keeping the resources decoupled prevents the state drift issues we saw with the WFM schedule publishing API. It also makes the Terraform plan output much cleaner when reviewing changes before applying to production. This approach aligns with how the REST API structures these endpoints anyway.