Generate an error

Introduction

Welcome to the second unit of the Handling errors in Make course!

Time to add another brick to your error knowledge. In this unit you will:

build a use case that generates an error
study the behavior of the run when an error is present
learn how to trigger a scenario from another scenario in Make

Time to get to work!

Failure is all you need

Fail again. Fail better. As architect Samuel Beckett wisely said.

In this unit, you’ll take his advice and build a scenario that generates an error. A scenario designed to fail! You’ll watch a run go wrong, see how it behaves, and learn how to spot errors.

It doesn’t sound very exciting for now, but in the next units you’ll use this scenario to explore ways of dealing with errors in Make.

It’s like asking Will the Worker to please make a big crack on your wall, or lay the tiles all wonky. Just to see Helen the Homeowner’s reaction. A bit cruel, but that’s life. Don’t worry, in the next units you will help her to deal with this.

Stay tuned for the cool part!

Use case

For this use case, imagine Arnold the Architect needs to share the list of supplies to order for the renovation project with Will. Arnold keeps all the details in a Google Sheet, and uses a scenario (scenario A) to send the information.

Will collects the information from Arnold, stores it in his own Google Sheet, and emails Susan the Supplier with the order details. He does this using a scenario (scenario B).

When saving the data, Will rounds up the price, since he’s not interested in decimals. If the price Arnold provides isn’t a number, this will trigger the error you’re so interested in!

You will use the ceil() function to round the price and generate the error. This function expects a number, but if you pass a string, it tries to convert it to a number first. If the string is not a valid number (it contains letters for example), it will generate an error.

Definition: ceil (number) <integer> Returns the smallest integer greater than or equal to a specified number.

Examples: ceil ( 1.2 ) = 2 ceil ( 4 ) = 4

Two scenarios

You have probably noticed that the use case involves two scenarios, with scenario A triggering scenario B and sending the processed data.

You need this setup because you want scenario B to fail on demand (when scenario A calls it) to be able to study the error behavior.

In this case scenario A will share the data with the invalid format, causing scenario B to fail when it tries to round it. You will use this in the next units, where you will learn how to handle errors automatically in Make.

Note: In this case data from scenario A, such as the order information, is passed to scenario B. Scenario B further processes it, by adding it to the Google Sheet and sending it via email.

Triggering a scenario from another scenario - why?

In real life, there are situations where you may want one scenario to trigger another. Let’s find out why you would want to do this.

Remember that when you trigger a scenario you can pass the data processed by scenario A to scenario B, enabling it to be further processed.

Avoid duplications

If you have multiple scenarios that need to perform the same actions, you have two options. You can either duplicate the same modules across all scenarios, or you can create one scenario that handles the common tasks. Then, you can have the other scenarios trigger this one when needed.

Imagine that Arnold is managing the ordering process for materials. He has several scenarios: one for ordering cement, one for ordering tiles, and one for ordering paint. Each scenario goes through the same steps: it checks the inventory, calculates the total cost, and sends an email to Susan for approval. Instead of repeating all these steps in each scenario, Arnold creates one central scenario that handles the entire process. Then, each of the material-ordering scenarios triggers this central scenario whenever necessary, avoiding duplication.

Make scenarios simpler

Having one scenario trigger another makes it easier to create smaller and simpler scenarios. This is helpful because when you need to make changes, you can adjust the smaller scenario without having to change others. This approach makes your scenarios easier to maintain. Maintaining a scenario means making updates or improvements as necessary, such as changing an email address or adjusting the data mapping in a module.

Will can do all the work himself: layering the bricks, wiring the house, putting pipes in the toilet. Getting tired, stressed, and not doing a very good job. Or he can hire Billy the Brick man, Elisa the Electrician, and Pamela the Plumber. All the tasks are easier to manage, and the result is not that bad. Will will report the progress of the works to Arnold. If Arnold changes his phone number, he simply needs to notify Will.

