Subscenarios
Subscenarios allow you to link multiple together to form a scenario chain. When the first in the chain finishes, it triggers the next . This is useful in workflows with different stages or processes that need to run in a specific order. Creating a chain with subscenarios brings in the following features:
- Run in sequence: when the first finishes, it automatically triggers the execution of the next . This ensures that tasks are carried out in the desired order without manual intervention.
- Data transfer: The first can send data to the second . This allows for using the result of the first as an input for the second .For example, you can send an order number to a that updates the warehouse inventory and to another that sets up tracking of the order delivery.
- Modularity: You can split a complex into multiple chained . By breaking down a complex workflow into smaller, manageable , it becomes easier to design, debug, and maintain. In addition, you can link the with other in the future, to avoid rebuilding the same logic.For example, you can have multiple to send customers notification emails and order invoices. Each of these starts with a few modules retrieving user data. With chaining, you can extract the repeating modules to a separate and put it at the start of the chain.
There are three types of in a chain:
- Parent
- Starts the chain.
- Triggers bridge or child .
- Can have multiple Run a scenario modules.
- Bridge
- Connects child or other bridge with parent in the chain.
- Is triggered by a parent or another bridge . In addition, the bridge triggers another bridge or a child .
- Can have multiple Run a scenario modules.
- Child
- Ends the chain.
- Is triggered by parent or bridge .
- Doesn't have any Run a scenario modules.
The following diagram shows the relation between parent, bridge, and child .
The chains can even create branches, like this:
To create a chain, you need to create multiple scenarios. The following steps focus on a quick and simple showcase, where you don't need to build complicated to try out chaining. Keep in mind that chaining brings the most benefits when you want to split a complex into multiple parts.
Overview of the steps to create a chain:
- Create the parent .
- Create the child .
- Connect the with Run a scenario modules to form a chain from the parent and child .
- Set the scheduling for the in the chain.
The chain can be visualized like this:
In the parent , we will use the OpenWeather app to get weather data. We will use the Set multiple variables module to set the data we will be sending to the child .
In , click Create a new scenario.
In the editor, click the big plus icon and search for the OpenWeather app.
Connect the Get current weather module with the Set mutliple variables module. In the Set multiple variables module, create new variables and map the data you want to send to the child .
For example, map the Temperature and Pressure pills from the Get current weather module to the london_temperature and london_pressure variables:
Connect the Get current weather module with the Set mutliple variables module. In the Set multiple variables module, create new variables and map the data you want to send to the child .
You created a starting piece of the parent in the chain.
Your should look like this:
In the following steps, we will create two child . Both child will use scenario inputs to receive data from the parent .
Click Create a new scenario.
In the editor, click the big plus icon and search for the Gmail app.
In search results, select the Send an email module.
Set up the inputs for the . The will expect the london_temperature and london_pressure variables as its inputs.
Configure the Send an email module. Use the inputs in the email message.
Confirm the module settings and save the .
Create another child .
For example, you can use another messaging app if you have created a connection for it, like the Slack app.
You have three new in your Make team, but they are not connected yet. Let's fix that.
The following steps describe how to use the Scenarios > Run a scenario modules to connect the parent scenario with the child scenarios.
Go to the first with the Get current weather and Set multiple variables modules.
Add the Scenarios > Run a scenario module to the .
In the Scenario field, select the you want to trigger with the module. If you are following the example, select the which sends the email notifications.
Note that the are organized in folders.
retrieves the inputs of the scenario you select. Map the london_temperature and london_pressure variables to the input fields:
Note that at the top of the module settings, there's the Inactive label informing you that the child scenario is not active. There's also the child scenario ID, the scenario folder and name and a Preview link that opens a new tab with the child scenario open in the scenario editor.
Click OK to confirm the settings and save the parent .
Open the Run a scenario module settings again and click the Preview link to go to the child .
Set the child scheduling to On demand. Enable the and save.
Repeat the same steps for the second child .
When you connect both of the with the parent , your list of should look like this:
Note the second to last column in the list. The column shows whether the is a parent, bridge, or child in a chain. Users in organizations with the Teams and Enterprise pricing plans can see the column.
See Make pricing for more information.
In the previous section, we've set the scheduling to on demand to have the enabled for testing without running them in intervals.
The in the chain have independent scheduling. A child can trigger with its own scheduling, in addition to being triggered by a parent or a bridge .
For example, if the child scenario in a scenario chain runs every two hours, but the parent (or bridge) scenario triggers it every hour, then the child scenario will run four times in three hours:
- 1st run: The child is triggered by the parent an hour after the start.
- 2nd run: The child triggers by it's own scheduling two hours after the start.
- 3rd run: The child is triggered by the two hours after the start.
- 4th run: The child is triggered by the parent s three hours after the start.
When setting scheduling for in the chain, keep in mind that the scheduling of the linked combines.
If you want to run in a chain in a sequence, use on demand scheduling.
In the example, set scheduling for the parent , but keep the child running on demand.
The child use the inputs from the parent with no default values. If the child would run with a schedule on their own, they wouldn't contain any values for the inputs.
You can prevent running a with empty inputs by setting the input field as Required and the scheduling to On Demand.
The Run a scenario module from the app enables you to trigger a run from another . The Run a scenario module from the Scenarios app works similarly.
The major advantage of chaining over triggering a with the app is the management utility and auditability of chaining. You can view connected in the relation tree tab and you can see chained in the list and history.
For a full comparison of the individual approaches to trigger a from another , check the comparison section.
To start using chaining instead of the Run a scenario module from the Make app:
Go to the that uses the Make > Run a scenario module.
Swap the Make > Run a scenario module for the Scenarios > Run a scenario module.
In the Scenario field, select the you want to trigger.
Optional: If you transfer data between , map inputs to the Run a scenario module.
Review the scheduling of the child . The child can have its own scheduling in addition to being triggered from the chain.
You can access the child from the Preview link in the Run a scenario module settings.
Check the relation tree tab in the details of any of the . The relation tree tab is now showing two .
The parent is the that contains the Run a scenario module, and the child is the triggered by the module.
With the HTTP > Make a request module, you can send data to a Webhooks > Custom webhook module. The Scenarios > Run a scenario module works differently. Run a scenario module sends data to a through inputs, instead of using the HTTP app.
The major advantage of chaining is the management utility and auditability of chaining. You can view connected in the relation tree tab and you can see chained in the list and history.
You can also use the inputs to validate the data you send to the child instead of checking the data after the webhook receives them.
For a full comparison of the individual approaches to trigger a from another , check the comparison section.
To start using chaining instead of the HTTP and Custom webhook modules:
Go to the with the HTTP > Make a request module.
Swap the HTTP > Make a request module for the Scenarios > Run a scenario module.
In the Scenario field, select the you want to trigger.
Optional: Set up inputs to transfer data from the parent to the child . Make will evaluate the structure of the inputs before running the , which increases the reliability of the chain.
Remove the Custom webhook module from the child .
Review the scheduling of the child . The child can run on demand when triggered from the parent , or can have its own scheduling in addition to being triggered from the chain.
Check the relation tree tab in the details of any of the . The relation tree tab is now showing two .
The parent is the that contains the Run a scenario module, and the child is the triggered by the module.
chaining simplifies the management of sequences, where one triggers another. This approach eliminates the need for naming conventions or organizing sequences in folders. Instead, you can easily monitor and manage the within a chain from multiple places in Make:
The relations, like:
- the Relation tree tab
- relations in the list of
- relations in the history
show only to users in organizations with the Teams and Enterprise pricing plans. Users in other organizations have to track relations differently.
See Make pricing for more information.
Run a scenario module: When you select a in the Scenarios > Run a scenario module, you can see at the top of the module settings information about the triggered by the module:
You can see:
- whether the is enabled (Active) or disabled (Inactive)
- ID
- the folder name
- the Preview link. Clicking the preview link opens a new browser tab with the linked scenario open in the scenario editor
Relation tree tab: Scenarios that are part of a scenario chain have the Relation tree tab:
- The Relation tree tab shows directly connected to the currently open in the chain.
- The open is outdented in the relation tree.
- A column in the relation tree shows the relation of the in the chain.
The scenario list also shows the chain relations:
Bundles output by the Run a scenario module contain a link to the triggered run.
Scenario history contains a link to the scenario that triggered the scenario run.
There is no link if the in the chain runs because of its own scheduling instead of being triggered by a parent or a bridge .
To add a to an existing chain:
Create the you want to add to the chain.
Go to the from which you want to trigger the new .
In the parent , add the Scenarios > Run a scenario module.
In the Scenario field, select the you want to trigger (the created in step 1).
You connected the to a chain. Check the Relation tree tab of the added to see the connected to the parent .
Make sure to review the scheduling and enable the added .
To remove a from a chain:
Go to the parent which triggers the you want to remove.
In the parent , remove the Scenarios > Run a scenario module.
You removed the from a chain. The removed doesn't have a Relation tree tab anymore and Make doesn't highlight the as a part of a chain.
If you are a power user of , you might know of other options on how to connect into a sequence. The following table compares the other approaches with chaining:
| Scenario chaining | Make app: Run a scenario | Trigger a webhook with the HTTP app |
|---|---|---|---|
triggering | Scenarios > Run a scenario | Make > Run a scenario | HTTP > Make a request the follow-up has to start with a webhook module |
Setting next | Select from a list of , categorized in folders. The has to be in the same team. | Search available through the Make app connection. You can run in any organization or team to which you have access. | You have to know the webhook URL. You can trigger any webhook if you know its URL. |
Sending data | Use the scenario inputs to accept data from the previous . | Use the scenario inputs to accept data from the previous . | Send the data in the HTTP request body or in the query parameters. |
sequence management |
| There are no dedicated management options. You can put sequence in a dedicated folder, use custom scenario properties, or create your own naming convention. | There are no dedicated management options. You can put sequence in a dedicated folder, use custom scenario properties, or create your own naming convention. |
running in parallel | You can trigger the next in a chain before it finishes it's current run. You can have multiple running in parallel. | You can have multiple running in parallel. | You can run webhook-triggered in parallel. |
chaining has certain feature limitations to help you avoid creating complex or unmanageable chains that could result in infinite loops. These limitations are as follows:
- You cannot use the Run a scenario module to trigger the current itself.
- You cannot form a circular chain. If a is already part of a chain, you cannot add it again to the same chain.
- You cannot connect from different teams. You can only create a chain from scenarios within the same team.