Skip to main content
Version: Current

Error Handling

Overview​

On Error is a configurable error-handling policy available at both the workflow and activity levels. It defines how the system should respond when an activity encounters a runtime error.

You can configure a default error-handling strategy at the workflow level and override it for individual activities when different behavior is required.

Configuration Scope​

Workflow Level​

Configure a default error-handling policy that applies to all workflow activities.

  • Open the Agent Builder.
  • Use the Error Handler Configuration option from the workflow context menu.
  • The configured policy becomes the default for all activities unless explicitly overridden.

Activity Level​

Configure an error-handling policy specific to an activity.

  • Open the activity properties.
  • Locate the On Error field and click Configure.
  • If the value is set to Inherit, the activity uses the workflow-level policy.

Error Handling Strategies​

The following strategies are supported:

  • Fault   Immediately fails the activity and terminates the workflow execution path.

  • Continue   Logs the error and continues execution with the next activity.

  • Suspend   Pauses the workflow instance and optionally notifies configured recipients.   The instance can be resumed after corrective action and continues from the activity that failed.

  • Retry   Retries the activity based on the configured retry settings.   If all retries are exhausted, a fallback strategy is applied.

  • Inherit   Uses the workflow-level error-handling policy.     Available only at the activity level.

Retry Settings  ​

(Applicable when Strategy = Retry)

  • Max Retry Count   Number of retry attempts before applying the fallback strategy.

  • Retry Interval (seconds)   Delay between consecutive retry attempts.

  • Exponential Backoff Increases the delay on successive retries when enabled. When disabled, retries use the configured interval.

  • Max Delay (seconds)   Upper limit for the delay when exponential backoff is enabled.

  • Fallback Strategy   Strategy to apply after the final failed retry. Supported values: Fault, Continue, Suspend.

  • Notify To   Required when the fallback strategy is Suspend. Accepts email addresses or workflow variables.

Suspend Settings​

  • Notify To   Required when the strategy is Suspend.   Accepts email addresses or workflow variables to notify responsible users or groups.

Precedence and Inheritance​

  • Activity-level configuration overrides the workflow-level default.
  • If an activity is configured with Inherit, the workflow-level policy applies.

Designer Behavior​

  • The activity properties panel displays a summary such as On Error: Inherit or the selected strategy.
  • Clicking Configure opens a dialog that displays only the fields relevant to the selected strategy.
  • Required fields are validated contextually (for example, Notify To is mandatory for Suspend, and for Retry when the fallback strategy is Suspend).

  • Safe default (recommended)   Configure the workflow-level strategy as Suspend with a notification group.   Override critical activities to Retry with a limited retry count and a Fault fallback.

  • Best-effort workflows   Configure the workflow-level strategy as Continue to allow execution to proceed.   Override key activities to Fault when data consistency or correctness is critical.

Using outputs after an error​

Continue allows execution to move on; it does not supply a successful result for the failed operation. Before consuming an output, check whether the activity produced the value your workflow needs. Handle the failure on a separate path when subsequent steps require a valid result.

For operations that write data, send a message, or initiate a call, consider whether a retry could repeat an action that already succeeded remotely. Choose retry settings for the operation, and use a bounded retry count and a suitable fallback.

Custom Error Handlers​

In addition to the standard On Error strategies, many workflow activities support Custom Error Handlers.

Custom Error Handlers allow you to build a dedicated error-processing path directly in the Agent Builder. Instead of applying a predefined strategy such as Fault, Continue, Retry, or Suspend, you can define custom recovery, notification, auditing, and remediation logic.

Typical use cases include:

  • Sending notifications when an activity fails
  • Creating incidents or support tickets
  • Recording audit information
  • Executing compensating actions
  • Performing custom recovery logic

Custom Error Handlers are configured directly on supported activities by enabling an additional error output port and connecting an error-handling workflow path.

info

Not all activities currently support Custom Error Handlers. Some lightweight activities, such as primitive activities, may not expose the error port.

For detailed configuration instructions, see:

Choosing Between On Error and Custom Error Handlers​

Use On Error strategies when a generic error-handling policy is sufficient.

Examples:

  • Retry a network operation.
  • Suspend execution and notify an administrator.
  • Continue processing despite non-critical failures.
  • Fail the workflow immediately.

Use Custom Error Handlers when activity-specific processing is required.

Examples:

  • Send different notifications depending on the activity.
  • Create incidents in external systems.
  • Log detailed diagnostic information.
  • Execute recovery workflows.
  • Route failures to specialized handling paths.

In many workflows, standard On Error policies provide the default behavior, while Custom Error Handlers are used only for activities that require specialized error processing.

Help improve this page