> For the complete documentation index, see [llms.txt](https://docs.docontrol.io/docontrol-user-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.docontrol.io/docontrol-user-guide/workflows/define-workflow-settings/error-handling.md).

# Error handling

You can configure error handling for a specific step in your workflow before you run it. This helps to better manage different failure scenarios in aggregated workflows so that minor errors will not stop the entire workflow execution. In addition, you can make implement better decisions in automated workflows based on the error statuses of workflow steps.

Error handling setup also provides valuable proactive feedback to your security team, allowing them to get notified on failures and resolve issues more quickly.

These error statuses are industry-standard terms. Note that the Warning status indicates an error that is not business-critical and doesn’t require immediate attention:

{% hint style="warning" %}
**Failure error** - An internal error that prevented the execution process from being completed, for instance if a permission required to complete the action was missing.

**Warning error** - Execution didn’t fail but couldn’t be fully completed due to a non-urgent issue, such as a file not being supported or a collaborator not being found.
{% endhint %}

You can set up error handling for these DoControl actions:

* Remediation actions
* Query actions
* Utility actions

## Error handling options

Depending on your workflow scenario, you can select the relevant error handling option for an action step inside your workflow:

### **Break on failure and warning errors**&#x20;

This is the default option. DoControl will stop the workflow execution in the case of either a failure or warning error.

### **Break on failure error only**&#x20;

In the case of aggregated workflows, you might want to ignore the events that couldn't be completed, such as a file that's not supported, and complete the events that did succeed. The workflow execution will stop only in the case of a failure error.

{% hint style="success" %}
We recommend adding a **Conditional** step to validate the results and take decisions accordingly. Even if the workflow fails and continues to run, you can notify the security team about the failure error, or decide to continue only for the successful subset of events.
{% endhint %}

### **Continue workflow**

Choosing this option continues to the next step in the workflow. You can decide to act on a subset of events, such as notifying the admin user about failures, or completing the execution of those workflows that did succeed.&#x20;

{% hint style="success" %}
We recommend adding a **Conditional** step to validate the results and take decisions accordingly. Even if the workflow fails and continues to run, you can notify the security team about the failure error, or decide to continue only for the successful subset of events.
{% endhint %}

<figure><img src="https://3236294211-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MesrnyDMZGYg1V-tOBo%2Fuploads%2FJF3sxVo1S8ZBntxFI0uT%2Ferror%20handling.png?alt=media&amp;token=d5357e7d-b52c-48c6-b1ed-718730728e36" alt=""><figcaption><p>Configure error handling for a remediation, query or utility action step in your workflow executions</p></figcaption></figure>

## Configure error handling

For remediation, query and utility actions, you can configure error handling in the action pane.

1. In the Workflow canvas, select the action step for which you want to define error handling.
2. Under Error handling, choose the relevant option:
   * Break on **failure** and **warning** errors
   * Break on **failure** error only
   * Continue workflow
3. If you select **Break on failure error only**, or **Continue workflow:**
   * Add an action step to filter the subset of events you'd like to continue with: only the successful executions, or also those executions with warning errors.
   * Add a **Conditional** action to validate results. We recommend adding a **Conditional** step to validate the results and take decisions accordingly.\
     Even if the workflow fails and continues to run, you can notify the security team about the failure error, or decide to continue only for the successful subset of events.
4. Click **Save**.

{% hint style="info" %}
Break on **failure** and **warning** errors is the default option.&#x20;
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.docontrol.io/docontrol-user-guide/workflows/define-workflow-settings/error-handling.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
