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 workflow designer.
  • 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.

  • Max Delay (seconds)   Upper limit for the retry delay.

  • 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.

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 workflow designer. 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.