Architect Set Variable node dropping nested JSON for ServiceNow REST API

Architect & Flows
1

Why does this setting in the Set Variable node strip nested objects before the Data Action executes? The flow is designed to trigger a ServiceNow incident ticket via a webhook payload when a specific IVR path is taken. The payload structure requires a deeply nested JSON object for the u_custom_fields attribute. When testing locally, the payload appears correct, but the Genesys Cloud logs show a 400 Bad Request response from the ServiceNow endpoint. The error message indicates Invalid JSON: Unexpected token.

The issue seems to be that the Set Variable node is flattening the structure or escaping quotes incorrectly during the transformation step. The environment is Genesys Cloud v2023.11 with ServiceNow v14.1. The REST API endpoint is configured with basic authentication and a Content-Type: application/json header. The payload uses standard JSON syntax, yet the platform seems to misinterpret the curly braces within the transformation step. Has anyone successfully passed a complex nested object from an Architect flow to a third-party REST API without resorting to a base64 encoding workaround?

2

The best way to fix this is to avoid passing the entire nested object directly into the Set Variable node’s value field. The node often flattens complex structures or fails to serialize deep JSON properly when bound directly to a flow variable. Instead, construct the nested object as a raw string within the Set Variable node, then parse it later.

For the ServiceNow u_custom_fields attribute, try this approach in the Set Variable node:

  1. Create a new variable, e.g., snow_payload_str.
  2. In the value field, use a static JSON string with dynamic references for the inner values, but keep the structure as text. For example:
    {"category": "{{flow.cat}}", "subcategory": "{{flow.subcat}}"}
  3. In the subsequent Data Action or Webhook node, do not pass snow_payload_str directly as a JSON object. Instead, pass it as a string and ensure the ServiceNow endpoint expects a JSON string, or use a JSON Parse node if your platform version supports it before the action.

A more robust pattern for bulk export and legal discovery workflows-which I often apply to ensure chain of custody integrity-is to build the JSON payload in a preceding Script node (JavaScript) and assign the resulting string to a flow variable. This bypasses the UI serialization limits entirely.

Example JavaScript snippet for the Script node:

Then pass flow.snow_payload.value to the webhook. This method preserves the exact nesting required by ServiceNow and prevents the 400 Bad Request caused by malformed JSON. Also, verify that the Content-Type header in the Webhook action is explicitly set to application/json.

var customFields = {
 "category": flow.cat.value,
 "subcategory": flow.subcat.value
};
flow.snow_payload.set(JSON.stringify(customFields));
1 Like
3

The set variable node definitely struggles with nested objects in architect. try building the json as a raw string instead, like "{ \"key\": \"value\" }", and parse it later. it’s a known serialization quirk.

4

thanks for the string workaround idea. i tried it and it did stop the 400 error from servicenow. the ticket actually gets created now.

but there is a catch. when you pass it as a raw string, servicenow sees it as text, not an object. the custom fields show up as a long string in the incident form instead of separate fields. you have to do extra work on the servicenow side to parse that string back into an object before saving. that’s not ideal for our team because they don’t want to change their script includes every time we update the flow.

i went back to the architect flow and tried a different setup. instead of one big set variable node, i broke the json down. i used separate set variable nodes for each piece of the nested object. then i used a construct json node to build the final payload right before the data action.

here is what the construct json node looked like:

{
 "u_custom_fields": {
 "category": "{{flow.category}}",
 "subcategory": "{{flow.subcategory}}"
 }
}

the flow variables flow.category and flow.subcategory are set in previous nodes. this way, architect handles the types correctly. no string parsing needed.

the logs show the payload is clean json now. servicenow receives it as an object. the custom fields populate correctly in the ticket. it takes more nodes in the flow, but it’s much cleaner than messing with string escaping.

if anyone knows a way to pass the whole nested object in one go without it breaking, i’m all ears. but for now, this works.