Architect Expression Evaluator fails on DateTimeDiff with ISO 8601 offset from Data Action

Architect & Flows
1

Problem

The flow builder keeps rejecting a custom expression that calculates duration between a webhook payload timestamp and the current session time. Data Action v3.1 pulls the timestamp from an external CRM, strips the milliseconds, but leaves the +00:00 suffix. The Expression Evaluator in Architect throws a validation error before the flow even hits the runtime engine. Switching to a static string in the evaluator works fine, which points to a type coercion issue with dynamic inputs. The timezone handling isn’t the culprit here since the CRM outputs UTC, but the parser still chokes on the offset character. It’s weird how the compile step validates this so strictly. You can’t find a workaround in the current syntax docs. The runtime engine handles ISO 8601 just fine, but the design-time validator doesn’t. Console logs show the expression evaluator is doing jack all with the offset string, just passing it straight to the underlying parser which obviously fails on the plus sign. Trying to figure out if the design-time validator is just overly strict or if the underlying binding actually rejects dynamic offsets.

Code

Here is the expression setup inside the Set Variable block:

DateTimeDiff(
 ToString(DataAction_Output.crm_event_time), 
 DateTimeFormat("yyyy-MM-dd HH:mm:ss"), 
 "now", 
 DateTimeFormat("yyyy-MM-dd HH:mm:ss")
)

Error

The validation panel returns this right after saving the block:

{
 "type": "invalid_request",
 "message": "Expression evaluation failed: The input string was not in a correct format. Parameter name: s",
 "status": 400,
 "code": "EXPRESSION_PARSER_MISMATCH"
}

Question

Does the built-in DateTimeDiff function actually support the trailing Z or +HH:MM offset when the source is a dynamic variable? Tried wrapping it in Replace(DataAction_Output.crm_event_time, "+00:00", "") but the parser still flags it as a string type mismatch during the initial compile step. The documentation mentions ISO 8601 compatibility, yet the flow builder validation engine seems to expect a strict layout without any timezone markers. Running CXone platform version 2023.11.1 with the latest Architect UI update.

// Fallback attempt that also fails validation
DateTimeDiff(Replace(DataAction_Output.crm_event_time, "+00:00", ""), DateTimeFormat("yyyy-MM-dd HH:mm:ss"), "now", DateTimeFormat("yyyy-MM-dd HH:mm:ss"))

The compile error still points to line 2, character 14.

2

Architect chokes on that offset. The parser expects a clean string. Strip the timezone suffix in the Data Action response using regex. Don’t pass ISO strings with offsets directly to DateTimeDiff. It throws hard. Mapping config below shows the fix.

3
  • The docs state “Expressions accept ISO 8601 strings with timezone offsets for duration calculations.” The parser shouldn’t choke on +00:00.
  • Verify the Data Action response type isn’t coercing the string.
  • Check why this payload fails validation when the docs explicitly allow offsets.
response = {"timestamp": "2023-11-01T09:00:00+00:00"}
4

The regex strip in the DATA ACTION RESPONSE mapping worked perfectly for the PIPELINE DEPLOYMENT. The logic breaks down simply. First, you remove the offset using $TransferData.timestamp.replace('+00:00', '') so the EXPRESSION EVALUATOR doesn’t choke on the suffix.

$DateTimeDiff($TransferData.timestamp.replace('+00:00', ''), $CurrentDateTime)

You’ll see the validation pass straight through without any schema errors.

5

Traceroute shows clean hops, but you’ll hit clock drift on BYOC edges later when stripping offset. What region is your CRM hitting?

Try passing raw ISO to secondary data action first, because NTP sync fails and QoS drops under bandwidth stress.