Academy

Unit 3 · Make Intermediate: Errors

Incomplete executions

18 min read Updated May 21, 2026

Introduction

Welcome to the third unit of the Handling Errors in Make course.

In the previous unit, you created a scenario with an error. Now it’s time to learn how to fix it.

In this unit you will learn:

  • how Make stores data from your scenario runs
  • what incomplete executions are
  • how you can use incomplete executions to automatically handle errors

Sounds exciting, right?

Errors and data loss

In the previous unit, you saw how a scenario behaves when an error occurs. Do you remember what happens to the bundle that caused the error? And the bundles after it?

If you said they are not processed, great job! The biggest risk here is losing this data.

If you want to process it again, you will have to resend the data to the scenario. For sure there must be a clever way to handle this, right? Actually, there is. And you’re about to learn it on the next pages.

You will discover how to automatically capture errors without stopping your scenario or losing any data. Mind blowing, right?

Will is assembling a wooden staircase, when he realizes that the size of the first step is wrong. He stops the construction, and since he can’t proceed, he throws away the incorrect step and all the following ones. If Arnold the Architect doesn’t do anything, there will be no steps left, and Helen the Homeowner will end up with no staircase at all.

Log

To understand how to handle possible data loss, it’s important to know how Make manages processed data.

When you run a scenario, Make saves the following data in the log:

  • input data (for each module)
  • output data (for each module)
  • execution details (date of execution, duration, etc)

Arnold carefully saves in his notebook every step of the renovation: the materials, the work completed, and how long each job took. You wouldn’t have expected Arnold to be this organized, right?

This helps identify what went wrong, but it’s not enough to rerun your scenario.

Note: that if your data is confidential you can tell Make not to save it. This way, only time and durations of the run are recorded, ensuring that none of your data is stored by Make. You will learn more about this later in the unit.

Blueprint

A blueprint is a document that contains the configuration of the modules and settings of your scenario. You can use the blueprint to share your scenario with others, allowing them to configure and run it with their own connections and data.

The blueprint is what you need to rerun your data! Make saves the data that wasn’t processed, but not the blueprint. Without the blueprint, you can’t be sure how the scenario was set up when the data was first processed. To reprocess data, you need the blueprint to understand the scenario’s setup.

Will has all the materials for the renovation, but he still needs the plan to be sure of what he’s supposed to do. Without it, he might tear down the bathroom wall, not knowing that Arnold changed the plan after realizing a bathroom actually needs walls.

Will’s Questions

Why do you need the blueprint if you have the original scenario? You can make changes to the scenario, and you can’t be sure that the current version of the scenario is the same as the one that processed your data when the error occurred. The blueprint represents the exact scenario settings and configuration at the time of the error.

Why isn’t the blueprint saved together with the logs by default? The blueprint contains a lot of information. It includes every single detail about the settings of the modules, and in some cases, it can be very long. Some modules have a lot of settings you can specify and you have been building quite small scenarios, but imagine a scenario with 15 modules. The blueprint would be too big and require too much space to save it automatically. For this reason, Make decided not to save them by default. #smart

Incomplete executions

Incomplete executions are a feature in Make that allows you to save the data and the blueprint from a failed run. This allows you to rerun it, preventing loss of information.

When incomplete executions are enabled, if an error happens in your scenario, Make saves both the scenario’s blueprint at the time of the error and the log details. These include the module’s settings, input, and output data up to the failed module.

With this saved data, you can investigate the run and figure out what went wrong. You can decide to retry the run from the failed module. You can also adjust the setup of the module that failed and the next ones if needed, without changing the original scenario.

Incomplete executions are not enabled by default, but you can turn them on in the Scenario settings menu. Once enabled, any unfinished run will appear in the Incomplete executions tab. Like seatbelts on a plane, Make recommends keeping incomplete executions ON all the time. This ensures that if something goes wrong, all data from your runs is captured, giving you the option to reprocess it if needed.

Arnold keeps a backup of the renovation plan and doesn’t throw away all the materials when something goes wrong. If Will tiles the bathroom wall incorrectly, he can stop, check the plan, reuse the tiles, and fix the mistake without starting everything from scratch.

