Handling and notifying errors

See also:
How to run actions when a condition is met
Sending an email

Email Parser processes incoming emails automatically, but things do not always go as expected. A parser might fail to extract a field, a database might be temporarily unavailable, or an HTTP request to an external API might return an error. When any of these situations occur, Email Parser logs the problem in the activity log and in the email history, but it does not send any notification on its own. Your workflow simply continues along the defined arrows without alerting you to the problem.

This page explains how to extend your workflow to detect these unexpected situations and get notified automatically when something goes wrong.

The two key actions for error handling

Error handling in Email Parser relies on combining two actions:

• Bifurcator: This action evaluates a condition and routes the workflow in one of two directions. The green path is followed when the condition is met, and the red path is followed when it is not. You use this action to check whether something worked as expected or whether an error occurred.
• Send email: This action sends an email. You place it at the end of the error path to notify yourself (or your team) whenever a problem is detected.

The image below shows a straightforward example of this pattern. A Bifurcator checks whether a temperature reading exceeds a threshold, and if it does, an email notification is sent automatically. Although this particular example is not strictly an error scenario, it illustrates the core pattern that applies to all kinds of error detection: a condition is evaluated, and if the result is unexpected, an email is sent.

Detecting parsing errors

When Email Parser fails to parse a field, that field is left empty. In some cases this is acceptable, since certain fields may not always be present in every incoming email. However, if a field is required for your workflow to function correctly, an empty field is an error that you need to detect and handle.

The way to detect a parsing failure is straightforward: add a Bifurcator action after the parser step and configure it to check whether the field you care about contains any value at all. The condition “this field expression <%fieldname%> contains anything” will be true if parsing succeeded, and false if parsing failed. In the example below, the Bifurcator is configured to verify that the temperature field was captured correctly:

You can chain multiple Bifurcator actions together when you need to validate several fields. The image below shows a complete workflow where two fields (temperature and pressure) are each checked in sequence. If either field is missing, the workflow takes the error path and a notification email is sent automatically. If both fields are present, the workflow continues normally, builds the mailing list, and sends the reading to subscribers.

Notice how both red (failure) paths from the two Bifurcators converge and lead to the same “Send error message” action. This is a useful pattern when you have multiple checks: any single failure is enough to trigger the notification, and you only need one error email action in your workflow instead of one per check.

Detecting errors in actions

Actions that interact with external services, such as database queries, HTTP requests, or file operations, can fail for a variety of reasons: the external service might be temporarily unavailable, a network connection might time out, or the request might be rejected due to invalid data. When an action fails, Email Parser captures whatever output the action returned and makes it available as “the previous action output.” Many actions include descriptive text such as “error” in their output when something goes wrong.

To detect these failures, place a Bifurcator action immediately after the action you want to monitor, and configure it to check whether “the previous action output contains the text error” (or whatever specific text your action returns on failure). The image below shows an example where a Bifurcator is placed right after a MySQL database action to check whether the database operation completed successfully:

In this example, if the database action fails, the Bifurcator routes the workflow to a “Send error found when adding data to database” email action, immediately alerting the relevant team. You can adapt this same pattern to any action in your workflow. The key is to know what text your specific action includes in its output when something goes wrong. You can find this out by checking the activity log after a failed run.

Getting notified

Once the Bifurcator detects an error condition and routes the workflow to the error path, the most common and practical response is to send yourself a notification email. Place a Send email action at the end of the error path and configure it with a clear subject line and a body that provides enough context to quickly understand what went wrong. Email Parser field expressions like <%From%>, <%DateTimeSent%>, and <%Subject%> are available in the email body, so you can include details from the original email that triggered the error.

In the example above, the notification email is sent to support@emailparser.com with the subject “Failed email parsing. Check Email Parser settings” and a body that includes the date and time the original email was sent as well as the sender’s address. This gives you the information you need to locate the original email and investigate the problem quickly. You can add even more context by including other field expressions, such as the parsed values that were available at the time, or the original email subject.

Apart from sending an email, you can also take other actions when an error is detected. For example, you could move the email to a dedicated error folder for later review, or log the error details to a spreadsheet or database for tracking purposes over time.