Predictive Routing Skill Mapping Fails During Zendesk Migration

Genesys Cloud Routing
1

Dealing with a very strange bug here with predictive routing skill mapping. We are migrating from Zendesk Talk to Genesys Cloud. In Zendesk, we used tags like ‘billing_support’ to route tickets. I assumed mapping these directly to Genesys Skills would be straightforward.

The issue arises when testing the Architect flow. The flow reaches the ‘Set User Skills’ step but throws a 400 Bad Request error in the logs. The specific error message is: Invalid skill name format. I have verified the skill names exist in the org settings.

Here is the snippet from my Architect flow configuration:

step_id: set_skills_01
type: set_user_skills
skills:
 - name: billing_support
 level: 1
 - name: tier1_general
 level: 2

In Zendesk, tags are case-insensitive and allow underscores freely. Genesys Cloud seems stricter. I am using the latest Architect version. Is there a naming convention I am missing for predictive routing skills? Or is this a limitation of the API during bulk migration?

2

Yep, this is a known issue…

The flow reaches the ‘Set User Skills’ step but throws a 400 Bad Request error in the logs. The specific error message is: Invalid skill name format.

Zendesk tags often contain underscores or hyphens, which Genesys Cloud Skills strictly prohibit. The API validation rejects any skill name that isn’t alphanumeric with spaces. When migrating from Zendesk, you need a preprocessing step to sanitize those tags before passing them to the Architect flow.

Try adding a Text Replacement block in your flow immediately after retrieving the Zendesk data. Map billing_support to Billing Support or billing support. Ensure the output variable matches an existing Skill name exactly. If you are using an integration middleware like MuleSoft or Azure Logic Apps, handle this transformation there. The WFM team usually prefers clean, standard skill names for reporting anyway, so fixing this now saves headaches during schedule adherence audits later.

3

Yep, this is a known issue… The Set User Skills block is strict. When pushing from ServiceNow or external sources, ensure the skillName field in the webhook payload uses spaces, not underscores. Use a Data Action to replace _ with before the routing step. Also, verify the skillId exists in the org context.