Advanced error handling
This article covers some advanced error handling techniques that involve filtering and nesting.
Filtering
There are 2 kinds of filtering that can take place on an error handler route:
1) Adding a filter to the error handler route
You can use a filter to control which errors are handled by the error handler route. This allows you to process only specific types of errors. If an error does not pass through the filter, it will be treated as if there is no error handler route defined for the given module.

2) Adding a Router followed by filters to the error handler route

As you can see above, the error takes place at the Create a folder module (A), which has a regular route and an error handler route. The latter is followed by a router with one route that has a filter that defines a specific type of error (Data Error Takes Place), and the other which is the default route for all other errors. The first route ends with the Resume directive which contains substitute values for the Action Flow to resume from module A (Create a folder) , while the second route ends with the Rollback directive which stops the Action Flow execution immediately.
See the Error processing section for further information on various error types and on how Celonis platform processes and evaluates them.
Nesting
Regardless of where a module is located, error handler routes can be created and implemented on all modules, except routers. Thus, it is possible to create an error handler route for a module that is already part of an existing error handler route created for another module.
Here's an example of a nested error handler route:
![]() |
In the above Action Flow, the second error handler route is nested under the first error handler route. So, if the Dropbox > Create a folder module encounters an error, the execution moves to Route 1, if the Data Error Takes Place filter is passed, the next module is executed followed by the Resume directive module if an error does not take place with the Dropbox > List all files/subfolders in a folder module.
However, if an error does take place with this Dropbox module, then the execution moves to Error Handler Route 2 and ends with the Ignore directive. It is obvious that the Resume directive module is not executed in this case.
That is a combination of filtering and nesting error handlers.
