We have a Data Action in an Architect flow - it’s after the collect digits block, supposed to send call data to our backend. The connector is a POST to a Workato recipe, pretty standard setup. The problem is, a custom variable we’re setting in the flow - cust_var_orderid - isn’t making its way through to Workato. It’s like the variable isn’t… exposed?
I’ve checked the event mapping in the Data Action connector config a dozen times. It’s mapped to $.variables.cust_var_orderid. Workato side, the recipe is listening for that field. Sometimes it shows up as blank, other times it doesn’t show up at all. It’s not a Workato issue - the test calls directly from Architect show the variable is gone before it hits the connector.
It’s a Zoom Contact Center flow. We are trying to pass this order ID to trigger a process in the backend, but the value is missing. The data action is configured to use the ‘Call’ context. The collector is set to ‘Store in variable’ with the variable name being cust_var_orderid.
Here are some things we’ve tried:
Flow version is current. We’ve re-published several times.
Data Action connector OAuth is valid and active.
Double checked the variable name for typos (it’s easy to make a mistake).
Tried different data types for the variable (text, numeric) - no change.
The collector is set to ‘Store in variable’ as it should be.
The connector log from Workato is… partial. It just shows “Request received” and then… nothing. I think it’s timing out or the payload is incomplete. I’m not sure what to check next. The Workato connector is the standard Genesys Cloud connector. It’s version 2.1.3.
platformClient.api.architect.flow.get will show you the variable scope - make sure cust_var_orderid isn’t set as ‘flow’ level, it needs to be ‘session’ or ‘global’. We’ve had this happen where the collect digits block sets it locally, but the Data Action can’t see it. One gotcha - if you’re using a sub-flow, variable propagation isn’t automatic.
Also check the Data Action’s request body in the Workato logs. It’s probably not a mapping issue, it’s the variable isn’t even in the payload. We ran into something similar last quarter when a connector update silently changed how it handles variable names - the Workato recipe expected orderId, but the Data Action was sending cust_var_orderid. Try setting a simple test variable - $.test_var - in the flow and mapping that to Workato. If that works, you know the Data Action itself is functioning and it’s a naming thing.
I checked the scope - it is session level, so that isn’t the problem. Now the Workato recipe is getting something under $.var, but it’s just the collect digits result - not my custom variable at all. It looks like it’s overwriting it.
Right, so this is a classic one - the Data Action connector in Architect is… particular about how it handles variables. is spot-on about scope, but that isn’t the whole story.
The issue, as you’ve described, is almost certainly that the Data Action is getting the result of the collect digits block instead of your custom variable. That’s because the connector’s default behavior is to pass the entire $.variables object, and the last variable set wins. It’s not overwriting in the way you think - it’s just grabbing whatever’s currently in that slot.
To fix this, you need to explicitly tell the Data Action which variables to send. Don’t rely on it grabbing everything. You do this in the event mapping configuration - you’re already looking at that, but you need to be precise. Instead of just mapping $.var, map $.variables.cust_var_orderid. You’ll need to create a separate mapping for each variable you want to send, listing them individually.
It’s a bit fiddly, honestly. I spent ages on this when we first built out the integrations with Workato. We’ve since moved to sending everything as JSON directly, which is… cleaner.
edit: Just remembered another wrinkle - if you’re doing any string manipulation on cust_var_orderidafter setting it, make sure the final result is actually stored back into the variable. We had one where it was doing a concatenation but wasn’t re-assigning, so Workato was getting the original, empty value.
i think is spot on about the collect digits block. we ran into something similar last month - the collect digits was setting $.var.digits_pressed and totally overwriting anything else we were trying to send through to Workato. i think it’s kinda dumb, honestly.
it’s probably not the mapping itself, like the earlier reply said. can you check if there’s a $.var.digits_pressed showing up in Workato alongside whatever else is getting through?
and this is a weird one - are you using conditional branching after the collect digits? sometimes the data action connector doesn’t pick up variables if the flow isn’t taking the “happy path” immediately after. i think it’s a caching thing? we had to add a short delay action before the data action to fix that. just a thought. are you mapping all the variables to Workato or just the custom one?