If the error occurs in the first module of the scenario, Make doesn’t save any incomplete executions. Since the scenario didn’t process any data or generate any output, there isn’t anything to save. If you need to reprocess the data, you will have to rerun the scenario entirely. For this reason, saving the incomplete execution wouldn’t provide any benefit, and Make doesn’t do it. #efficient

Warnings

With incomplete executions, Make generates a warning instead of an error.

A warning indicates that an event needs your attention, but isn’t serious enough to stop the scenario. It is less critical than an error. When you have a warning, the scenario keeps running without being deactivated.

This happens because the information from the run that caused the error is saved, not lost, and you can retrieve it later. Since the situation isn’t critical, you receive a warning instead of an error.

It’s like Will noticing a small mistake in the renovation, like a small crack on a wall. It’s not serious enough to stop the whole project, so he texts Arnold about this and keeps going. He can fix the crack later for sure.

Make notifies you of a warning in three ways:

An email alerting you about the warning.

Make sends an email to alert you about a warning. This email will specify the scenario name and provide details about the warning, such as “Failed to map data.Price: function ‘cell’ finished with error! ‘123e63’ is not a valid number.”

A warning status in the scenario history.

In the scenario history, you will see a “Warning” status for the execution that encountered the issue.

A warning sign next to the module in the scenario history.

A warning sign (a yellow triangle with an exclamation mark) will appear next to the specific module in the scenario history that generated the warning, for example, a Google Sheets module.

Impact of incomplete executions

Let’s continue exploring incomplete executions.

What happens to my scenario when I have incomplete executions enabled?

In case of an error, the scenario is never paused, hooray! It will continue running, and Make will log the issue as a warning.

What happens to the bundles after the one that generated the error?

They keep running! If an error happens in the second bundle, the third bundle continues as if nothing occurred.

What are the advantages of incomplete executions?

  • The scenario continues running even if an error occurs.
  • The data of the current bundle is not lost; it’s saved in the incomplete executions, allowing you to retry it.
  • The next bundles are unaffected and are processed as usual.

Resolve incomplete executions

Incomplete executions save all information needed to retry a failed run from the exact point of failure. Once an incomplete execution runs successfully, it is resolved. You can retry the run in different ways or choose to delete it.

Automatic retry

Some errors are temporary and resolve by simply waiting before retrying the scenario. For example, a Rate Limit Error happens when you exceed the API call limits. After a set waiting period, you’ll be able to make calls again. Other temporary errors include Connection Errors and Module Timeout Errors.

When a temporary error occurs, Make automatically retries the incomplete executions at set intervals. This means attempting to run the scenario again from the failed module with the same settings, without any changes. Nothing for you to do here, just make sure that the scenario is active, and Make will handle the rest.

If the retry works, Make marks the execution as Resolved and stops retrying. If it still fails after a certain number of attempts, Make marks it as Unresolved. You can retry it manually.

Will tries to paint, but the wall is still wet. Instead of giving up, he waits a bit and tries again later.

Manual retry

Some errors can’t be fixed by simply retrying the run as it is. For example, a Data Error occurs when the data you’re sending is incorrect. You can retry it as many times as you want, but this won’t solve the issue.

To fix this, you need to correct the data. This means manually inputting the right data or mapping values from another source.

Incomplete executions let you do this. You can manually modify the value that caused the error, and then rerun the scenario. You’ll learn how to do this in the use case.

Susan the Supplier orders light fixtures with incorrect wiring settings. Will has to pause the electrical work while she adjusts the fixtures to match the room’s wiring. Once fixed, Will can continue, and Helen can breathe a sigh of relief.

Bulk retry

Imagine you ran out of credits in a third-party application or an API was unavailable for a few hours/days. Once the issue is fixed, because you bought more credits or the API is back online, you will find yourself with a bunch of incomplete executions that you want to run all at once.

You want to retry all of these incomplete executions together. Make has got you covered! You can use bulk retry to do so.

