You should to get rid of one of these error handlers... Within the same app is can get complex to predict which global error handler is in charge if multiple of em exist. But basically you could just rename one of it. Only the prefix 'Error' must exist for such a handler. The suffix can be freely chosen. Anyway the global handler is designed to be the last resort of failure handling after: 1. boundary error handlers 2. in process error handler 3. caller process error handler If one really want wants to handle/compensate an error appropriately it should be done as close as possible to where the error occurs. So the global handler can may be used to display a UI to the end user, or the generate mails to the administrator. But I really do not see any real use case to have multiple instance instances of it... In the `ErrorHandlingDemos` `ErrorHandlingDemos`, which are shipped as sample with Axon.ivy Designer there Designer, are some reasonable use cases that outline which make use of foreseen error handlers on multiple levels. ![alt text][1] ![alt text][2] [1]: https://answers.axonivy.com/upfiles/errorHandlingDemos.png [2]: https://answers.axonivy.com/upfiles/globalHandlerExample.png

You should to get rid of one of these error handlers... Within the same app is can get complex to predict which global error handler is in charge if multiple of em exist. But basically you could just rename one of it. Only the prefix 'Error' must exist for such a handler. The suffix can be freely chosen. Anyway the global handler is designed to be the last resort of failure handling after: 1. boundary error handlers 2. in process error handler 3. caller process error handler If one really want to handle/compensate an error appropriately it should be done as close as possible to where the error occurs. So the global handler can may be used to display a UI to the end user, or the generate mails to the administrator. But I really do not see any real use case to have multiple instance of it... In the `ErrorHandlingDemos` which are shipped as sample with Axon.ivy Designer there are some reasonable use cases outline which make use of error handlers on multiple levels. ![alt text][1] ![alt text][2] [1]: https://answers.axonivy.com/upfiles/errorHandlingDemos.pnghttps://answers.axonivy.com/upfiles/errorHandlingDemos.png [2]: https://answers.axonivy.com/upfiles/globalHandlerExample.png

You have should to get rid of one of these error handlers... There Within the same app is no way to have can get complex to predict which global error handler is in charge if multiple of em exist. But basically you could just rename one of it. Only the prefix 'Error' must exist for such handlers that live within the same app.a handler. The suffix can be freely chosen. Anyway the global handler is designed to be the last resort of failure handling after: 1. boundary error handlers 2. in process error handler 3. caller process error handler If one really want to handle/compensate an error appropriately it should be done as close as possible to where the error occurs. So the global handler can may be used to display a UI to the end user, or the generate mails to the administrator. But I really do not see any real use case to have multiple instance of it... In the `ErrorHandlingDemos` which are shipped as sample with Axon.ivy Designer there are some reasonable use cases outline which make use of error handlers on multiple levels. ![alt text][1] [1]: https://answers.axonivy.com/upfiles/errorHandlingDemos.png

You have to get rid of one of these error handlers... There is no way to have multiple such handlers that live within the same app. Anyway the global handler is designed to be the last resort of failure handling after: 1. boundary error handlers 2. in process error handler 3. caller process error handler If one really want to handle/compensate an error appropriately it should be done as close as possible to where the error occurs. So the global handler can may be used to display a UI to the end user, or the generate mails to the administrator. But I really do not see any real use case to have multiple instance of it... In the `ErrorHandlingDemos` which are shipped as sample with Axon.ivy Designer there are some reasonable use cases outline which make use of error handlers on multiple levels. ![alt text][1] [1]: https://answers.axonivy.com/upfiles/errorHandlingDemos.png