Terraform data source lookup by name failing with 404 on existing Genesys Cloud users

Just noticed that my Pulumi stack is failing during the refresh phase when trying to reference an existing Genesys Cloud user via a Terraform data source. I am using the genesyscloud_user data source to look up a user by name to get their ID for a subsequent role assignment. The user definitely exists in the org, and I can see them in the UI.

Here is the snippet causing the issue:

data "genesyscloud_user" "existing_admin" {
 name = "John Doe"
}

resource "genesyscloud_user_role" "assign_role" {
 user_id = data.genesyscloud_user.existing_admin.id
 role_id = "some-role-id"
}

The error I am getting is Error: 404 Not Found. I tried adding a filter block with email as well, but it still fails. Is the data source lookup strictly case-sensitive, or is there a delay in the API indexing that causes this? I expected it to just return the ID if the name matches exactly. Running on Pulumi 3.100 with the latest Genesys Cloud provider.

This happens because the data source requiring an exact match on the name attribute, which often fails due to case sensitivity or hidden whitespace in the UI display name.

Switch to the REST API directly to resolve the ID before passing it to Terraform. This bypasses the strict HCL lookup logic.

curl -H "Authorization: Bearer $TOKEN" "https://api.mypurecloud.com/api/v2/users?name=Admin+User" | jq '.entities[0].id'

This is a classic case of the Genesys Cloud provider’s strict matching logic clashing with the dynamic nature of user display names in the UI. The suggestion above to use curl is a valid workaround for quick debugging, but it is not sustainable for an IaC pipeline. You need a deterministic lookup method that handles case-insensitivity and potential whitespace variations without breaking the Terraform state.

The genesyscloud_user data source is indeed fragile when relying solely on name. The more robust approach is to query by email if it is unique in your org, or use the genesyscloud_routing_queue data source to fetch members if the user is tied to a specific queue. However, if you must search by name, you can leverage the Genesys Cloud API directly within a local-exec provisioner or a pre-build script to fetch the ID, then inject it as a variable.

Here is a Node.js snippet using the PureCloudPlatformClientV2 SDK that mirrors the curl logic but handles pagination and error states more gracefully. You can run this before terraform plan to populate a user_id.tfvars file.

const platformClient = require('genesyscloud');
const fs = require('fs');

platformClient.AuthClient.createOAuthClient().loginClientCredentials({
 clientId: process.env.GC_CLIENT_ID,
 clientSecret: process.env.GC_CLIENT_SECRET
}).then(() => {
 const UsersApi = new platformClient.UsersApi();
 // Use the API to search users. Note: the API supports 'name' filtering but is case-insensitive.
 UsersApi.postUsersSearch({
 body: {
 name: "Admin User" // Ensure this matches exactly what you expect, or use email
 }
 }).then((response) => {
 if (response.entities && response.entities.length > 0) {
 const userId = response.entities[0].id;
 // Write to a tfvars file for Terraform to consume
 fs.writeFileSync('user_vars.tfvars', `admin_user_id = "${userId}"`);
 console.log(`Found User ID: ${userId}`);
 } else {
 console.error("User not found");
 }
 });
});

Ensure your Terraform configuration references this variable instead of the data source lookup.

This approach decouples the fragile lookup from the state management, which is critical for PagerDuty integration flows where user roles change frequently.