Think of Will drilling holes in multiple rooms. If the drill breaks down, he has to pause, and all the work accumulates. Once the drill is fixed, he can finish drilling away all the rooms, without changing the original drilling plan.

Note: that you can’t modify the blueprint in that case, only retry all the executions at the same time.

Delete

You’re not interested in retrying an incomplete execution, maybe because you’ve already resent and processed the data. In this case, you don’t need to reprocess the incomplete execution, and you can delete it.

Will kept the wood planks he first ordered for Helen’s house, but after measuring, he realized they were too short. He has now ordered the right, longer planks, so he can throw away the incorrect ones since they’re no longer needed.

Note: that once you delete an incomplete execution, you cannot restore it.

Incomplete executions tab

Let’s explore the incomplete executions tab. To open it, select your scenario and switch from the Diagram tab to the Incomplete executions tab.

Here are the elements you’ll find in the Incomplete executions tab:

  • Check box: Use it to select your incomplete execution for retrying or deleting.
  • #: A unique string that Make generates to identify the incomplete execution.
  • Created: The date and time when Make created the incomplete execution.
  • Size: The size of the blueprint and the data.

Status

These are the possible statuses for incomplete executions:

  • Unresolved: The incomplete execution is saved, but you haven’t retried it, and it is not scheduled for automatic retry.

  • Pending: The incomplete execution is scheduled for automatic retry.

  • In progress: Make is currently retrying the incomplete execution.

  • Resolved: The incomplete execution was successfully retried (automatically or by the user) and the scenario reprocessed the data without errors. Make will automatically delete resolved incomplete executions after 30 days.

  • Scheduled in: Time left until Make automatically retries the incomplete execution.

  • Attempts: The number of times the incomplete execution was retried (automatically or by the user).

Detail

The Detail button opens the scenario editor for the specific incomplete execution, where you can modify the settings and rerun the incomplete execution. You will do this in this use case.

Scenario settings

In the Scenario settings you can find different options that influence the incomplete execution storage and processing.

Sequential processing

Sequential processing determines whether the bundles have to be processed in the order they are received. You will learn more about this in the Advanced Webhooks course. Regarding incomplete executions, here’s how this setting affects them:

  • Choose Yes if you want to process the bundles in the order in which they are received. If a bundle generates an error and is saved as an incomplete execution, the scenario pauses until it’s resolved. No further bundles are processed. Choose this option if you want to process the bundles in the order in which they occurred.
  • Choose No if you are not interested in the order in which Make processes the bundles. The scenario keeps running and processes new data, while incomplete executions can be resolved later. Choose this option if you are not interested in the order in which Make processes the bundles.

Data is confidential

If you set Data is confidential to Yes, Make doesn’t store any input or output information. This means that Make won’t save any failed run in incomplete executions, and you won’t be able to reprocess the data if something goes wrong.

  • Choose Yes if you don’t want Make to save your data. Be aware that if you choose yes, you cannot save incomplete executions.
  • Choose No if your data is not confidential and you’re happy with Make to save the output. When No is selected, Make can save the incomplete executions.

Note: When your data is stored, it’s encrypted by Make, and kept 30 days (60 days for the Enterprise plan).

Allow storing of Incomplete Executions

This is the option that you need to select if you want to store the incomplete executions of your scenario. Every organization has a maximum data size for storing the incomplete executions, based on its plan. The Enable data loss setting lets you choose what happens when this storage is full:

  • Choose Yes if you want to store incomplete executions in case of an error. If you are more interested in keeping the scenario running, even at the cost of losing data. The scenario keeps running, but new incomplete executions are not saved since they can’t be stored.
  • Choose No if you don’t want to store incomplete executions in case of an error. If preventing data loss is the priority. Since new incomplete executions cannot be saved and you have chosen not to lose data, Make disables the scenario. You will need to resolve existing incomplete executions to free up space before reactivating the scenario again.

Note: By default the storing of Incomplete Executions is set to No.

Let’s test it

Now that you know more about incomplete executions it’s time to test them in the scenario you created in Unit 2. If you haven’t created it yet, go back to Unit 2 and do so.

