Architect flow fails with Invalid transition when called from Java SDK

Triggering architect flow from mulesoft worker process using java sdk. The flow is simple, just sets attributes and routes to a queue. But when java app sends request, architect logs show flow started then immediately failed with FlowExecutionException: Invalid transition.

Strange thing is flow works fine when testing in architect designer UI. The java code uses FlowClient to initiate.

Here is setup part:

FlowRequest request = new FlowRequest();
request.setFlowId("abc-123-flow-id");
request.setContext(new FlowContext().put("customerId", "cust-99"));
flowClient.startFlow(request);

The logs on mulesoft side don’t show any http error. Request hangs for bit then hits rate limit. Verified the architect flow version. It’s active. Maybe the webhook payload format is wrong for api? The documentation says context should be map of strings but putting integer there might cause parse error on flow side.

Also us1 region. The java sdk version is 2.18.0.

Flow log snippet (incomplete):
2024-05-12T08:30:00.123Z ERROR FlowEngine - Transition failed at node 'SetAttributes'. Expected string type for input 'customerId' but received null.

Wait, the code passes string “cust-99”. Why does flow see null?

{
 "type": "flow.start",
 "flowId": "abc-123-flow-id",
 "context": {
 "customerId": "cust-99"
 }
}

The json looks correct when printed to console before call. The flow node config expects string input mapped to {{context.customerId}}.

Checking raw http request in mulesoft debug trace shows body is empty.

POST /api/v2/architect/flows HTTP/1.1
Host: api.mypurecloud.com
Content-Type: application/json
Content-Length: 0

Check the payload being passed through the FlowClient. The UI test injects default mock data, but the SDK call might be sending an empty JSON object or missing a required key. Architect flows are strict on input schemas. Dump the actual request body before execution and match it to the flow definition. This usually clears the invalid transition error. Can you share the exact request body you’re sending, and confirm whether the required keys are mapped in your current config?

cxone-java-sdk does not auto-inject mock values for every parameter defined on the Start node like the UI test harness does. When the flow engine attempts to evaluate a condition or route to a queue without the expected keys, it immediately drops straight to an invalid transition error.

cxone-java-sdk requires explicit payload mapping rather than guessing at the shape. Export the flow definition JSON from the designer to inspect the schema. Every required input will expose a name and a type. The SDK request must wrap these parameters in a strict input object.

Something like this usually fixes the mapping issue:

{
 "input": {
 "queueName": "Support Tier 2",
 "priority": 1,
 "customerID": "CUST-9921"
 },
 "flowType": "architect"
}

cxone-java-sdk serialization will break the routing logic instantly if the Start node expects an array or a nested object and you pass a string. The flow engine validates the schema before the first transition anyway. Missing a required field doesn’t always throw a 400. It just halts execution and logs that warning. It’s pretty standard behavior when the routing logic gets confused.

cxone-java-sdk payload dumping helps, but the real issue usually sits in how the Start node handles missing schema definitions. Another angle worth checking is the flowType field. The SDK sometimes defaults to studio or leaves it blank. Architect flows need architect explicitly set, otherwise the execution context gets confused about which routing engine to load. Also worth noting that queue routing actions require the queueId or a resolvable queueName string. If the input schema expects an ID but the test harness passed a name, the production call will fail the transition check.

cxone-java-sdk wrapper can obscure the actual failure point. Run the flow through the API gateway with a raw POST instead of the SDK wrapper for a minute. Strip out all the automatic serialization. See if the response changes. The error usually points straight to the missing key.