Error handlers

Introduction

You have reached the final unit of the Handling errors in Make course!

After incomplete executions, you will now explore another way to automatically handle errors in your scenario: error handlers.

You will learn:

• what error handlers are and how they work in a scenario
• the different error handlers in Make
• when you should use each error handler

This will be the finishing touch to your project.

Error handlers

Error handlers, or error handling directives, are modules you can add to your scenario to automatically manage errors in Make.

Unlike incomplete executions, which affect the behavior of the entire scenario, error handlers are connected to a specific module and run only when that module encounters an error.

In Make there are 5 different types of error handlers, each one impacting the bundle with the error and the scenario differently. You will learn more about them in this unit.

Arnold the Architect set up safety measures on his construction site to keep things running smoothly in case of issues. Instead of stopping everything, there are protocols to fix problems while keeping the project moving. If Will the Worker installs the wrong flooring, Arnold may pause that task but continue with the electrical work. These strategies prevent the renovation from stopping and keep Helen the Homeowner from losing hope.

Error handling route

You can connect an error handling route to almost any module of your scenario. It is a route, shown as empty dots, that runs only when the attached module encounters an error.

In this route you can have an error handler or modules that run only when an error occurs.

The error handling route can include the following options.

An Error Handler

To control how the scenario handles the error.

Ignore is one of the error handlers, you will learn more in the next pages.

One or More Modules

To perform specific actions when an error happens.

If the Google Sheets module encounters an error, the error handling route activates, and the second Google Sheets module runs to perform its action.

A Combination of Both

Where the error handling module is last: to perform specific actions and change the scenario’s behavior.

In case of a combination of error handlers and other modules, the error handler is the last module of the error handling route.

You will see examples and applications in the next pages.

The 5 directives

In Make there are 5 error handlers, also known as error handling directives:

• Break
• Commit
• Ignore
• Resume
• Rollback

Later in this unit, you will learn where to find them and how to add them to your scenario.

Let’s have a look at each of them, from the easiest to the most complex, starting with Break.

Break

Let’s start with Break.

What does Break do?

Break stops the run only for the bundle that caused the error. It saves the data and blueprint as an incomplete execution and lets the other bundles keep running.

This looks suspiciously similar to enabling incomplete executions, so what is the point of this error handler? Is there any difference from incomplete executions? Well, actually, there are plenty. Let’s have a look at them.

Remember that incomplete executions are like Arnold the Architect keeping a backup of the renovation plan and saving the bathroom tiles. In case there is a mistake, Will the Worker can check the plan and fix the mistake without restarting everything from the beginning. With Break, Will gets more control over when he fixes the bathroom issue before continuing with the rest of the renovation.

Why do I need it?

Incomplete executions automatically retry only temporary errors at defined intervals. While Break allows you more flexibility and you can customize it based on your needs.

This is what you can do with the Break error handler:

• You can automatically retry all types of errors, not just temporary ones.
• You can define the number of attempts and the interval between them. For example, you can set the number of attempts to 3 and the interval between attempts to 15 minutes.
• You can decide not to automatically retry temporary errors, but do it manually instead.
• You can save the run to incomplete executions only if the error happens in a specific module, not everywhere in the scenario.
• You can add one or more modules in the error handling route, to perform any action you want before the incomplete execution is saved.

What about the scenario?

In case of an error, the scenario is not deactivated. It will continue running, and Make will report the issue as a warning.

If the error happens in the second bundle, Make still processes the third bundle and any that come after it without issues.

Do you have any examples?

An API returns a Rate Limit error due to too many requests. The default waiting time in Make is 20 minutes, but since you know the API allows it, you can safely retry after just 1 minute. To handle this, add a Break to the HubSpot module and set it to retry the incomplete execution 3 times after 1 minute. This way, incomplete requests are retried sooner, avoiding unnecessary wait time.

For example: Google Sheets → HubSpot → Break (with “Retry after 1 minute” configured).

Ignore

The next error handler you will explore is Ignore.

What does Ignore do?

Ignore stops processing the bundle with the error. The scenario keeps running without interruptions and processes the remaining bundles.

The key point is that your scenario continues running smoothly, even if it means losing some data.

Since you can add modules to the error handling route, you can include one to keep track that a bundle was ignored due to an error, otherwise you will lose this information. You will learn how to do this in the use case.

Will notices a screw is missing while assembling the kitchen table, but he keeps going since it doesn’t affect the structure. Helen needs her table assembled!

What about the scenario?

If an error occurs, the scenario keeps running. Make won’t report it as a warning or error, and the scenario will finish with a success status.

If the error happens in the second bundle, Make still processes the third bundle and any that come after it without issues.

