Architect Flow Evaluate Action Silently Failing on Complex Boolean Expression

Architect & Flows
1

I am building a routing flow that evaluates multiple conditions to determine which skill group to route to. I have an Evaluate action with the following expression:

If(
  AND(
    Flow.customerTier == "platinum",
    Flow.languagePreference == "ja",
    Flow.queueWaitEstimate < 120,
    NOT(IsSet(Flow.previousAgentId))
  ),
  "preferred_team",
  If(
    AND(
      Flow.customerTier == "platinum",
      Flow.languagePreference == "ja"
    ),
    "platinum_overflow",
    "general_queue"
  )
)

The problem is that when Flow.queueWaitEstimate is null (because the Data Action that populates it timed out), the entire AND expression does not evaluate to false like I would expect. Instead, the Evaluate action throws a runtime error and the flow jumps to the error handling path.

I expected that comparing null to an integer with < would just evaluate to false, like it does in most programming languages. But apparently Architect treats null comparisons as errors rather than false.

I have tried wrapping it in If(IsSet(Flow.queueWaitEstimate), Flow.queueWaitEstimate < 120, false) but the nested If inside the AND is making the expression exceed the maximum expression length limit and Architect refuses to save it.

Is there a cleaner way to handle nullable variables in complex Architect boolean expressions?

2

This is a fundamental architectural constraint in the Genesys Cloud Architect expression engine. Unlike JavaScript or Python where null comparisons degrade gracefully, Architect uses strict type evaluation. Any arithmetic or comparison operator applied to a NOT_SET variable throws a runtime exception rather than returning false.

The recommended pattern is to use separate Decision blocks instead of a single monolithic Evaluate expression. Break your logic into sequential Decision nodes:

  1. Decision: IsSet(Flow.queueWaitEstimate) - Yes/No branches
  2. On the Yes branch, Decision: Flow.queueWaitEstimate < 120 - Yes/No branches
  3. Continue building the routing logic from there

This is more verbose in the flow canvas, but each Decision node handles exactly one condition and you never hit the expression length limit. It also makes the flow much easier to debug in the execution log because each Decision shows its individual evaluation result.

The expression length limit you are hitting is 4,096 characters. There is no way to increase it. Genesys has stated this is a fixed platform constraint that will not change because the expression evaluator compiles expressions into a fixed-size bytecode representation.

3

The sequential Decision blocks approach works but honestly it turns your flow into spaghetti when you have 5+ conditions. What I do instead is use a Set action before the evaluation to normalize all the nullable variables:

Set Flow.safeWaitEstimate = If(IsSet(Flow.queueWaitEstimate), Flow.queueWaitEstimate, 999)
Set Flow.safePreviousAgent = If(IsSet(Flow.previousAgentId), Flow.previousAgentId, "")

Then your Evaluate expression only references the safe* variables, which are guaranteed to be non-null. The 999 value acts as a sentinel that effectively means “Data Action failed, skip this condition” since no real wait estimate would be 999 seconds.

This keeps your actual routing logic clean and readable in a single Evaluate block without hitting the expression length limit. The normalization step takes 2-3 Set actions at the top of the flow and you never think about nulls again downstream.