> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.itential.com/itential-cloud/studio/tasks/reference/error-handling/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.itential.com/_mcp/server. # ErrorHandling > Use the ErrorHandling task to manage error severity levels and control workflow flow in response to fatal errors, warnings, or successful states. The `ErrorHandling` manual task is available under **Tools** and performs error handling in a workflow. The task allows you to provide a severity level of `fatal`, `warning`, or `success` as well as a status message. You may specify whether retry is allowed in the event of a fatal error, which is allowed by default. In the event of a fatal error, retry should revert back to a previous task in the workflow. See the [Examples](#examples) section below for more information. `ErrorHandling` is a manual task and must be assigned to a group in order to run. ## Properties | Incoming | Description | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `severity` string (required) | The severity level must be one of the following values: `fatal`, `warning`, or `success`. | | `status` string (required) | The status is a string that should be indicative of the error state, and will be displayed to you. This could be the returned status code from a REST call, or a custom message you supply. | | `retry` boolean | Specifies whether retry is allowable in the event of a fatal error. Retry is `true` by default. | | Outgoing | Description | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | `response` | The task will output a variable called `response` which will have one of the following values: `success`, `failure`, `retry`, or `error`. | ### Severity level The severity level variable may be supplied statically or dynamically, but must be one of the following values: | Severity | Description | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `fatal` | A fatal error is one that would prevent the workflow from reaching completion. You will be prompted to either retry (if allowed) or abort the job. | | `warning` | A warning will alert you and allow you to proceed or abort the job. Use the warning level for non-critical failures that will not hinder the completion of the job, but which should be made known to you. The warning level can also be used for control flow, allowing you to continue down a given path with a warning or divert the job flow down another path if you choose to abort. | | `success` | Use this to confirm that a given task or series of tasks completed successfully. The severity level can also be supplied dynamically, and this severity level can be used as a check before proceeding down a given path. | ### Response The `ErrorHandling` task outputs a variable called `response`. This variable is especially useful when the severity level is provided dynamically, and the control flow of the job can be directed depending on the value. The response variable will be a string with one of the following values: | Response | Description | | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `success` | Indicates either a successful status, or that you have selected to proceed with a warning. | | `retry` | Indicates you have selected to retry. In this case the output should revert back to an earlier task in the workflow. | | `failure` | Indicates you have chosen to abort. | | `error` | This response is output when the severity level is supplied incorrectly, in the case that it is dynamically provided. This is a sanity check, and the response should never be an error. | ## Examples The following examples demonstrate various use cases for the `ErrorHandling` task. ### Revert to a previous task Upon entering a state of fatal error, you will be prompted to either retry (if allowed) or abort. It is a good idea to give yourself the option to retry and revert to a prior state. As mentioned in the previous section, the `response` variable output from the `ErrorHandling` task will have the value of `retry` if you have chosen to retry. ![](/_fern-img/2456b6991af66e7f4869796c499941699abfd1a78645eadb5dba0fa78a42bbd8.webp) To perform this check, place an evaluation task after the error handling task. ![](/_fern-img/b2517cc66d4ae24f5751cacea1498e525197da812f40b0f6c0bbce8745ff278f.webp) From here, add a success edge to revert back to a prior task in the workflow, and then add a failure edge connecting to the end point of the workflow. ![](/_fern-img/0dbf5713967745e3e6fbada763fb7b0b00a65476c4efcef165630279e18c2c99.webp) ### Direct control flow There are scenarios where you may wish to direct the flow of control, such as performing cleanup tasks after an error has occurred. The `ErrorHandling` task can be used to give you a warning, and then allow you to choose a path of execution. ![](/_fern-img/f873b513a0aaec262ea196c7a365abc92b4974edf6a3c702e4f6142ecadbfcb3.webp) The success path in this case would execute cleanup tasks, while the abort (failure) path would immediately end the job. ![](/_fern-img/53ed3555147f5c7ee599fb0d951531657f94729df20cac7ca1d3a7752f1a1f73.webp) ### Verify successful completion of a task The `success` severity level can be used to verify successful execution of a task or series of tasks. ![](/_fern-img/e7a2cfc9edceff4c745fcee5b0fd643b73c13a7eae3caa87e67c143dd3ed4b4c.webp) This is useful in scenarios where the severity level and status are dynamically supplied. ![](/_fern-img/14ba7773940f39ceafa98ac0104348fab8f452b586f02f0e4330e534e07af7bb.webp) ### Invalid input If invalid input is supplied to the `ErrorHandling` task, the task will output an error state with the following message. ![](/_fern-img/ad1c4aa9751790a60b859f256d1be5ba8b0a0cdd7b4c28cfd09532a98541db5b.webp) This is a failsafe in the event that the severity level is provided dynamically and does not match one of the allowable severity level types. > Use the ErrorHandling task to manage error severity levels and control workflow flow in response to fatal errors, warnings, or successful states.