Provide services

If you want to provide a service that multiple sources can access, create a scenario that performs a specific task. Whenever a third-party needs to perform this task, it triggers the scenario. This setup allows different scenarios to rely on the same service without duplicating the action each time.

Susan the Supplier, has a scenario set up to handle all the ordering processes for the renovation projects. The scenario checks the inventory, organizes shipping, and sends the invoice along with the delivery date. Whenever any of the architects she works with needs to place an order, they can trigger the same scenario. This way, Susan’s scenario becomes a reusable service that multiple people can access whenever needed.

Triggering a scenario from another scenario - how?

You have seen that in Make you can use a scenario to start another scenario and send to scenario B the data that has been processed within the scenario A. How can you do it? There are three main ways.

Webhooks

In Scenario A make an HTTP call that triggers a Webhook in the child scenario, as you’ve seen in What are webhooks? course.

Make app

Use the Make app to start a specific scenario. You will learn more about this in the API calls with HTTP modules course.

Subscenarios

Use the Scenarios → Call a subscenario module to trigger any scenario on your Team. Let’s learn more about this in the next pages.

Run a scenario

Let’s take a closer look at the Call a subscenario module in more detail, as this is the one you will be using in the use case.

Scenario A

In Make you’ll find the Scenarios → Call a subscenario module. You need to add it to scenario A to trigger other scenarios (like scenario B). When this module runs, it will trigger scenario B. Remember that scenario A is called parent scenario.

This module lets you trigger any scenario within your team by selecting it from the module setup. You can also configure it to send data processed in scenario A to scenario B. You will learn how to do it in the next pages.

Scenario B

Remember that scenario B that you trigger from the parent scenario, is called (surprise surprise) child scenario.

Scenario B needs to be active, and you want to run it only when scenario A triggers it, not on a regular schedule. For this reason, set it as On demand in the Scenario settings.

Scenario B can use the data that the scenario A sends by using scenario inputs. You will learn about this in the next pages.

Subscenarios

You don’t have to stop here, you can go crazy and create scenario chains! One scenario triggers another (or more), which can trigger even more and so on! This process is called subscenarios, and it’s useful when your use case requires triggering multiple scenarios one after the other.

For example Arnold uses scenario A to share supplies information with Will, triggering scenario B. Scenario B can trigger Susan’s scenario C that processes and ships the order. And so on!

The first scenario in the chain is the parent scenario, the last one is the child scenario. Any scenarios in between are bridge scenarios. You can have multiple bridge scenarios in a scenario chain.

Selecting bridge/child scenario

When you use the Call a subscenario module, you can directly select the scenario that you want to trigger from the drop-down menu containing a list of all the scenarios in your team.

From scenario A, Arthur can directly select scenario B when configuring the Call a subscenario module. Remember that you can only select scenarios within the same team.

Sending data

You can use scenario inputs to send data from the parent scenario to the subscenarios, so they can process it.

You will learn more about this in the next pages. Arnold uses scenario inputs to send the order data to Will, so he can store and process it.

Scenario management

In the Scenario folder Make clearly indicates the relationship between the subscenarios. This allows you to easily identify the parent, bridge and child scenarios.

Sending data to the child scenario

As you have seen, when scenario A triggers scenario B, it can pass data from A to B. You can set this up if you want that your child scenario processes data that the parent scenario generated. But how does this work?

Step 1: Define Scenario Input

In the child scenario, you specify the information you need for processing without assigning a value to it yet, but you just define the data structure.

In scenario B, Will specifies that he needs information about the quantity of items he needs to order. And that it is a number.

As you have seen in the An introduction to data types and data structures course, the data structure describes the format of the data by specifying the data types (i.e. text, number, array, etc) and how it is organized.

Note: This information that you have specified is your scenario input! Let’s keep learning about it. You will see how to specify it in the next pages.

Step 2: Map Input in Child Scenario

