Stop and Error node

Overview

The Stop and Error tool intentionally throws an error to halt workflow execution. It supports two modes: a simple error message string, or a JSON error object with structured fields (message, description, code, type). Use this when a workflow should fail with a specific error under certain conditions.

Node Type

Action — processes input items and produces output

Input / Output

Direction	Port(s)
Input	Input
Output	Output, Error

Credentials

This tool does not require any credentials.

Parameters

Parameter	Type	Required	Default	Description
Error Type	options	No	errorMessage	Type of error to throw.
				Options: errorMessage, errorObject
Error Message	string	Yes	—	The error message to throw. (shown when Error Type is errorMessage)
Error Object	json	Yes	—	Object containing error properties. Supports fields: message, description, error, code, type. (shown when Error Type is errorObject)
Max Concurrency	number	No	10	Maximum number of items to process concurrently.

Output Data

This node always fails the items it receives — that is its whole purpose. What reaches the rest of the workflow depends on the node’s error-handling mode:

• stop — the first item throws and the workflow run halts. Nothing is emitted.
• continue (the default) — each input item is turned into an error item and leaves on Output, carrying an _error object alongside the original item JSON. Downstream nodes will see them, so check for _error before treating that branch as normal traffic.
• errorPort — the same error items are routed to the Error output instead, leaving Output empty.

The message on the error is resolved once for the whole node run:

• With Error Type errorMessage, the message is the Error Message text, or Workflow stopped with error when it is empty.
• With Error Type errorObject, the message is the object’s message, falling back to description, then error, and finally to the whole object rendered as JSON. description is carried through when present, and the full object you supplied is attached to the error as its metadata. Text that is not valid JSON produces the message Invalid error JSON: … rather than silently succeeding.

Example Configuration

Fail with a plain message:

{
  "type": "stop_and_error",
  "parameters": {
    "errorType": "errorMessage",
    "errorMessage": "Validation failed: Required field is missing"
  }
}

Fail with a structured error object:

{
  "type": "stop_and_error",
  "parameters": {
    "errorType": "errorObject",
    "errorObject": {
      "message": "Authentication failed",
      "description": "The provided API key is invalid or expired",
      "error": "INVALID_API_KEY",
      "code": 401,
      "type": "AuthenticationError"
    }
  }
}

Fail a validation branch, limiting how many items are processed at once:

{
  "type": "stop_and_error",
  "parameters": {
    "errorType": "errorMessage",
    "errorMessage": "Invalid input: email address format is incorrect",
    "maxConcurrency": 5
  }
}

Return an API-style error:

{
  "type": "stop_and_error",
  "parameters": {
    "errorType": "errorObject",
    "errorObject": {
      "message": "Resource not found",
      "description": "The requested user ID does not exist in the database",
      "error": "USER_NOT_FOUND",
      "code": 404,
      "type": "NotFoundError"
    }
  }
}

Raise a business-rule failure:

{
  "type": "stop_and_error",
  "parameters": {
    "errorType": "errorObject",
    "errorObject": {
      "message": "Insufficient funds",
      "description": "Account balance is too low to complete this transaction",
      "error": "INSUFFICIENT_BALANCE",
      "code": 422,
      "type": "BusinessRuleError"
    },
    "maxConcurrency": 1
  }
}

Error Handling

Mode	Behavior
stop	Halts workflow on first error
continue	Skips failed items, passes successful ones through
errorPort	Routes failed items to Error output port

Tips

The Stop and Error tool intentionally halts workflow execution. It is the right tool when a workflow needs to fail with a specific error under certain conditions, rather than continuing or completing successfully. It produces a custom error message string or a structured JSON error object.

Behavior notes

• Put it behind a condition. This node fails everything that reaches it, so gate it with an If or Switch node — wire only the branch that represents the failure case into it.
• Set the node’s error handling to stop if you want the run to actually halt. On the default continue setting the error becomes an item and the workflow keeps going.
• The error text is fixed, not per item. Error Message and Error Object are read once for the node and used verbatim for every item, so write a message that makes sense on its own rather than one that depends on a particular record. To include values from the data, build the message in an upstream node and branch on it.