Did you know that 50% of the integration design should go into planning how the exceptions are handled? This 50% will define how successful your business automation processes are built, so setting up the process for exception handling becomes very crucial!
Exception handling ensures that the flow of the business process doesn't break when an exception happens. An exception can be some missing or corrupted data, for example, occurring during the execution of a manual task automation. For instance, if you have automated an invoicing process in your company, and, a reference number in one of the invoices is missing, the automation flow will not break down, instead an exception and an error log will be thrown to your administrator.
When exception handling mechanisms are in place, they ensure that problems can be automatically resolved if possible, or easily tracked, identified and resolved by system administrators.
There are several kinds of exception situations:
- Technical when, e.g. the source interface timeouts.
- Logical when, e.g. the source material contains surprises or business rules that are exceeded.
- Silent exception, an error case, when, e.g. no one is sending anything.
What Frends can do to mitigate these problems?
1. Tech Failures Fixable With Retries
To mitigate technical failures fixable with retries the obvious solution is to configure failing tasks to automatically retry a specified number of times before actually going into an exception state. This approach will usually solve most issues where the problem can be avoided by simply re-running the failed step in the integration:
2. Tech Failures: Not-Fixable With Retries
These types of errors will not “fix-themselves” no matter how many times you try to retry the failing part of the integration.
So, in this case of a specific task failing due to incorrect credentials or otherwise changed configuration such as updated interfaces or APIs, the only real option is to identify the error situation and raise an alert and apply a fix to the problematic area:
3. Process Failures
Sometimes you might want to end a process in a failure by design and possibly raising an alert in these situations. This typically means that you are expecting some data or functionality to behave in a certain way and when it doesn’t, you stop the process and raise an error. A good example of such a use case could be, for example, a database query returning no values matching your search criteria or receiving too many values:
4. Tech Failures With a Backup Plan
In some cases you might have a situation in which if a task fails, you want to try an alternative approach such as using a Staging Database instead of Production, if the Production database is down. In these situations you can catch the error like in Tech Failures: Not-Fixable With Retries, but instead of sending an alert you want to preform a compensatory action and still resume the process:
5. Erroneous Data
In many cases, the most common exception situations are those where the data you are processing is faulty or incorrect in some way. The most efficient ways to mitigate this is to implement your low-code references with nullable operators and default values, or to validate your data before processing and raise an alert is the data is incorrect:
6. Silence Monitoring Errors
You might experience situations where the integrations themselves are working as they should and no exceptions are present, but the underlining use-case is still not being fulfilled. These typically mean that you for e.g. process incoming orders as files, but do not receive any orders meaning there is nothing to fail in the integration. Here we should use Monitoring Rules to our advantage to detect situations where the error is, why nothing happens or something happens too much or takes too long:
Watch the webinar: Exception Handling in Process Automation: Patterns, Scenarios, and Solutions
Watch the webinar: How to create Human Interaction processes in Business Process Automation