Portal Community
No configuration required. The Try Block node has no configurable properties. It is a structural node — it declares a guarded scope boundary and pushes an exception context frame. Simply add it to your workflow before the nodes you want to protect from unhandled exceptions.

Minimal Configuration Object

The node's configuration block in the workflow definition is minimal:

{
  "nodeType": "TryBlock",
  "id": "try_api_call",
  "label": "Try — External API Call"
}

Scope Rules

Understanding the Try Block's scope rules is essential for correct error handling behaviour:

Pairing with Catch and Finally

In the workflow designer, connect nodes as follows:

  1. Place the Try Block node where you want guarded execution to begin.
  2. Connect the Try Block's "success" port to the first node that should run inside the protected scope.
  3. Continue building the protected scope's graph normally (all nodes reachable from the try's success port are in scope).
  4. Place the Catch Block node at the same level as the Try Block. The engine automatically associates the nearest Try Block with the Catch Block in execution order.
  5. Optionally, place a Finally Block node after the Catch Block at the same level.
Scope boundary: Only exceptions that originate within nodes directly or transitively connected from the Try Block's success port are intercepted. Exceptions from nodes that are placed before the Try Block, or on other branches of the workflow graph, are not affected by this try/catch scope.

Exception Context Frame

When the Try Block executes, it pushes an exception context frame onto the workflow's execution stack. This frame:

When the scope exits normally (no exception), the frame is popped and execution continues to the Finally Block (if present) or the node immediately following the try/catch/finally trio.