What is the best way to handle exceptions in automated processes?

Defining exception types and scenarios is akin to crafting a detailed blueprint for automation. It's about anticipating hiccups in the journey, labeling them as system, data, or business issues, and assigning the right level of importance. With this map in hand, we build robust bots that navigate smoothly, armed with predefined solutions for any detours. It's like constructing a resilient bridge over the automation stream, ensuring seamless passage, no matter the obstacles.

Without taking account exceptions.. never gives you a solid business solution.? Exceptions will occur...try creating fake exceptions just for testing.

Defining specific exception types is essential to appropriately handle errors. For instance, retrying an action like login should be based on the nature of the exception. System-related exceptions may warrant retries, but retrying due to incorrect password input could cause additional issues. Hence, accurate exception categorization is vital for effective error management.

Engineer any important automation like a product. All exception types should have an automation ID (like a unique product id), an error code and a proper time stamp. In addition, the final user should be able to see a simplified version of them. I have seen too many automations where the final user can see that a workflow is not progressing but there is no way to know if it erred or not unless you open a support ticket.

I've been wondering if too many exception handlings couldn't be a signal of an inefficient workflow or bad code. I believe that we need to be careful while dealing with errors to avoid two situations: - General errors handling (like "except: pass") could hide non-known situations in the workflow. - Timing. If the task with an error is important, you'll only see this task again when it becomes a greater problem because your exception didn't deal with it properly. This being said, it's great when our code runs without interruptions and errors, but we can't see the error-handling process as just an "inconvenient" that we need to go over.

Exception handling logic is like equipping our bots with a reliable compass. We construct intricate decision trees, using try-catch structures, error codes, and adaptive pathways. It's the digital equivalent of giving our bots problem-solving skills - they encounter issues, pivot seamlessly, and provide valuable feedback. Exception handling isn't just code; it's the very essence of our bots' resilience and adaptability, ensuring they triumph over challenges in the automation landscape.

This is crucial. Because the process should be automated. If review and the number of a specific exception that is occurring constantly this needs to be taken care off. Otherwise we have an semi-automated process that always need the human to fix small issues.

The primary gap in the industry is often the lack of IT expertise among business analysts. Ideally, requirement gathering and analysis should be done by individuals with a strong IT background. However, it's frequently handled by business-focused personnel, potentially leading to poorly designed automation processes.

I work with Power Automate, and we have several automations that deal with Teams files, which need to be closed for the automations to work. Frequently, users don't close files and automations fail, so I like the idea of automating the error-handling response. I can send them an email that says "Close the file", and then I can direct them to a button in Teams to rerun the automation without having to reach out to our team.

Exceptions aren't always a bad thing. Exceptions can be a condition that falls outside of the scope for which the automation is allowed to act. Handling cases that exceed a certain threshold and therefore considered an exception is different from handling a user typing text in a number field. Proper exception handling needs to be designed based on the conditions that caused the exception.