# Agentic Workflow Error Handling {% hint style="success" %} **Audience**: Administrators, Developers, Solution Architects **Purpose**: Reference for the error handling configuration available on space.vars.automation steps. {% endhint %} ## Overview Most space.vars.automation steps include an **Error Handling** configuration that determines what happens when the step fails during execution. This configuration controls two independent settings: * **Behavior on failure**: whether the execution continues, pauses, or stops, and whether a notification is sent. * **Notification severity**: how the resulting notification is categorized for review and filtering. Error handling is configured per step, so different steps within the same space.vars.automation can respond to failures in different ways depending on how critical each step is to the overall space.vars.workflow. *** ## Behavior on Failure The behavior dropdown determines what the execution does when the step fails.
Three options are available: * **Continue and Notify on Failure**: The execution continues to the next step and a failure notification is sent. Use this when the step is non-critical and the space.vars.workflow should proceed regardless of the outcome. * **Pause and Notify on Failure**: The execution pauses at the failed step and a failure notification is sent. The execution can be resumed after the issue is resolved. Use this when the step is critical and the space.vars.workflow should not continue until the failure is investigated. * **Continue on Failure and Do Not Notify**: The execution continues to the next step silently. No notification is sent. Use this only when failures are expected or acceptable and do not require review. ### Multi-Action Step Behavior Some steps run multiple actions internally. These steps are treated as successful if at least one of their actions succeeds. The step only enters a failure state — and only triggers the configured Behavior on Failure — when every action inside it fails. Partial failures do not stop the execution or send a notification. *** ## Notification Severity The **Error Notification Severity** setting controls how the failure notification is categorized. Severity affects categorization and filtering only: it does not change whether the execution continues, pauses, or stops. That behavior is governed entirely by the Behavior on Failure setting above.
Four severity options are available: * **Inherit from Automation (Gray)**: Uses the severity defined at the parent space.vars.automation level. Default for most steps. * **Error (Red)**: Indicates a failure that requires immediate attention. * **Warning (Yellow)**: Indicates a failure that should be reviewed but is not necessarily blocking. * **Info (Blue)**: Indicates a failure that is informational only. *** ## Exceptions for Error Handling Most steps support the standard Error Handling configuration. The following steps are exceptions and do not include error handling, either because they have no failure state or because their behavior makes step-level error handling unnecessary: * **Triggers**: Initiate execution; they either fire or do not, with no failure state for error handling to catch. * **Delays**: Wait for a specified duration before continuing; have no failure state. * **Go To Automation Step**: Redirects execution within the same space.vars.automation; no failure mode is exposed. * **Stop Execution**: Explicitly sets a terminal state, which makes step-level error handling unnecessary. ### Resuming Paused Executions When a step is configured with **Pause and Notify on Failure** and the step fails, the execution enters a paused state at that step. Paused executions can be resumed once the underlying issue is resolved. *** ## What's Next? Return to the action category page you were configuring, or review related references below.
Related Topics * [Automation Control Actions](/docs/concepts/agentic-workflows/agentic-workflow-actions/agentic-workflow-control-actions.md) * [Field Actions](/docs/concepts/agentic-workflows/agentic-workflow-actions/agentic-workflow-field-actions.md) * [Related Object Actions](/docs/concepts/agentic-workflows/agentic-workflow-actions/agentic-workflow-related-object-actions.md) * [Team Actions](/docs/concepts/agentic-workflows/agentic-workflow-actions/agentic-workflow-team-actions.md) * [Integration Actions](/docs/concepts/agentic-workflows/agentic-workflow-actions/agentic-workflow-integration-actions.md) * [Messages Actions](/docs/concepts/agentic-workflows/agentic-workflow-actions/agentic-workflow-messages-actions.md)
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://developer.kizen.com/docs/concepts/agentic-workflows/agentic-workflow-actions/agentic-workflow-error-handling.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.