We’re running into a weird one with web messaging bot flows and data actions. It’s similar to a post from a few months back about data types - the Data Action is sending the email address as a string, even though it’s mapped as ‘Email Address’ type in the action. It’s happening intermittently, but it’s enough to break the flow.
The flow collects the email using a ‘Collect Input’ node, then passes it to a Data Action to pull some customer info from an external system. The Data Action returns a JSON with the customer details. The problem is, when we try to use the email address returned from the Data Action in a subsequent ‘Transfer to Agent’ node, it’s failing validation because it’s a string. It’s a string with quotes around it.
I’ve checked the Data Action mapping several times. The output mapping is set to ‘Email Address’ type. In my experience, if the input type doesn’t match the mapping, the Data Action often just throws an error, but this is just… passing through a string. It’s really frustrating.
We’ve seen some success with adding a “String to Number” transformation to the data action output in similar cases - a workaround someone posted about a year ago - but that doesn’t seem right for an email. It works, though. It’s just not clean.
The bot flow version is 2.1. The SDK version isn’t something we directly control, it’s the standard Genesys Cloud one. We’re on the latest release of the Genesys Cloud platform. Does anyone know if there’s a known issue with email data types in Data Actions? It feels like there’s something off with how the Data Action handles the email format.
ran into this a while back, kinda similar to that post about the API state from a few months ago. it’s almost always a data type mismatch - the Genesys Cloud API is pretty picky.
From what I’ve seen, the ‘Collect Input’ node sometimes defaults to string even if you’ve set the type to ‘Email Address’. Try explicitly setting the variable type in the Collect Input node’s advanced settings - there’s a little dropdown you can miss.
If that doesn’t stick, double-check the Data Action config. You’ll want to make sure the request payload is actually sending the email as a string and that your external system is expecting a string. It’s weird, but sometimes you have to match the wrong type to get it right.
Here’s an example of a Data Action payload that worked for us - it forces the email to a string:
One gotcha - if you’ve got multiple Data Actions chained together, the type can flip between them. Keep an eye on that. Also, if you’re doing any data transformation in the flow, that could be the source of the issue.
That’s right, the data type mismatch is the likely culprit - we flagged that same pattern during a calibration last quarter. Agents enter free-form text, and the system’s expecting a validated email format.
But it’s not always the ‘Collect Input’ node. The data action’s schema validation can also be the choke point. Double-check the request mapping - is the email attribute explicitly typed as ‘Email Address’ in the action’s configuration? It’s easy to overlook, especially if you’ve copied mappings from elsewhere.
Fwiw, we’ve seen cases where the API rejects valid emails due to length restrictions. The API expects a maximum email length of 254 characters, and we had a client passing longer values. Heads up - that’ll silently fail, and the data action won’t return an error, making it difficult to pinpoint. Review the failed interactions and check the email length.
It’s also worth reviewing that earlier post about API state - sometimes a transient issue on the integration side can cause type coercion. A quick redeploy can resolve it.