End Node
Overview
The End node terminates workflow execution without producing a specific output. It marks a completion point where the workflow stops processing, useful for branches that don’t need to return data or for gracefully ending execution paths.
When to Use
Use an End node when you need to:
- Terminate a workflow branch without output
- End execution after completing side effects (e.g., logging, notifications)
- Close conditional branches that don’t need to return data
- Explicitly mark completion points in complex workflows
- Stop processing after an error handling path
- End a workflow that performs actions without needing a result
Configuration
The End node has minimal configuration:
- Node ID: Unique identifier for the node
- Name: Descriptive name for the end point
No other configuration is required.
How It Works
- Execution Reaches End Node: Workflow processing arrives at the End node
- Terminates Execution: Workflow stops immediately
- No Output: Unlike Set Output node, End doesn’t define workflow output
- Marks Complete: Workflow is marked as completed successfully
Examples
Example: End After Notification
Flow:
processOrder
└─ sendConfirmationEmail
└─ EndThe workflow processes an order and sends an email, then ends. No output needed since the work is done.
Example: Error Handling Path
Flow:
validateInput
└─ Conditional: checkValid
├─ Valid → processData → Set Output: results
└─ Invalid → logError → sendAlert → EndInvalid data is logged and an alert is sent, then the workflow ends without output.
Example: Multiple End Points
Flow:
checkCondition
└─ Conditional: evaluateRisk
├─ Low Risk → autoApprove → Set Output: approved
├─ Medium Risk → requestApproval → Set Output: pending
└─ High Risk → rejectRequest → notifySubmitter → EndHigh risk requests are rejected and the submitter is notified, then the workflow ends.
Example: Cleanup Branch
Flow:
Parallel: processAndCleanup
├─ Branch 1: Process Data
│ └─ processData → Set Output: results
└─ Branch 2: Cleanup
└─ deleteTemporaryFiles → EndCleanup branch ends after deleting files, while the main branch returns results.
Example: After Side Effects
Flow:
createUser
└─ sendWelcomeEmail
└─ createAuditLog
└─ triggerWebhook
└─ EndAfter creating a user and performing several side effects, the workflow ends without returning specific output.
End vs Set Output
Use End when:
- The workflow performs actions without needing to return data
- You’re in an error/cleanup branch
- Side effects (logging, notifications) are the primary purpose
- No calling system needs a response
Use Set Output when:
- You need to return data to a calling system
- Another workflow will use this workflow’s results
- An API consumer needs structured response data
- You want to document what the workflow produces
Common Patterns
Notification Only Workflow
trigger
└─ formatMessage
└─ sendNotification
└─ EndPurpose is to send notifications, no output needed.
Error Branch Termination
processData
└─ Conditional: checkSuccess
├─ Success → Set Output: results
└─ Failure → logError → EndFailed processing is logged and workflow ends.
Background Task Completion
scheduleReport
└─ generateReport
└─ uploadToStorage
└─ notifyUsers
└─ EndScheduled task completes actions and ends.
Conditional Early Exit
checkPreconditions
└─ Conditional: canProceed
├─ Yes → continueProcessing → Set Output: results
└─ No → logSkipped → EndIf preconditions aren’t met, log and exit early.
Multiple End Nodes
A workflow can have multiple End nodes in different branches:
routeRequest
└─ Conditional: requestType
├─ Type A → processTypeA → Set Output: resultA
├─ Type B → processTypeB → Set Output: resultB
└─ Type C → logUnsupported → EndUnsupported request types are logged and the workflow ends without output.
Best Practices
- Use Descriptive Names: Name End nodes to indicate why execution is ending (e.g., “End After Cleanup”, “End on Invalid Input”)
- Document Paths: Make it clear why a particular path ends without output
- Consider Output: Think carefully whether a branch should return data or just end
- Cleanup First: Perform any necessary cleanup before the End node
- Logging: Log important information before ending, especially in error paths
- Consistency: Be consistent about when to use End vs Set Output across workflows
Limitations
- No Output: Cannot return data (use Set Output if you need that)
- No Conditional End: End node always terminates; can’t conditionally continue
- Implicit End: If a node has no onSuccess, workflow ends implicitly (End node is optional but explicit)
Implicit vs Explicit End
Implicit End (No End Node):
sendEmail
(no onSuccess, workflow ends here)Explicit End (With End Node):
sendEmail
└─ EndBoth work the same way. Use an explicit End node when:
- You want to be clear about termination points
- Documentation and visual clarity are important
- The workflow structure is complex
Execution Status
When a workflow ends via an End node:
- Status:
Completed - Has Output:
No(unless a Set Output node executed earlier in the path) - Exit Code:
Success
This is different from a failure, which would show:
- Status:
Failed - Error information in execution logs
Example Workflows
Pure Side-Effect Workflow
trigger
└─ Parallel: notifyAll
├─ Branch 1: sendEmail
├─ Branch 2: sendSMS
└─ Branch 3: createNotificationLog
└─ EndAll branches perform actions, then workflow ends without output.
Mixed Success/Failure Paths
validateAndProcess
└─ Conditional: isValid
├─ Valid
│ └─ processData
│ └─ Conditional: processSuccess
│ ├─ Success → Set Output: results
│ └─ Failure → logProcessingError → End
└─ Invalid
└─ logValidationError → notifyUser → EndMultiple end points for different failure scenarios, one success path with output.
Cleanup After Error
complexOperation
onFailure: cleanupAndEnd
cleanupAndEnd:
└─ rollbackChanges
└─ releaseResources
└─ notifyAdmins
└─ EndWhen an error occurs, cleanup happens and workflow gracefully ends.