Does anyone know why 'Set Variable' fails with 400 Bad Request during Zendesk Trigger Migration?

  • What is the reason the Genesys Cloud Architect flow returns a 400 Bad Request error when attempting to map complex Zendesk trigger conditions to dynamic variables? We are migrating a high-volume support queue from Zendesk to Genesys Cloud, and the IVR logic is breaking at the very first decision node.
  • In Zendesk, we relied heavily on automation rules that checked ticket tags, priority, and custom fields in a single pass. The setup was remarkably simple. We just plugged in the conditions, and the system handled the logic. Here, the Architect interface feels incredibly rigid. We are trying to replicate a simple ‘If-Then’ block where the IVR checks the caller’s phone number against a CRM record and sets a ‘Priority’ variable based on the result.
  • The error occurs specifically in the ‘Set Variable’ block. The input is a string value derived from a previous ‘Lookup Record’ action. The variable name is ‘CustomerPriority’, and the value is ‘High’. However, the flow execution log shows: “Error: Invalid input format for Set Variable block. Expected string, got undefined.” This happens even though the preceding lookup returns a valid JSON object with the expected field.
  • We are using the standard Genesys Cloud Architect v2.0 interface. The environment is in the EU-West-1 region. The lookup action uses a Data Action that successfully retrieves data from our Salesforce instance. The issue seems to be how Genesys Cloud handles null values or empty strings from the CRM when the lookup fails to find a match. In Zendesk, the system would just skip the rule or default to a fallback. Here, the entire flow crashes.
  • We have tried wrapping the value in a ‘Format’ block to ensure it is a string, but the 400 error persists. The request ID in the logs is 8f3a-4b2c-9d1e. Is there a specific syntax or data type requirement for variables that we are missing? The documentation mentions ‘dynamic values’, but it does not explain how to handle missing data gracefully without breaking the IVR flow. Any practical migration advice on handling these null states would be appreciated.