Do you have any examples?

Helen gets new supplier information from LinkedIn forms and adds it to her contact management software.

Sometimes, the email already exists, causing a Duplicate Error. To prevent the scenario from stopping, she adds an Ignore directive to skip duplicate entries.

Before the error handler skips the bundle, she sends herself a notification with the contact details, allowing her to check it later if needed.

The flow is: LinkedIn forms → HubSpot → Email (Send detail of bundle with error) → Ignore (Skip the bundle with error).

Resume

Time to have a look at Resume.

What does Resume do?

The Resume module lets you set a substitute value for a specific module’s output. If that module fails, the scenario continues using the substitute value in the next steps instead of stopping. This way, the scenario keeps running even after a failure, using the fallback value you specified.

You’re installing a new sink, but the specific pipe you ordered isn’t available. Instead of stopping work, you use an alternative pipe that fits just as well, keeping the project moving.

What about the scenario?

If an error occurs, the scenario keeps running. Make won’t report it as a warning or error, and the scenario will finish with a success status.

If the error happens in the second bundle, Make still processes the third bundle and any that come after it without issues.

Do you have any examples?

Susan stores supplier quotations for renovation materials in a spreadsheet and wants to be notified by email about new ones. She uses the email value in the Google Sheets to find the supplier’s name in Slack, then sends herself an email with the quotation details.

If the supplier is unknown, Slack fails to find the name, causing an error. To fix this, she adds a Resume directive to replace the Slack module’s output with custom values. Instead of the supplier’s name, she sets unknown user in the Resume module setup. The email module then processes the bundle and sends the email with unknown user instead of the name.

How does the substitute value work?

In the Resume module, you set the substitute value.

The Resume setup window shows the same items as the output of the module it’s attached to. For example, if it’s connected to a Slack → Search for user module that returns Name and Profile, you’ll see those same fields in the Resume module. And you can specify the substitute values for them.

The next module in the scenario, the Email module in this case, will use the Resume output if an error happens as if it was coming from the Slack module and no error happened, and keep processing the bundle.

Commit

The last two error handlers (Commit and Rollback) are more complex and you will learn more about them in the Advanced Webhook course. Let’s start to have a look at Commit for now.

Why are they complex?

Some modules in Make let you either confirm and apply changes or revert them after they have finished running. These modules are called ACID modules.

Commit and Rollback are more complex error handlers as they are linked to this capability.

Since they only work with ACID modules, their use is more limited than other directives. Still, it’s important to know they exist and how they affect your scenario.

What does Commit do?

Commit stops the scenario and confirms any changes to the ACID modules.

The bundle that generated the error is stopped and not processed through the remaining modules in the scenario. The next bundles are not processed.

Will is replacing the roof when he realizes he’s been laying the tiles upside down. He secures the tiles he’s already installed so rain won’t enter into Helen’s living room, and stops all work until he discusses the issue with Arnold.

What about the scenario?

In case of an error, the scenario is not deactivated. It will continue running, and Make will report the issue as a warning.

If an error occurs in the second bundle, Make stops processing any further bundles.

Do you have any examples?

Susan is giving away 10 discount vouchers to the first 10 architects who submit their orders. She receives a list of 250 orders, sorted by submission time.

Her scenario filters out invalid entries with missing information, adds winners to her data store, and sends confirmation emails.

If a step fails, she stops processing new entries to avoid awarding extra vouchers to people lower in the queue. As the data store is an ACID module, she uses Commit to ensure the processed data stays recorded.

Rollback

What does Rollback do?

Rollback stops the run and reverts all changes to the ACID modules. The bundle that caused the error doesn’t continue in the scenario, and Make doesn’t process any remaining bundles.

This is the default behavior of the scenario if no error handlers are present or if incomplete executions are enabled. Any changes in ACID modules are automatically reverted.

Why would you need an error handler, then? Good question! As soon as you add an error-handling route, the default behavior is overridden, meaning you must explicitly add this directive if you want to revert changes.

This time, when Will realizes he’s been laying the roof tiles upside down, he removes everything, so he can start over and lay the tiles as it should be done!

What about the scenario?

If an error occurs, the scenario stops. Make reverts the changes of the bundle up to the point of the error, but the bundle is not processed in the next modules of the scenario.

Note: that when you have a Rollback directive, the scenario will deactivate after it is triggered three consecutive times due to errors in the runs.

If an error occurs in the second bundle, Make stops processing any further bundles.

Do you have any examples?

Arnold is tracking new renovation requests in a Google spreadsheet. His scenario uses the Watch Rows trigger to pick up new requests and notify Will via Slack.

