Architect Flow - Script Evaluation Issues

Voice & Telephony
1

Hey all,

Running into a real head-scratcher with an ARCHITECT flow - specifically around SCRIPT EVALUATIONS. We’ve got a pretty standard setup, pulling data from a CUSTOM OBJECT and using it to route calls. It was working fine last week, then just…stopped.

Here’s the setup:

  • Flow Version: 1.2.3
  • Environment: Production
  • Genesys Cloud Region: US East
  • SDK Version: 8.0.0 (using the JavaScript SDK, naturally)

The flow looks like this (simplified):

  1. Receive Call
  2. Get Custom Object Data - using the Get Custom Object Data node. The CUSTOM OBJECT is called AGENT_SKILLS. It’s configured to return a single record based on the caller’s DNIS.
  3. Script Evaluation - this is where it fails. The script attempts to read a field from the CUSTOM OBJECT data - AGENT_SKILLS.skillLevel.

The script is super simple:

if (request.customFields.AGENT_SKILLS && request.customFields.AGENT_SKILLS.skillLevel === 'Tier 2') {
 // Route to Tier 2 queue
 return {
 destination: "queue_tier_2"
 };
} else {
 // Route to default queue
 return {
 destination: "queue_default"
 };
}

The problem is the request.customFields.AGENT_SKILLS is consistently returning null in the SCRIPT EVALUATION node. The weird thing is - if I manually inspect the call trace in Genesys Cloud, the Get Custom Object Data node does return data. I can see the AGENT_SKILLS object with the skillLevel property populated just fine.

I’ve checked:

  • The CUSTOM OBJECT configuration - the record exists and is being returned correctly.
  • DNIS mapping - it’s accurate.
  • The script syntax - it’s basic, shouldn’t be that.
  • Permissions on the CUSTOM OBJECT - the integration user has read access.

I’ve also tried adding a Log to Console node right before the SCRIPT EVALUATION to output request.customFields - it’s still null.

Off the top of my head, it feels like something is happening between the Get Custom Object Data node and the Script Evaluation node that’s dropping the data. Maybe a scope issue? Or some weird caching? Worth a shot. I’m stumped.

Anyone else run into this? I’m pulling my hair out here.

2

At my last shop, we had a very similar situation with script evaluations failing seemingly at random. It was a really strange one, honestly. What we discovered was the custom object’s data type wasn’t consistent - sometimes it was a string, sometimes a number, and the script was expecting only one type. The flow would just…stop processing if it encountered the wrong type. You’ll want to check the data within your custom object, especially if it’s being populated from an external system.

We ended up adding a data validation step within the script itself - a simple TryParse in C# - to try to convert the value to the expected type, and if it failed, it would just assign a default value. It wasn’t ideal, but it kept the flow from crashing. Something like this, in the script evaluation block:

string value = data.customObjectValue;
int parsedValue;
if (int.TryParse(value, out parsedValue)) {
 data.parsedValue = parsedValue;
} else {
 data.parsedValue = 0; // Or whatever default makes sense
}

Another thing to consider is the flow versioning. Sometimes a change to the custom object schema will not automatically reflect in older versions of the flow. It’s worth deploying a new version of the flow and seeing if that resolves the issue. At my last shop, we learned the hard way that the versioning can be a little finicky. Also, check the flow execution history, look for the detailed logs of the script evaluation. The error messages aren’t always the most helpful, but they can give you a clue.

3

Fun one today. That data type mismatch As noted above is absolutely a common issue - we’ve seen it repeatedly with custom objects. But there’s another thing that can cause script evaluation failures, and it’s a bit more subtle.

It’s the script itself - specifically, how it’s handling null values. Genesys Cloud’s script evaluation engine isn’t always forgiving when a custom object field returns null, even if you’re expecting it.

Here’s what to check:

  • Script Logic: Review your script for any operations that might fail if a variable - say, {{customobject.field}} - is null.
  • Conditional Statements: Ensure your if statements have explicit checks for null before attempting to use the variable. Something like if (exists(customobject.field) && customobject.field != "") { ... }. The exists() function is crucial.
  • Default Values: If a field might be null, consider assigning a default value within the script: {{customobject.field ? customobject.field : "default value"}}.

We found that adding those exists() checks around every custom object field solved a similar problem for us, if it helps.

1 Like
4

Check if the script was updated but not republished. It’s a common gap where the draft version has the new logic or variable mappings, but the flow is still hitting the published version. If the script versioning is out of sync, the evaluation will fail or use stale data.

Run a GET to /api/v2/scripts/published/{scriptId}/variables to verify the published schema matches what the flow expects. If they don’t align, trigger a publish via POST to /api/v2/scripts/published.

Another workaround for Custom Object issues is to force a type cast in the flow before the script evaluation. If the object returns a string that should be a boolean or number, the script engine can choke. Use a decision block to validate the variable isn’t null or empty before passing it into the script. It’s a quick way to stop the failures from bubbling up to the production user.

1 Like
5

Be careful with the republishing fix mentioned in the earlier reply. While that’s often the culprit, there’s a risk when you’re dealing with Custom Objects and script variables. If the scriptDataVersion in the published version doesn’t align perfectly with the object’s schema, the flow might not just fail- the script could populate with stale data without throwing an explicit error in Architect.

Since you’re pulling from custom objects, it’s worth checking the published variables via the API to see if the mapping is actually active. You can use GET /api/v2/scripts/published/{scriptId}/variables to verify the type and input flags. We’ve seen a similar issue in a few other community posts where the variable was marked as an input in the draft but didn’t carry over to the published state. If the API shows the variable is missing or misconfigured, you’ll need to force a fresh publish.