StopWorkflow stop

When to Use

• Explicit success gate: At the end of all branches in a complex workflow, use StopWorkflow with status: "success" to mark clean completion. This ensures execution history always shows an explicit terminal status rather than an ambiguous implicit end, and triggers any downstream monitoring or alerting that watches for completed workflows.
• Business rule rejection: After validating an order, if the product is out of stock or the customer account is suspended, use StopWorkflow with status: "cancelled" and a descriptive message — e.g. "Product SKU-4412 is out of stock. Order not processed." — to record the business reason without treating it as an error.
• Error termination after CatchBlock: In a TryBlock/CatchBlock pattern, after exhausting retries or catching an unrecoverable error, call StopWorkflow with status: "failed" and pass the exception message dynamically via message_expression to preserve the root cause in execution history.
• Conditional early exit: After processing a batch, check whether the result meets a threshold. Exit with "success" if the threshold is met, or "cancelled" if no further action is needed — keeping execution history meaningful without forcing everything into a success/fail binary.
• Sub-workflow result signaling: In a validation sub-workflow, return status: "success" when data is valid or status: "failed" when it is not — the parent's SubWorkflow node then routes to its success or error port accordingly, enabling clean branching in the parent without embedding the validation logic there.

Configuration

Status Semantics

Sample Configuration

Explicit success with a summary message

{
  "status": "success",
  "message_expression": "{{ 'Invoice ' + $output.createInvoice.invoiceId + ' generated and emailed to ' + $json.customerEmail }}"
}

Business rule cancellation (static message)

{
  "status": "cancelled",
  "message": "Customer already has an active subscription. No renewal action required."
}

Failed with dynamic exception detail

{
  "status": "failed",
  "message_expression": "{{ 'Validation failed: ' + $var.__exception_message__ }}"
}

Sub-workflow result signal (validation child)

{
  "status": "failed",
  "message_expression": "{{ 'Invalid customer record: ' + $output.validateFields.errors }}"
}

Validation Errors

StopWorkflow performs minimal validation — it is designed to always be reachable. There are no pre-execution configuration errors. The only runtime condition that prevents execution is if status is missing entirely from the node configuration, which will default to recording an empty status string.

Output / Execution Ports

StopWorkflow has no output ports. It is a terminal node — no downstream connections are possible. When the workflow reaches a StopWorkflow node, execution ends for the current workflow context.

Execution History Fields Written

Sample Output

Execution history record written by StopWorkflow

{
  "ExecutionStatusID": "failed",
  "stop_message": "Validation failed: email field is not a valid email address",
  "stopped_at": "2026-05-26T11:42:08Z",
  "stopped_by_node": "stopOnValidationError"
}

Parent SubWorkflow error port — child stopped with "failed"

// $output.runValidation on parent's error port:
{
  "error": {
    "code": "CHILD_WORKFLOW_FAILED",
    "message": "Validation failed: email field is not a valid email address"
  }
}

Expression Reference

StopWorkflow is a terminal node and produces no output data. It writes only to execution history. The following expressions are available in the parent workflow on the error port after a child workflow terminates via StopWorkflow.

Node Policies & GuardRails

Examples

Example 1 — Validation Sub-Workflow Signaling Parent

A "Validate Order" child workflow checks product availability, customer credit, and shipping region eligibility. It uses StopWorkflow to signal the parent with a precise status and message. The parent SubWorkflow node routes to success or error accordingly, keeping all validation logic encapsulated in the child.

// Inside child workflow "Validate Order" (workflow ID: 55)
ManualTrigger  [key: "start"]
  └─► HttpRequest  [key: "checkInventory"]
        GET /inventory/{{ $json.productId }}
        └─► IfCondition  [key: "hasStock"]
              Condition: {{ $output.checkInventory.quantityAvailable > 0 }}
              ├─► true ──► HttpRequest  [key: "checkCredit"]
              │              GET /customers/{{ $json.customerId }}/credit
              │              └─► IfCondition
              │                    Condition: {{ $output.checkCredit.approved == true }}
              │                    ├─► true  ──► StopWorkflow  (status: "success", message: "Order validation passed")
              │                    └─► false ──► StopWorkflow  (status: "failed", message: "Credit check failed for customer {{ $json.customerId }}")
              └─► false ──► StopWorkflow  (status: "cancelled", message: "Product {{ $json.productId }} is out of stock")

// Inside parent workflow:
SubWorkflow  [key: "validateOrder"]
  sub_workflow_id: 55
  ├─► success ──► [proceed to fulfillment]
  └─► error   ──► Slack  (alert ops: {{ $output.validateOrder.error.message }})

Example 2 — CatchBlock Error Termination with Dynamic Message

A TryBlock wraps an external payment API call. If the call fails after retries, the CatchBlock catches the exception and routes to StopWorkflow with a message_expression that embeds the actual error detail from the exception variable into the recorded message.

TryBlock  [key: "tryPayment"]
  └─► body ──► HttpRequest  [key: "chargeCard"]
                POST /payments/charge
                body: { cardToken: {{ $json.cardToken }}, amount: {{ $json.amount }} }
  └─► catch ──► IfCondition  [key: "isRetryable"]
                  Condition: {{ $output.chargeCard.statusCode == 429 || $output.chargeCard.statusCode == 503 }}
                  ├─► true  ──► Delay  (duration_seconds: 30)
                  │              └─► success ──► [retry TryBlock — up to 3 attempts via Loop]
                  └─► false ──► StopWorkflow
                                  status: "failed"
                                  message_expression: "{{ 'Payment failed (non-retryable): HTTP ' + $output.chargeCard.statusCode + ' — ' + $var.__exception_message__ }}"

Example 3 — Multi-Branch Workflow with Explicit Success and Cancellation Exits

An order fulfilment workflow branches by order type. Each branch terminates with an explicit StopWorkflow node carrying a context-specific message. A shared "already fulfilled" early-exit path uses "cancelled" to distinguish intentional skipping from an actual error.

WebhookTrigger  [key: "orderReceived"]
  └─► HttpRequest  [key: "checkDuplicate"]
        GET /orders/{{ $json.orderId }}/status
        └─► IfCondition  [key: "isDuplicate"]
              Condition: {{ $output.checkDuplicate.alreadyFulfilled == true }}
              ├─► true ──► StopWorkflow
              │              status: "cancelled"
              │              message_expression: "{{ 'Order ' + $json.orderId + ' already fulfilled on ' + $output.checkDuplicate.fulfilledAt + '. Skipped.' }}"
              └─► false ──► Switch  [key: "routeByType"]
                              ├─► "digital" ──► HttpRequest  (POST /delivery/digital  ...)
                              │                  └─► StopWorkflow
                              │                        status: "success"
                              │                        message_expression: "{{ 'Digital delivery sent for order ' + $json.orderId }}"
                              └─► "physical" ──► HttpRequest  (POST /warehouse/pick  ...)
                                                 └─► StopWorkflow
                                                       status: "success"
                                                       message_expression: "{{ 'Warehouse pick initiated for order ' + $json.orderId + ', tracking: ' + $output.warehousePick.trackingId }}"