To enable the incomplete execution, go to the MI_C05_U02_child scenario and open the Scenario settings.

Set Allow storing of Incomplete Executions to Yes so you will be able to see incomplete executions in action and test them in your scenario. Leave all the other options as default.

Click OK to save the setting, then save the scenario. Make sure the scenario is active.

All set. Let’s test it out!

Run it!

Now that you have enabled the storage of incomplete executions, it’s time to run the scenario and observe its behavior. Work through each stage before you continue.

Before running the scenario, double check that everything is ready:

  • You enabled the incomplete executions in the MI_C05_U02_child scenario.
  • The child scenario is ON and set as On demand.
  • You deleted all the rows in the MI_C05_U02_workers spreadsheet.
  • The MI_C05_U02_architect spreadsheet contains a letter in the price of the second item (Pipes).

To run the scenarios, go to the MI_C05_U02_parent scenario and right-click the Google Sheets module. In the pop-up, click Choose where to start and select All, 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 Warning status. If you open the run details, you’ll see a warning sign next to the Google Sheets module. Clicking it reveals more details about the warning. It informs you that Make saved the run as an incomplete execution, and you can resolve it. Before doing so, let’s finish analyzing this run.

In the MI_C05_U02_workers spreadsheet, you’ll see two rows corresponding to bundle 1 and bundle 3. As expected, the scenario didn’t stop when it encountered an error in the second bundle. It still processed the third bundle (Paint), and you didn’t lose any data. Pretty cool these incomplete executions, right?

In your inbox, you’ll find two emails confirming that the scenario processed bundles 1 and 3, along with a warning email if you have enabled the notification emails in your organization. The warning email notifies you about the issue with the second bundle. The email doesn’t inform you that you can have an incomplete execution that you can resolve. You’ll have to check your scenario manually.

Let’s go do that now.

Resolve it!

After running the scenario in the previous step, you now have an incomplete execution to resolve. Let’s do it. Work through each stage before you continue.

Go to the incomplete execution tab of the child scenario and check the Unresolved incomplete execution from the previous run. Click Details to open it, then click the scenario image to access it. Here, open the Google Sheets module. You can modify the mapping or adjust the item values before Make processes them.

The invalid number in the price field caused the error. Replace the mapping by typing the value 125.63 inside the ceil() function. This makes it a valid number. Save the module configuration. Click Run once. In the pop up that appears, select Continue without changes. You don’t need to modify the scenario inputs, as you have manually updated the value in the Google Sheets module. Notice that your attempts has a success status. The Google Sheets module will still have an error sign.

If you go back to the Incomplete executions tab, notice that the incomplete execution is now Resolved. Well done! You have resolved your first incomplete execution! Let’s have a look at the spreadsheet and the email now.

In the MI_C05_U02_workers spreadsheet, you’ll see a new row for Pipes. This is the row that generated the error. After you changed the data, the scenario was able to process it correctly.

Note: The order of the elements is different from the order in which you sent them. Pipes is now the last element, not the second. The scenario processes all the bundles without errors. Once the run finishes, you can manually resolve any incomplete executions. In this case, the output of that bundle will be processed later, just like in the example where the Pipes appears in the last row in the spreadsheet.

If you want the bundles to be processed in the same order they are received, select Yes for Sequential processing in the Scenario settings, as shown earlier.

As expected, you’ve received an email notifying you that the scenario added a new bundle to the spreadsheet. That’s all you need to know about manually retrying an incomplete execution. Delete all the rows from the MI_C05_U02_workers spreadsheet to have it ready for the tests in the next unit.

Wrap up

To reprocess a failed run, you need the data along with the scenario blueprint. The scenario blueprint contains information about the modules and their settings. Make doesn’t save it by default.

Incomplete executions save data and blueprint from a failed run, so you can retry it without losing any information. The scenario keeps running even if an error happens, and the next bundles are processed as usual.

You can resolve an incomplete execution in different ways. Make automatically retries executions caused by temporary errors, or you can manually retry and adjust any data that caused the issue. Additionally, you can bulk retry incomplete executions without changing any settings or delete them if they are no longer needed.