End & Stop
The End node explicitly terminates a workflow execution. Use it to stop processing at a specific point: after a condition is met, when an error occurs, or when a branch should not continue.
End vs. natural completion
Workflows end naturally when the last node in the chain finishes. The End node is for cases where you need to stop early or explicitly:
| Scenario | Why use End |
|---|---|
| Error handling | Stop the workflow when validation fails |
| Conditional exit | If a condition is met, exit without running remaining nodes |
| Dead branch | One branch of an If-Else should not continue |
| Status reporting | End with a specific success/failure status for monitoring |
Configuration
| Field | Type | Required | Description |
|---|---|---|---|
| Status | Select | No | Success (default), Failed, or Skipped |
| Message | FX formula | No | A message logged with the execution (for debugging) |
| Stop scope | Select | No | This branch only or Entire workflow |
Stop scope
| Option | Behavior |
|---|---|
| This branch only | Stops the current branch; other parallel branches continue |
| Entire workflow | Stops all branches; nothing else runs |
Common patterns
Validation gate
Webhook → Transformer (validate input) → If-Else (valid?) →
No: End (status: Failed, message: "Invalid input: missing email")
Yes: Continue processing...
Rate limit protection
Trigger → HTTP Request (check rate limit) → If-Else (rate limited?) →
Yes: End (status: Skipped, message: "Rate limited, will retry next run")
No: Continue with main logic...
Early exit on duplicate
Webhook → Find One (check if record exists) → If-Else (found?) →
Yes: End (status: Skipped, message: "Duplicate record, skipping")
No: Create Record → Continue...
Error branch termination
HTTP Request → Error branch →
Log (error details) → Send Email (alert) → End (status: Failed)
End status in execution history
The status you set on the End node appears in the execution history:
| Status | Display | Meaning |
|---|---|---|
| Success | Green checkmark | Workflow completed as expected |
| Failed | Red X | Workflow stopped due to an error condition |
| Skipped | Gray dash | Workflow intentionally skipped (duplicate, rate limited, etc.) |
This helps you distinguish between real failures and intentional early exits when reviewing execution history.
Tip
Use Skipped status for expected early exits (duplicates, rate limits, off-hours). Reserve Failed for actual errors. This makes your execution history much easier to read: you can filter for real failures without wading through intentional skips.