Since Watch Rows is an ACID module, if an error occurs, the changes rollback and aren’t confirmed. The same rows in the Google Sheet are picked up by the scenario next time.

By default, this happens automatically, but if Arnold also wants to be notified when Slack fails, he adds an error handling route to the Watch Rows module containing a Slack module to get notified about this and a Rollback directive to ensure the same rows are processed again.

Remember that when an error handling route is added, it overrides the default behavior. For this reason, when Arnold adds an error handling route to the Watch Rows module, the default Rollback behavior no longer applies, and changes will be confirmed. To roll back any changes, he needs to add a Rollback directive at the end of the route.

Recap

Now that you’ve seen all 5 error handlers in Make, time for a recap.

• Break
• Ignore
• Resume
• Commit
• Rollback

Error handlers vs incomplete executions

Susan the Supplier has a question: why use error handlers if you already have incomplete executions?

Great question Susan! Error handlers give you more control over how your scenario behaves compared to incomplete executions:

• They’re attached to specific modules and only run when an error happens in that module.
• They let you customize behavior differently than storing data in incomplete executions, giving you more flexibility based on the error type.
• You can add modules that perform specific actions in case of an error.
• You can add different error handlers to different modules, allowing each module to behave differently when an error occurs.
• You can use filters to apply different error handlers depending on the type of error (you will see this on the next pages).

Note: that when an error handler is present in the scenario, it overrides the default scenario behavior in case of an error. Even if incomplete executions are enabled, the error handler takes over, and incomplete executions won’t be saved (except for the Break error handler, as this is the behavior of this module).

Error handlers - When to use them?

Error handling directives do not consume any credits. This is very cool, but not a good enough reason to start using all of them in your scenario and on every module.

When deciding which error handler to use, keep in mind the following:

• how important is the data that the scenario processes?
• how important is it that the scenario keeps running?
• how important is it to obtain a result, even if an error occurs?

Break

Use Break when you want to retry the run and have more control over how to resolve incomplete executions.

Ignore

Use Ignore when you accept losing data but still want your scenario to keep running.

Resume

Use Resume when you want to obtain a result, even in case of an error, by substituting mock or default values. This ensures the scenario completes despite errors.

Commit

Use Commit when you have ACID modules in your scenario and want to confirm the changes made so far, while stopping the processing of any subsequent bundles. This locks in what has been processed before the error.

Rollback

Use Rollback when you have ACID modules and want to revert all the changes made up until the point of the error. It undoes any changes made by ACID modules, ensuring that none of their modifications are saved or committed.

Error handlers and filters

You can even mix and match error handlers to handle different situations in the same scenario. This means you can apply filters to the same modules and use different error handling directives based on the type of errors. Let’s have a look at an example.

Will has a scenario to track and get notified about new jobs from Arnold. When Arnold adds a new job to the Renovation spreadsheet, Will’s scenario detects the new row, transfers the relevant details to a Tasks spreadsheet, and sends himself an email to stay informed about the new task.

The Google Sheets module can generate errors, so Will wants to add error handlers to deal with them automatically.

The Google Sheet module can generate two types of errors: Data Errors and Connection Errors. Will wants to handle them differently, so he adds an error handling route containing a Router to the Google Sheets module.

The error handling route will run only if the Google Sheets module encounters an error. Will then uses filters to define different behaviors for each type of error:

• 1st route: Data Error
• 2nd route: Connection Error

Note: If the Google Sheets module outputs a different type of error, it won’t be processed by any route. You could add more routes or a fallback route to handle other error types.

Handling Data Errors

Every time a module generates an error, its output includes an Error: Type item that specifies the error type. This can be used to filter errors based on their type.

In this case, the first route filters all Data Errors. The filter is set up using the Error: Type item with the condition Error: Type Text operator: Equal to DataError.

The route for handling Data Errors includes an Ignore error handler, which stops processing the bundle and doesn’t stop the scenario. Since the data about the bundle will be lost, Will adds an Email module to get notified about the issue. The Email module sends an email to s.dogg@make.com with the subject “Issue with a record (Data Error)” and content “There was an issue with row <row_variable>. Please check - Data was not added.”

Handling Connection Errors

The second route uses the Error: Type item to filter the Connection Errors, with the condition Error: Type Text operator: Equal to ConnectionError.

A Connection Error is a temporary error that can be fixed by retrying the run after some time. To handle this, Will adds a Break directive to the route, saving the errored bundle as an incomplete execution and setting it to automatically retry 3 times every 15 minutes.

Testing time

