Skip to main content
This page lists the error messages FlowX.AI users hit most often, with the exact message text so you can find it by search. Each entry explains what the error means, its usual causes, and where to fix it.
Copy the exact error message into the search bar or the AI assistant - the entries below use the platform’s exact wording.

How FlowX reports errors

Process errors (incidents): when a process instance hits a problem, the error details attached to the instance include a Source (the node or action that failed), a Cause Type (one of the messages below), and a Timestamp. Example of what you’ll see:
API errors: REST endpoints return errors in application/problem+json format, with a type of https://www.flowx.ai/error, a human-readable title, and an HTTP status:

Business rules and gateways

Invalid business rule expression.

The script attached to a business rule action could not be parsed or executed. Common causes:
  • Syntax that is invalid for the selected scripting language - a rule written for one language while the action is set to another.
  • Referencing process data keys that don’t exist yet at the time the rule runs.
  • Language features that the embedded runtime doesn’t support - the rule can pass an editor check but fail at runtime.
Fix: open the business rule on the failing node, confirm the selected language matches the syntax, and test with the data the instance actually has at that point. See Business rule action.

Could not execute condition.

A condition expression on an action failed to evaluate. Same causes and fixes as invalid business rule expressions - check the expression’s language and the data it references.

Invalid gateway rule. / The rule returned no result. / Missing sequence from gateway rule evaluation.

An exclusive gateway could not pick an outgoing branch:
  • Invalid gateway rule. - the rule expression itself failed to evaluate.
  • The rule returned no result. - the rule ran, but no branch condition matched the instance data.
  • Missing sequence from gateway rule evaluation. - the rule picked a branch that has no outgoing sequence configured.
Fix: make sure the gateway’s conditions cover every possible data state (add a default branch) and that each branch connects to a next node. See Exclusive gateway.

Executing a script produced an error!

A Script node inside an integration workflow (not a process business rule) failed - the message is followed by the underlying cause, for example SyntaxError: expected '(' at line 4, column 9. Fix: open the workflow’s Script node and correct the JavaScript or Python code at the reported line. Test the node individually before re-running the workflow. See Integration Designer.

Timers

Invalid timer definition. / Timer expression is not valid

The timer event’s expression could not be parsed - typically a malformed cron or ISO 8601 duration expression. Fix: validate the expression format against Timer expressions.

Timer could not be triggered due to invalid format of process parameter.

The timer is configured with a dynamic value from process data, and at runtime that parameter held a value that isn’t a valid timer expression (wrong format, empty, or not a date/duration). Fix: check the process data key the timer reads and make sure every path that reaches the timer sets it to a valid cron or ISO 8601 value. See Timer events.

Messages and correlation

The message does not follow the custom integration data model.

A message received from an external system (or sent to one) doesn’t match the data model configured on the integration. The error often carries the underlying parser message appended after it. The most common variant is:
Unrecognized token '$' means the message body wasn’t valid JSON when the engine parsed it - almost always because a ${...} placeholder in the body did not resolve and was sent through as literal text. That happens when the process data key the placeholder references doesn’t exist (or is misspelled) at the moment the message is sent. Fix:
  • For the Unrecognized token '$' variant: check every ${...} placeholder in the message body against the instance’s process data at the point the Send Message Task runs - the referenced keys must exist and hold values by then.
  • Otherwise: compare the actual message payload against the data model defined for the integration - field names and structure must match exactly. See Integrations.

Invalid send message structure. / Invalid receive message structure.

The data mapped on a Send Message Task or Receive Message Task doesn’t match what the node expects - usually a mapping that references missing keys or produces the wrong shape. Fix: review the node’s data mapping against the message structure. See Message events.

Correlation errors on throw and catch events

  • Correlation value null or empty for throw event. / Correlation key null or empty for throw event. / Event name null or empty for throw event. - the throw event is missing its identification, usually because the process data key used as correlation is empty at runtime.
  • No catch events with event name and correlation value. - the message was thrown, but no waiting catch event matched both the event name and the correlation value.
  • Duplicated correlation value. - more than one waiting catch event matched the same correlation value, so the message can’t be delivered unambiguously.
Fix: make sure the throw and catch events use the same event name, and that the correlation key resolves to a unique, non-empty value on both sides. See Message events.
Token waits forever at a Receive Message Task? That is usually not an error but a correlation miss: the reply arrived with a different event name or correlation value than the catch event expects, or the workflow/subprocess completed without sending it. Check the three correlation errors above first.

Integration workflow output

The first two errors below appear as a WORKFLOW_PARAMETERS incident on the process instance, with the Receive Message Task as the source and a cause type of Invalid or incomplete workflow output. The third surfaces in the workflow run details, on the failed End node.

The mandatory output parameters of the workflow are missing at runtime.