Once you have defined the input, this item becomes available in the variables of your scenarios, allowing you to map it across the different modules, even though no value has been assigned to it yet.

Now Will can map the quantity item in the different modules so scenario B can process it when it runs.

Step 3: Map Input in Parent Scenario

In the parent scenario, when you set up the Call a subscenario module and select scenario B as the child scenario, Make recognizes that you need to send some information. This happens because you have created scenario inputs in the child scenario.

This allows you to define the value of this input from the parent scenario, by either assigning it a specific value or mapping the required information.

Arthur is setting up the Call a subscenario module in scenario A, and he realizes that he needs to send the quantity information from the Google Sheets module.

Step 4: Data Transfer

When the parent scenario triggers the child scenario, it passes this information and the child scenario can process it.

When scenario A triggers scenario B, scenario A sends the quantity information, allowing scenario B to process it.

Scenario inputs

This information that you have defined in the child scenario (the quantity item), is your scenario input!

Scenario inputs are dynamic inputs that can be used and mapped in the modules of the scenario. Dynamic input means that the value can change according to the situation or the context, and in this case it will take the value that the parent scenario sends. You can map the quantity item in the child scenario, and the value changes according to the data the parent scenario sends.

You can set them up in the child scenario by defining the data structure, and you will do this in the use case.

Note: Scenario inputs can be used in any scenario, not only in child scenarios triggered using the Call a subscenario module. They are used to pass data with a predefined structure every time you run your scenario. This data is available to all the modules in your scenario. You just need to provide this information when starting your scenario. This is everything that you need to know about scenario inputs for now!

Use case overview

Arnold the Architect needs to share the list of supplies to order for the renovation project with Will. Arnold keeps all the details in a Google Sheet, and uses a scenario (scenario A) to send the information.

Will collects the information from Arnold, stores it in his own Google Sheet, and emails Susan the Supplier with the order details. He does this using a scenario (scenario B).

Now that you know more about how to trigger the child scenario and share info with it, let’s have a look at the scenarios that you will build in the use case. Remember that you want to create a use case that generates an error, that you will fix in the next units.

Parent scenario - A

The parent scenario consists of the following modules:

Google Sheets → Watch New Rows When you run the scenario, this module watches for new supplies information in the Google Sheet. If new information is present, it will pass it to the next module.
Flow Control → Array aggregator This module combines all the information from all the new rows into a single array, to transfer the information altogether to the child scenario.
Scenarios → Call a subscenario This module triggers the child scenario. It also allows you to map the information that you will send to the child scenario.

Child scenario - B

The child scenario consists of the following modules:

Flow Control → Iterator This module takes the array containing the supplies information shared by the parent scenario and splits it into individual bundles. This allows the child scenario to process each bundle one at a time.
Google Sheets → Add a row This module stores the supplies information in a spreadsheet. It rounds the price, which will cause an error if the price isn’t a valid number (because it contains text characters). You will use this to cause the error in the child scenario.
Email → Send an Email to a Team Member This module sends an email to a member of your team containing the information about the supplies that you need to order. In this case you will select your own email. You will use this module as the set up is easy and straightforward.

Preparation

Before you start building the scenarios, let’s make sure everything is ready. Work through each stage before you continue.

Create Arthur’s Spreadsheet

First, let’s create Arthur’s spreadsheet where he keeps all the supplies information. Go to your Google Drive and create a new Google Sheet. Call it MI_C05_U02_architect.

Copy and paste the following text into the first column, ensuring it matches the structure shown in the image:

Item	Supplier	Quantity	Price	Location
Tiles	The Floors	25	453.65	Kitchen
Pipes	Red Hot Chilli Pi	15	125.63	Bathroom
Paint	Paint Floyds	1	89.13	Living room

Create Will’s Spreadsheet

Next, create the Google spreadsheet where Will stores the supplies information. To do so, create another Google Sheet and call it MI_C05_U02_workers.

