Running into a strange issue with our healthcare bot. The bot is configured for multi-language (English and Spanish). When a customer chooses Spanish, the bot correctly switches to the Spanish NLU and collects the data.
However, when it reaches the ‘Transfer to ACD’ block, it fails with ‘No agents available’ even though we have 5 Spanish-speaking agents On Queue.
I checked the Architect log and found that the bot is trying to transfer with the ‘Language’ attribute set to ‘Spanish’, but our agents are tagged with the ‘Spanish’ Skill, not the ‘Spanish’ Language (the built-in attribute). In CXone, these were the same thing, but in GC they seem to be distinct. How do I force the bot to ignore the built-in Language attribute and just use the Skill I’ve defined?
Welcome to the ‘inherited mess’ club. I’m currently debugging an implementation that does this exact thing. In Genesys Cloud, ‘Language’ is a first-class routing object separate from ‘Skills’.
If your Bot Flow has a language set, it will try to find an agent with that specific Language attribute assigned in their profile. If your agents only have the ‘Spanish’ skill, the match fails. You either need to assign the ‘Spanish’ Language to your agents (under their User profile > Languages) or modify the ‘Transfer to ACD’ action in Architect to clear the language requirement and explicitly add the ‘Spanish’ Skill instead.
2 Likes
Coming from CXone, this is a common ‘Gotcha’. In CXone, everything is a skill. In GC, the ‘Language’ attribute is powerful because it allows for specific routing logic without cluttering your skill list.
My advice: don’t fight the system. Assign the actual ‘Language’ attribute to your agents. It’s better for reporting too, as you can see ‘Spanish’ as a dimension in the Performance dashboards without having to filter by skill IDs.
If you want to keep using the Skill for now, in the ‘Transfer to ACD’ block, look at the ‘Language’ input. You can set it to ‘None’ or use an expression to clear it. Then, in the ‘Skills’ input, add your Language.Spanish skill. Just remember that if the bot is in Spanish mode, GetCurrentLanguage() will return the Spanish object, which you can use to dynamically set the skill.
2 Likes
are you sure the agents have the specific ‘Spanish’ Language attribute assigned in their user profiles? is spot on about the distinction between Language objects and Skills, but there’s a hidden trap here that bites people who manage queues via the API.
If you’re using the Admin UI to assign languages, it usually works. But if you’re managing agent profiles via the PureCloudPlatformClientV2 SDK or direct REST calls, the PUT /api/v2/users/{userId} endpoint is notoriously tricky. It doesn’t just add the language; it replaces the entire languages array if you don’t send the full list of existing assignments. I’ve seen this wipe out ‘English’ assignments when trying to patch ‘Spanish’, causing agents to drop out of the pool entirely for half the calls.
Here’s how to safely patch it without breaking their current setup:
# Python SDK Example
user_api = platform_client.users_api
user = user_api.get_user(user_id)
# Ensure you preserve existing languages
if 'Spanish' not in [lang.language.name for lang in user.languages]:
lang_obj = models.Language(
id="spanish-lang-id-from-admin",
name="Spanish"
)
user.languages.append(lang_obj)
# Update the user, sending the FULL language array
user_api.update_user(user_id, user)
Also, check your Queue’s ‘Routing Rules’. Even if the Language matches, if the Queue has a strict Skill requirement that doesn’t align with the Language-to-Skill mapping in the Routing Profile, it’ll still fail. The UI layout for this is confusing because the Language assignment is in User Admin, but the validation happens in Queue/Workflow settings. It’s easy to miss the disconnect.
don’t forget to verify the routingProfile on those agents too. if the profile doesn’t have the Spanish language capability enabled for the specific skill group, the match fails silently.