Trying to automate role assignments for new hires using genesyscloud_iam_user resource. The user creation succeeds, but the roles block fails consistently during terraform apply.
Error log:
Error: error creating IAM user roles: 400 Bad Request
Details: Invalid role ID format or role does not exist in this environment.
The role IDs are pulled from a remote data source data.genesyscloud_role.search which queries by name. The search returns correct IDs. Verified via Postman that these role IDs are valid in the target apac-1 environment. The same HCL applies cleanly in us-east-1 without errors.
Suspect this might be related to how the provider handles role scope in specific regions or a race condition if the user isn’t fully provisioned before role assignment. However, the error is immediate 400, not 409 or timeout.
Also noticed that if I remove the roles block and apply, then add it back in a second apply, it works. This suggests the API endpoint for bulk role assignment on creation is behaving differently than the update endpoint.
Is there a known workaround for apac-1? Or is this a provider bug? We need a single-apply deployment for our CI/CD pipeline. Manual post-apply scripts are not an option due to audit requirements.
Please advise if there’s a specific attribute needed for apac-1 role assignments or if I should open a GitHub issue against the provider.
If I remember right, the provider often fails to handle the async nature of IAM propagation in apac-1.
Trying to automate role assignments for new hires using genesyscloud_iam_user resource.
Use a depends_on or a null_resource with a sleep to ensure the user is fully indexed before the role assignment hits the API.
You should probably look at at the specific error payload returned by the API during the 400 response. While the replication lag mentioned in the previous comments is a valid concern for apac-1, a 400 Bad Request usually indicates a schema validation failure rather than a timing issue. If the user object exists but the role assignment fails, it is often because the role_id being passed is not visible in the specific org context or lacks the necessary permissions for the assigned user type.
In my experience managing trunks and user provisioning across regions, the Genesys Cloud provider sometimes struggles with the asynchronous creation of users. The genesyscloud_iam_user resource creates the user, but the roles block attempts to attach permissions immediately. If the user’s internal ID has not fully propagated to the IAM service, the API rejects the role assignment with a 400 error.
To mitigate this, instead of a generic sleep, use a depends_on clause explicitly linking the role assignment to the user creation resource. Additionally, ensure you are using the local_user_id or the correct role_id from the genesyscloud_iam_role data source. Hardcoding role IDs can cause issues if they differ between regions.
Here is a more robust pattern:
data "genesyscloud_iam_role" "agent_role" {
name = "Agent"
}
resource "genesyscloud_iam_user" "new_hire" {
name = "Test User"
email = "[email protected]"
roles = [data.genesyscloud_iam_role.agent_role.id]
}
If you separate the user creation and role assignment into distinct resources, you can add a time_sleep resource with a depends_on to the user creation, ensuring the IAM index is updated before the role assignment is attempted. This approach provides more predictable behavior than relying on implicit provider dependencies. Check the error_message field in the Terraform debug logs to confirm if it is a validation error or a propagation delay.
You need to verify that the role_id values in your Terraform configuration are not only valid globally but are specifically visible and assignable within the apac-1 organizational context. The 400 Bad Request error typically stems from a schema validation failure where the API rejects a role ID that exists in the system but is not scoped to the user’s organization or lacks the necessary permissions for the assigned user profile.
While the replication lag mentioned earlier is a valid concern for apac-1, it usually results in a 404 Not Found or a 500 Internal Server Error, not a 400. A 400 indicates the request payload itself is malformed or invalid against the current API schema. Check your genesyscloud_iam_user resource block to ensure the roles list contains only role_id strings that are explicitly enabled for your organization’s user management policies.
Here is a corrected configuration snippet that includes explicit dependency handling and role validation:
resource "genesyscloud_iam_user" "new_hire" {
name = "New Hire Name"
email = "[email protected]"
username = "[email protected]"
enabled = true
# Ensure the user resource is fully created before role assignment
depends_on = [genesyscloud_iam_user.new_hire]
roles = [
"valid_role_id_visible_in_apac1", # Replace with actual visible role ID
"another_valid_role_id"
]
}
Additionally, consider using a null_resource with a local-exec provider to introduce a short delay if the IAM propagation delay persists, though this should be a secondary fix after confirming role visibility. Refer to the official documentation for IAM role scoping in multi-region deployments: https://developer.genesys.cloud/apidocs/iam#role-scoping