Copy and paste the following text into the first column, ensuring it matches the structure shown in the image. You will fill the table using the child scenario.

Item	Supplier	Quantity	Price

You’re all set!

Build the child scenario – part 1

Let’s start building the scenarios. The parent scenario needs information about the scenario inputs, which you will set up in the child scenario. So it makes sense to build the child scenario first. Work through each stage before you continue.

Setting up Scenario Inputs

In Make, create a new scenario and call it MI_C05_U02_child.

Let’s start by setting up the scenario inputs. In the toolbar at the bottom of the page, select Scenario inputs and outputs.

You will use Scenario inputs. The supplies information is a collection of multiple elements, so you need to create an array of collections.

Click Add item, name it Supplies. Select Array as the Type. Then select Collection as the Type again, to create an array of collections.

Each collection contains the following items (> with the data type):

Item > Text
Supplier > Text
Quantity > Number
Price > Text

Note: that you set Price as Text. To trigger the error, the price will contain a letter (125m63).

Time to add the different items of the collection that you have just created. Click Add item, name it Item and leave the rest as default to keep the Type as Text.

Repeat the same process for the Supplier. Keep the Type as Text. Add another item and name it Quantity. Change the Type to Number. Add one more item and call it Price. Leave the Type as Text to be able to generate an error as you’ve learned earlier.

Click Save to save your scenario inputs.

You have just set up the structure of the scenario input. These are the data that the child scenario needs to start the scenario, and the parent scenario knows exactly which data to send.

Note: Make sure you have no spaces after scenario input items, otherwise you will get an error.

Will’s questions

Why do you need the scenario inputs? You need the scenario inputs to inform the parent scenario about the information it should send to the child. When building your scenario, when do you have to set up the scenario inputs? You can set them up at any time, as the first thing, while building the scenario, or at the end, when you have added all the modules. Then why are you doing it at the beginning here? Because you need to map the input items in the modules. Setting up the scenario inputs first ensures they are available for mapping.

Will’s questions

Why don’t you set the price as number? If you set it as Number, the child scenario will expect a number for the price item. Make checks the data that the parent scenario sends when triggering the child scenario. If it detects a text instead of a number, it will raise an error in the parent scenario, because the data that it’s sending is not correct. Here, you want the Child scenario to fail, so you set Price as Text. This allows the parent scenario to pass a price containing text characters without issues, leaving the failure to occur in the child scenario.

Adding the Iterator Module

You can start building your scenario now. Add a Flow Control → Iterator module to split the Supplies array that the scenario receives from the parent scenario into separate bundles.

In the Array field, map the Supplies array that you have created in the Scenario inputs. You can find it in the Custom and system variables menu.

Click Save to save your module.

Build the child scenario – part 2

Let’s finish building the child scenario. Work through each stage before you continue.

Google Sheets Module

To store the information about the supplies, add a Google Sheets → Add a row module.

The Google connection should already be present if you have used this app in your team. If it’s not present, click Create a connection and then Sign in with Google. Follow the instructions to create the connection.

Under Spreadsheet ID, select the MI_LC05_U02_workers that you created earlier, and under Sheet Name, select Sheet1.

To add a new row, you have to map the items from the Iterator module. In the Item (A) field, map the Item element. In the Supplier (B) field, map the Supplier element, and in the Quantity (C) field, map the Quantity element.

For the Price (D) item, the situation is different as you need to round it using the ceil() function to be able to later generate an error. Type ceil( then map the Price item from the Iterator module, then close the parenthesis ) to close the function.

Click Save to save the module.

Will’s questions

Can you remind me again why the ceil() function will raise an error?

The ceil() function expects a number, so it can return the smallest integer greater than that number. If you pass 12.3, it will return 13.

But it works with strings as well, you can pass 12.3 as a string, and the function converts it first to a number, then returns the integer.