The message appears on two surfaces with slightly different wording: the process incident reads The mandatory output parameters of the <workflow> workflow are missing at runtime., while the workflow run details read The following mandatory output parameters of the <workflow> workflow are missing at runtime: <parameter>. - the run details name the missing parameter, so start there. The workflow reached an End node, but a parameter declared in the workflow’s output schema resolved to no value. Declared output parameters are a runtime contract: the workflow run fails when any of them ends up empty, and the calling process records the incident. The data source call itself usually succeeded - the problem is the End node’s output mapping expression. A placeholder that references a non-existent key resolves silently to null instead of raising an error, so this message is the only symptom. Common causes:
  • A misspelled key in the End node’s output mapping - for example ${responeKey.data} instead of ${responseKey.data} (the Response Key configured on the REST node).
  • An input. or output. prefix inside the placeholder - use the bare key: ${responseKey.data}, never ${output.value}.
Fix: open the workflow’s End node output mapping and point every declared parameter at a key that exists at that point in the workflow. For a REST result, the response body lives at ${<responseKey>.data}, where <responseKey> is the Response Key set on the REST node. Run the workflow from the editor and open the End node in the run details - it shows the exact input it received and the output JSON it produced, so a null value is immediately visible. See End node.

Workflow output cannot be appended to the process instance due to missing mapping in the data stream.

Full form: <workflow> workflow output cannot be appended to the process instance due to missing mapping in the data stream. The workflow finished and returned its output, but the Receive Message Task waiting for it has no output mapping saved on its data stream, so the engine doesn’t know which process attribute should receive the result. This often happens after the mapping was configured on screen but never persisted: in the mapping modal, Test only previews the result. Click Confirm to store the mapping, then save the node itself. Fix: on the Receive Message Task, open the Integration Output data stream and the output mapping for the workflow’s End node, map the workflow output to a process attribute, click Confirm, and save the node. See Integration Output.

Executing an end node produced an error!

Shown as the run error in the workflow run details, with the End node marked FAILED and its output null. The End node could not render its return payload - most often because the payload stops being valid JSON once the ${...} placeholders are substituted. Placeholders are substituted as raw text, so whatever the key resolves to lands in the payload verbatim. Plain-text API responses are the classic trigger. A text/plain endpoint typically returns its value with a trailing newline (for example "2395\n"), and a raw newline inside a JSON string literal is invalid JSON. For such a value, the usual quoting rule inverts:
  • {"value": ${responseKey.data}} - works when the value is numeric: the trailing newline falls outside the number, where JSON treats it as whitespace.
  • {"value": "${responseKey.data}"} - fails: the newline lands inside the string literal.
Fix: keep the placeholder unquoted when the resolved value is a number or boolean. If the value must be a string, or the response may carry other control characters, clean it before the End node - for example a Script node with output.value = input.responseKey.data.trim(); - and reference the cleaned key. The failed End node in the run details shows the exact input it received, which makes the offending character visible.
A failed workflow reply is not retried. A process instance whose workflow call failed with any of these errors stays blocked at the Receive Message Task permanently - after fixing the configuration, always test with a new process instance.

Subprocesses

Missing subprocess definition or a published version. / The subprocess couldn’t start because we couldn’t find a published version.

The parent process references a subprocess that either doesn’t exist in the project (or its dependencies) or has no published version in the active build. Fix: publish the subprocess and make sure the build that runs includes it. See Subprocess.

Incorrect action configuration, the subprocess is missing or is not referenced correctly.

The Start Subprocess action (or embedded subprocess node) points at a subprocess name that can’t be resolved - renamed, moved, or not referenced through the right dependency. Fix: re-select the subprocess in the action/node configuration. See Subprocess.

Could not render subprocess due to multiple swimlanes or missing Parent Process Area.

An embedded subprocess can’t render its UI. The platform requires the embedded subprocess to have exactly one swimlane and to define a Parent Process navigation area that its UI renders into - this error means one of the two is missing. Fix: in the subprocess definition, reduce to a single swimlane and add a Parent Process navigation area for its UI. See Subprocess.

SubProcess params cannot be parsed.

The data passed to the subprocess at start couldn’t be parsed - usually a mapping that produces malformed or unexpected data. Fix: check the input mapping on the subprocess start configuration.

Export and import

Resource format incompatibility.

Shown when importing a project version or build. Two exact variants:
Each resource type in an export archive is stamped with a format version. The import is rejected when those stamps don’t match what the target environment supports (do not match variant - the archive was exported from a platform version whose resource formats differ from the target’s) or aren’t present at all (are missing variant - typically an archive produced by a much older version, before format stamping). A sibling error, Configuration parameter format incompatibility: the config params format versions in the import do not match with current config params format versions on the environment., reports the same condition for configuration parameters. Fix: re-export from a source environment running a platform version compatible with the target, and use the export option that targets the destination version where available - incompatible resources are then excluded and listed in the manifest instead of failing the import. See How incompatible content is handled.

API errors

Entity not found.

A 404 in the standard error envelope: the resource referenced by the request - a file, document, process instance, or other entity - doesn’t exist or isn’t accessible with the caller’s permissions. Frequently seen on file previews and document URLs when the file ID is wrong or the underlying file was deleted. Fix: verify the identifier being requested and that the caller’s role can access it.

Glossary

The FlowX.AI vocabulary - what each core term means.

Cookbooks

Tutorials, guides, and reusable patterns.
Last modified on September 30, 2026