After all of this theory, it is time to see the error handlers in action. You will use the parent and the child scenarios you built in unit 2 and the Ignore error handler. You will test the directive in the child scenario, on its own and also by adding an extra module in the error handling route.

Just Ignore

Add the Ignore directive to the Google Sheets module that generates an error. This will stop any bundle that causes an error from the scenario, and the remaining bundles will be processed normally.

Extra module

With the Ignore error handler, you lose the information of the bundle that caused the error. To keep track of it, create an extra sheet in the MI_C05_U02_workers spreadsheet to record error details. Then, add a Google Sheets → Add a row module in the error handling route to store the error information.

Remember that the error handler is always at the end of the route.

Use it - Ignore

Let’s start by creating the error handling route, add Ignore and analyze the scenario behavior.

Open the MI_C05_U02_child scenario. The module that generates the error is the Google Sheets module, so let’s add the error handling directive to it. Right-click the module and select Add error handler. An error handling route (with transparent dots) is added where you can add modules or error handlers that run only in case of an error in the Google Sheets module.

Add the Ignore directive. You don’t need to configure anything for this module. Save your scenario and make sure it is ON.

Note: You don’t have to set incomplete executions to off, as they are overridden by the error handler.

To run the scenarios, go to the MI_C05_U02_parent scenario. This scenario has a flow of Google Sheets → Array aggregator → Scenarios. Right-click the Google Sheets module. In the pop up, select All under Choose where to start, then click Save. Click Run once and observe the parent scenario running.

Let’s check the child scenario, the spreadsheet and the inbox, to see what happened during the run. Start with the child scenario. In its History, you’ll notice a Success status. If you open the run details, you’ll see a warning sign next to the Google Sheets module in the logs. Clicking it reveals more details about the warning. Here, you can see that something went wrong with the run, but the information about the bundle with the error is otherwise lost.

In the MI_C05_U02_workers spreadsheet, you’ll see two rows corresponding to bundle 1 and bundle 3. As expected, the scenario skipped bundle 2 with the error and continued running. The scenario is still active and processed the third bundle (Paint). Delete all the rows for the next tests. In your inbox, you have two email confirmations corresponding to these two rows. You could completely miss the information that the second bundle had an issue. Let’s add evidence to show it.

Extra module - Ignore

Let’s add a module that keeps track of the bundle that generated the error. Work through each stage before you continue.

You will record both the information about the bundle that generated the error and the error in a separate sheet of the workers Google Sheet. To do so, open the MI_C05_U02_workers spreadsheet and add a new sheet. Name it Errors. Copy and paste the columns names into the first row. It should look like the one in the image.

You will add a Google Sheets → Add a row module in the error handling route to record the information about the bundle and the error in the Errors sheet. To do so, go to the MI_C05_U02_child scenario. Right-click the error handling route and select Add a module. Then, add a Google Sheets → Add a row module.

The connection is already set up. Select MI_C05_U02_workers under Spreadsheet ID, and Errors under Sheet Name.

Under Date, you want to record the date when the error happened. To do this, use the now item and the formatDate() function to format it as DD-MM-YYYY. Type formatDate( map the now item, then complete the function by typing ;DD-MM-YYYY).

formatDate(date; format; [timezone])

Returns a date in the requested format and optionally, in a specified timezone. For example, format DD.MM.YYYY HH:mm

Under Error type map the Error: Type item from the Google Sheets module.

Under Object, you have to include the information of the bundle that failed. To do so, copy and paste the following information and map the corresponding items from the Iterator module: Item: [map Item from the Iterator] Supplier: [map Supplier from the Iterator] Quantity: [map Quantity from the Iterator] Price: [map Price from the Iterator]

Under Error message map the Error: Message item from the Google Sheets module and click Save. Finally save your scenario.

Let’s run it. Make sure the child scenario is ON and go to the MI_C05_U02_parent scenario. Right click the Google Sheets module. In the pop up, select All under Choose where to start, then click Save. Click Run once and observe the parent scenario running.

Go to the MI_C05_U02_workers spreadsheet and check the Errors tab. You should see the details of the second bundle. Great! You didn’t lose any data, and your scenario keeps running. That’s all for now!

Wrap up

Error handlers are modules that automatically manage errors in Make. Unlike incomplete executions, you attach them to a specific module and run only when that module fails. Make offers five types of error handlers (Break, Ignore, Resume, Commit, and Rollback), each affecting the errored bundle and scenario differently.

An error handling route connects to a module in your scenario and runs only if that module fails. It appears as empty dots and can include an error handler or modules that execute when an error happens.

Error handling directives don’t use credits and override the default behavior and incomplete execution settings. If you decide to use them, choose wisely to match your scenario’s needs.