If the string doesn’t contain a valid number, like 12f3, it will return an error. This is what will happen in your use case.

ceil (number) <integer> Returns the smallest integer greater than or equal to a specified number.

ceil ( 1.2 ) = 2 ceil ( 4 ) = 4

Email Module

To get notified about the order, add an Email → Send an Email to a Team Member module.

Select yourself from the To dropdown menu to send the email to yourself. In the Subject, type New order.

Copy this text and paste it in the Content field:

You have a new item to order:
<br>
<br>
Item: [MAP ITEM]
<br>
Supplier: [MAP SUPPLIER]
<br>
Quantity: [MAP QUANTITY]
<br>
<br>
A new row has been added to the Google Sheet.
Row number: [MAP ROW NUMBER]

Note: that the message contains HTML tags for text formatting: <br> adds a line break in the text.

Notice that in the text that you have just copied there are some instructions in square brackets about the items that you need to map. Remove them and map as described below:

Remove [MAP ITEM], including the square brackets, and map the Item from the Iterator module.
Repeat the same for [MAP SUPPLIER] and [MAP QUANTITY] and map the Supplier and the Quantity respectively from the Iterator module.
Remove [MAP ROW NUMBER] and map the Row number item from the Google Sheets module.

Click Save to save the module.

Scenario Configuration

Save the scenario.

Turn the scenario ON by toggling the button in the toolbar.

In the Schedule setting window, select On demand, so that the child scenario executes only when the parent scenario triggers it using the Run a scenario module. Click Save.

Save the scenario again, and the child scenario is ready!

Build the parent scenario

Time to build the parent scenario now. Work through each stage before you continue.

In Make, create a new scenario and call it MI_C05_U02_parent. First, you want to check the Google spreadsheet for any new row. Add a Google Sheets → Watch New Rows module. Notice that the Google connection is already present.

Under Spreadsheet ID select the MI_C05_U02_architect spreadsheet you created earlier. For Sheet Name select Sheet1. Change the Limit to 10 to allow the module to retrieve up to 10 rows. This ensures you get all 3 existing lines that are actually present while leaving room for future additions. Click Save to save the module. In the Choose where to start window select All. Click Save to save the selection.

Add a Flow Control → Array aggregator to combine all the rows into the same array of collections. Under Source module select Google Sheets → Watch New Rows to specify where the aggregator should take the bundles. Save the module.

Arnold’s questions

How does the Array aggregator generate the array? The Array aggregator needs to know the structure of the array it will generate, including the type of elements it contains. Then, you map the items from previous modules, specifying where the data comes from.

How does the Array aggregator determine the structure of the array? First, you need to add the next module that will use the array. This defines the target structure or the array. Once added, the Array aggregator will recognize this structure that will appear in the setup window of the Array aggregator. You will then be able to map all the items correctly.

Add a Scenarios → Call a subscenario module to trigger the child scenario and transfer the Supplies data. From the Scenario dropdown menu select the MI_C05_U02_child that you have just created. Notice that the module recognizes that the child scenario requires scenario inputs and gives you the option to define them. Toggle the Map button and map the Array[] from the Array aggregator. Set the field Wait for subscenario output to NO. Click Save to save the module.

Go back to the Array aggregator module and click on it to open the set up. Notice that now under the Target structure type menu you can select Scenarios → Call a subscenario → Scenario Inputs:. You have set the Call a subscenario module to send the Supplies array to the child scenario. You have also defined the Supplies array structure in the scenario inputs of the child scenario. Now that you have added and set up the Call a subscenario module, the Array aggregator knows the structure of the Supplies array and will display it in the module set up. You can map the data in it.

Under Item map the Item from the Google Sheets module. Repeat the same for the rest of the items, mapping Supplier in the Supplier field, Quantity in the Quantity field, and Price in the Price field. Click Save to save the module and Save your scenario as well.

