Finally Block Node
Define cleanup and audit logic that runs unconditionally — after both the success path and the catch path of a Try/Catch block.
Why "Always Runs" Matters
Consider a workflow that opens a database transaction, processes some records, and must close the transaction whether processing succeeds or fails. Without a Finally Block, you would need to duplicate the transaction-close logic in both the success path and the catch scope. With a Finally Block, the close logic appears exactly once and is guaranteed to execute.
Success Path
- Try Block executes
- All nodes in try scope complete
- Catch Block is skipped
- Finally Block executes
- Workflow continues
Exception Path
- Try Block executes
- Node throws an exception
- Catch Block executes
- Finally Block executes
- Workflow continues
Key Capabilities
- Guaranteed execution — runs after both the try success path and the catch handler, with no exception or condition that can prevent it from executing.
- Zero configuration — the Finally Block node has no properties. Place it in the workflow after the Catch Block and connect cleanup nodes to its success port.
- Access to all workflow variables set during the try and catch scopes — including exception variables if an error occurred.
- Optional — not every try/catch needs a finally block. Only add it when you have genuine cleanup or unconditional logging requirements.
- Supports any node type — database updates, HTTP calls, Slack notifications, log writes, and more.
- Can inspect whether an exception occurred (if exception variables are populated) to vary the audit log entry between success and failure without duplicating the logging node.
Business Benefits
Compliance and governance frameworks require that certain events be recorded regardless of outcome. When a payment is attempted — whether it succeeds, fails, or is cancelled — the attempt must be logged. When a data export is initiated — whether the export completes or encounters an error — the export event must be recorded in the audit trail. The Finally Block is the mechanism for this unconditional recording.
Resource management is another critical application. If a workflow holds an external resource — a file lock, a database connection, a processing queue slot, or a reserved capacity unit — that resource must be released when the workflow exits, regardless of whether the exit is clean or due to an error. The Finally Block provides the only guaranteed place to perform this release.
For long-running workflows that track state externally (e.g., setting a status record to "processing" when starting and "completed" or "failed" when ending), the Finally Block ensures the status record is always updated — even if the processing itself failed. Without it, crashed workflows leave status records perpetually stuck in "processing" state, causing downstream systems to stall.
Use Cases
Release Held Resources
A workflow that acquires an exclusive file lock or processing slot at the start uses the Finally Block to release it. Whether processing succeeds or fails with an error, the lock is released in the Finally Block, preventing resource starvation for other workflow instances waiting for the same resource.
Log Workflow Completion Status
An audit log entry is written in the Finally Block with the outcome (success or error), timestamp, and record count processed. This provides a reliable execution history regardless of whether individual records failed. Operations dashboards consume this audit log for SLA monitoring and capacity planning.
Send Audit Events
Compliance-regulated workflows emit an audit event to a SIEM or audit event bus in the Finally Block. The event includes the workflow ID, user context, action performed, and outcome. These events are emitted unconditionally, ensuring that the compliance audit trail has a complete record of all processing attempts.
Update Status Records
Long-running workflows set a status record to "processing" at the start. The Finally Block updates the status record to either "completed" (if the try scope succeeded) or "failed" (if an exception was caught). An If Condition on $mem.__exception_type__ != null distinguishes the two outcomes within the finally scope.
Clean Up Temporary Files
A document processing workflow creates temporary files during processing. The Finally Block calls the File Delete node for all temporary file paths, ensuring storage is reclaimed whether processing succeeded or failed. Without this, failed workflows accumulate orphaned temporary files indefinitely.
In This Guide
Configuration
Finally Block has no configuration — this page covers placement rules, scope mechanics, and variable availability.
Input & Output
The single success port, execution guarantee mechanics, and what data is accessible in the finally scope.
Examples
Patterns for audit logging, resource release, status updates, cleanup, and conditional outcome recording.