Looking for advice on why my DBConnector action in a CXone Studio script is consistently returning an empty result set, even though the same SQL query executes perfectly in the database client. I am building a legacy lookup flow where I need to fetch customer status based on a phone number passed from the IVR. The database is a standard PostgreSQL instance, and the connection profile in CXone is verified as active. I have configured the DBConnector action with the correct profile ID and set the query type to SELECT. The SQL statement is straightforward: SELECT status FROM customers WHERE phone = :phone. I am using a Data Action to map the inbound caller_id to the input parameter phone. The issue arises in the Assign action immediately following the lookup. I expect the output variable db_result.status to contain a value, but it remains null. I have enabled Debug Mode on the script execution. The debug log shows the SQL being sent is correct and the parameter substitution happens as expected. However, the ResultCount output variable from the DBConnector is always 0. I have checked the database permissions, and the service account has full read access. I have also tried wrapping the phone number in quotes within the SQL string, but that resulted in a syntax error from the database driver. The error message in the Studio debug log is generic: No rows returned. This is blocking my deployment because the subsequent Branch action relies on this value to route the call. I need to know if there is a specific configuration in the DBConnector action for handling text fields or if I am missing a required mapping for the output columns. Here is the JSON configuration of the DBConnector action:
{
"action": "DBConnector",
"profileId": "prof_12345",
"queryString": "SELECT status FROM customers WHERE phone = :phone",
"inputs": [
{
"name": "phone",
"value": "${caller_id}"
}
],
"outputs": [
{
"name": "status",
"columnIndex": 0
}
]
}
Is there a known issue with string parameter binding in the CXone Studio DBConnector, or should I be using a different approach for this lookup?