No need to change the scheduling settings of this scenario as you will run it by clicking Run once. Let’s do it in the next page!

Run it!

Now it’s time to run the scenarios.

Make sure the MI_C05_U02_child scenario is active and set as On demand.

Go to the MI_C05_U02_parent scenario and click Run once. See that the scenario runs.

Once it completes there are three things you need to check to confirm that your child scenario ran successfully:

Check the history of the child scenario and confirm that it ran with a Success status.
Go to the MI_C05_U02_workers spreadsheet and check that all data has been added. The three items should be present. Remove all of them to have a clean spreadsheet for the next tests.
Check your email: you should have received three emails, each confirming that you need to order a new item.

Great, your scenarios ran properly! Let’s go and mess things up!

Make it fail!

Let’s generate the error in the child scenario. Work through each stage before you continue.

Go to the MI_C05_U02_architect Google sheet and replace the dot in the Price item of the second row with a letter, for example 125m63.

But why do this?

Adding a letter changes the data from number to text. When the Google Sheets module in the child scenario tries to apply the ceil() function, the function will fail because the input is not a valid number.
Modifying the second row lets you observe how the first bundle (the first row) is processed normally, how the second causes the error, and what happens to the third row. No spoilers here!

Remember that you have set the price item as text in your scenario inputs. This ensures that the data can pass from the parent scenario to the child scenario without issues. And that the error occurs only in the child scenario. This will be important in the next units when learning how to handle errors.

Let’s run it! Make sure that the MI_C05_U02_child is active and set as On demand.

In the MI_C05_U02_parent right click the Google Sheets module and select Choose where to start. Select All to reprocess the data that you have in the sheet and Save it.

Save the scenario and click Run once. Check that it ran without any issues.

Let’s review the same three elements (child scenario, workers spreadsheet, email) to see what happened in the child scenario.

Go to the child scenario, and notice that it is still active. In the History, you’ll see an Error status for the last run. Click Details to find out more.

The Google Sheets module generated an error. Click on the error icon for more information. The module produced a DataError because the value that passed to the ceil() function was not a valid number. Everything as expected!

Go to the MI_C05_U02_workers spreadsheet and notice that now it contains only one line. This corresponds to the first row of the MI_C05_U02_architect spreadsheet.

This means that the scenario didn’t process the second row, which caused the error. And it didn’t process the third row either, even if the scenario is still active. As you’ve learned before, when an error occurs, Make stops the current run. This means that it doesn’t process any bundles after the one that caused the error. This data is now lost. Learning to automatically handle errors can help you prevent this. Interesting! Let’s keep investigating.

Before moving forward, delete all the rows (except the column names) to reset the workers Google sheet for the next units.

The last place to check is your inbox. You should have received two emails:

New order: An email confirming the new order of the item on the first row. This indicates that the scenario processed the first bundle properly.
Encountered error: An email notifying that Make found an error in the scenario. It provides more details about this. You will receive this email if you have not disabled the email notifications in Make.

Notice that the email says: The scenario has not been paused and continues to run according to your settings. Does this ring a bell? Which of the scenario behaviors that you have seen before does this refer to? Click here for the answer.

Make stops the current run, but doesn’t deactivate the scenario. It will wait for three consecutive errors before deactivating it.

You can check this by repeating the entire process from step 2 two more times and observe that the scenario gets deactivated.

If you do this, remember to turn the scenario back ON for the next units.

Great job! You have an error in your scenario!

Wrap up

You can trigger a scenario from another to simplify processes, avoid duplication, or provide a service. You can use the Call a subscenario module to trigger any scenario from your team. Scenario inputs allows you to send data from the parent scenario to the child scenario, defining the data to transfer and process.

In Make, if an error occurs in a scenario, the run stops, and you will receive an email notification. You can find more information about the error in the run history, clicking on the module that generated the error.

When an error happens, the scenario stops processing the bundle that generated the error, along with any bundles after it.