Explore more
Scenarios
Subscenarios
15 min
in make, you can build an automation using a parent scenario and one or more subscenarios a parent scenario is the main scenario that triggers one or more subscenarios via the https //apps make com/scenario service#call a scenario module a subscenario is a scenario triggered by a parent scenario or other sources, such as an ai agent, an mcp client, or an api call a p arent scenario can include multiple scenarios > call a scenario modules to trigger different subscenarios a s ubscenario can also act as a parent scenario and trigger other subscenarios through the scenarios > call a scenario module benefits of subscenarios s ubscenarios help you to simplify complex workflows break down large scenarios into smaller, manageable components that are easier to build, maintain, and troubleshoot for example, instead of building a single scenario with dozens of routes to handle lead creation, checking companies, contacts, campaigns, and affiliates, you can split each task into its own subscenario the parent scenario stays clean and readable, while each subscenario handles one thing well save time by reusing logic use the same subscenario across different parent scenarios instead of recreating modules for example, if multiple scenarios need to update your product inventory, new orders, returns, b2b deliveries, you can build one inventory subscenario and call it from all of them update the logic once, and all parent scenarios benefit automatically extend automation to ai agents and mcp servers use scenarios as callable tools in agent workflows for example, you can expose a subscenario as a tool that an ai agent calls when it needs to look up a customer record, send a notification, or trigger an action in an external app, without the agent needing to know how the underlying automation works transfer data more easily pass a clearly defined structure of inputs and outputs between scenarios for example, you can send a customer’s email as an input to a subscenario it checks whether they’re already registered, then returns a status as an output that the parent uses to decide whether to send a welcome email if you call a scenario using the webhooks app, you don't have the in built capability to define the inputs you want to pass from the parent scenario and the outputs you want to receive from the subscenario reduce credit usage scenarios run via the scenarios app don't consume credits for example, if you call a scenario using the webhooks and make apps, each operation will consume credits with the scenarios app, you can call scenarios, pass the inputs, and return outputs free of charge limitations of subscenarios although subscenarios offer multiple benefits, they also have certain limitations you can only call a scenario created in your team if you want to call a scenario from another team or organization, you have to use one of these modules make > run a scenario webhooks > custom webhook calling modes for subscenarios subscenarios can run in two modes that define how the parent scenario and the subscenario interact they can follow synchronous execution asynchronous execution the mode depends on whether the parent scenario needs the subscenario´s results to continue the run synchronous execution in synchronous mode the parent scenario calls the subscenario via the scenarios > call a scenario module, passes scenario inputs, and pauses execution until the subscenario completes the subscenario starts running with the scenarios > start scenario module, processes the inputs, and returns outputs to the parent scenario via the scenarios > return outputs module once the parent scenario receives the outputs, it resumes execution asynchronous execution in asynchronous mode the parent scenario calls the subscenario via scenarios > call a scenario module, and continues immediately without waiting for outputs the subscenario starts running with scenarios > start scenario module and completes its operations independently a parent scenario can also call multiple subscenarios that run in different modes create a parent scenario with subscenarios to build an automation with subscenarios, you need to c reate a parent scenario create one or more sub scenarios that this parent scenario will call link them with the scenarios > call a scenario / scenarios > start scenario modules let's look at this basic workflow as an example and walk through each step afterward a parent scenario the parent scenario receives the data from the jotform > watch for submissions a subscenario with s ynchronous execution the parent scenario sends the data to the subscenario and waits for the output the subscenario checks if the email from the event registration form already exists in the database using the google sheets > search rows module a router handles two possible outcomes email doesn't exist the participant is added to the database via the google sheets > add rows module the subscenario sends a confirmation and the data back to the parent scenario via scenarios > return output module email already exists the subscenario sends a notification back to the parent scenario via the scenarios > return output module after the parent scenario receives confirmation that the email has been added, it sends a welcome email to the participant via the gmail > send an email module a subscenario with as ynchronous execution the parent scenario sends the data to the subscenario and immediately proceeds to send a welcome email to the participant without waiting for the outputs the subscenario stores the participant's data in the database and completes create a parent scenario to create a parent {{scenario singular lowercase}} in {{product name}} , click +create a new scenario in the scenario builder, click the big plus icon and add the jotform > watch for submissions module in the webhook field, click add to create a webhook in the create a webhook window in the webhook name field, enter the webhook's name in the connection field, select a connection or create a new one in the team field, select the jotform team in the form field, select the form that collects event registrations click save click save to save the module settings click the plus icon next to the jotform > watch for submissions module and add the scenarios > call a scenario module in the scenario field, click +create scenario you can also select an existing scenario from the list in this case, make sure that the scenario you select as a subscenario is active and scheduled to run on demand additionally use the scenarios > start a scenario module to start a subscenario define scenario inputs define scenario outputs if the parent scenario expects them use scenarios > return output module if the parent scenario expects outputs after this, you'll be redirected to the scenario builder there, you can create and configure your subscenario based on whether you want synchronous or asynchronous execution create a subscenario with s ynchronous execution after clicking create a scenario in the scenarios > call a scenario module, you can configure your subscenario to do that in the create a scenario window in the name field, enter the subscenario name optionally, in the description name field, add a description define the input and output structure in our example, the parent scenario receives the name and the email from the jotform > watch for submissions module and passes this data to the subscenario therefore, we create two scenario inputs name and email for outputs, we want to return the participant's registration status together with the name and email, so we create three outputs status , name , and email click create scenario you can see scenario inputs and outputs in the subscenario it is important to define the https //help make com/create the structure of scenario inputs or outputs accurately to ensure data passes without errors you will see a scenario diagram with two automatically added modules scenarios > start scenario and scenarios > return outputs to add modules to your subscenario, click the big + icon between the modules add the google sheets > search rows module to check whether the email already exists in your database in the module settings select the spreadsheet and sheet where registrations are stored in the filter field select the google sheet's column that contains emails set the text operators equal to map the email from scenarios > start scenario module click save add a router that will handle two possible routes the first route will run if the email from the registration form doesn't exist in the database to configure the filter, right click the dots between the modules and select set up a filter set the condition as follows map total number of bundles from the google sheets > search rows module select numeric operators equal to enter 0 add the google sheets > add a row module to store the email and the name from the registration form in the module settings select the spreadsheet and sheet where registrations are stored map name and email values from the scenarios > start scenario module click save click the scenarios > return output module after the google sheets > add a row module you will see the output fields you defined when creating a subscenario in the status field, enter a message indicating the participant has been added e g , participant added in the name and email fields, map the name and email passed from the parent scenario so that you can identify the participant return to the router and add a second route this route will run if the email from the registration form already exists in the database to configure the filter, right click the dots and select set up a filter set the condition as follows map total number of bundles from the google sheets > search rows module select numeric operators greater than enter 0 add another scenarios > return output module to this route you will see the output fields you defined when creating a subscenario in the status field, add a message indicating the participant is already registered e g , participant already exists in the name and email fields, map the name and email passed from the parent scenario your subscenario should now look like this all subscenarios should be active and scheduled on demand if you create a subscenario from the scenarios > call a scenario module, it's automatically scheduled on demand in this case, you only need to enable the toggle to activate the subscenario and save it return to the parent scenario to complete the configuration open the scenarios > call a scenario module and verify that the correct subscenario is selected the subscenario is active (has a green active label) in the scenario inputs field, map the data you pass from the parent scenario to the subscenario in this example, it will be name and email from the jotform > watch for submissions module set wait for the scenario to finish to yes in a synchronous execution, it indicates that a parent scenario will wait for a subscenario's outputs before continuing execution once verified, click save add the gmail > send an email module to send a welcome email to the registered participant here, you can map email returned from the scenarios > call a scenario module to the recipient email address field the scenarios > call a scenario module will return outputs from your subscenario since we only need to send the email to the newly registered participants, set up a corresponding filter right click the dots between the gmail > send an email and scenarios > call a scenario modules, and click set up a filter set the condition as follows map status from the scenarios > call a scenario module select text operators equal to enter participant added (the status defined in step 8) click save your parent scenario should look like this save it and submit a form in jotform to test the workflow create a subscenario with as ynchronous execution after clicking create a scenario in the scenarios > call a scenario module, you can create your subscenario to do that in the create a scenario window in the name field, enter the subscenario name optionally, in the description name field, add a description define the input structure in our example, the parent scenario receives the name and the email from the jotform > watch for submissions module and passes this data to the subscenario therefore, we create two inputs name and email since this is asynchronous execution, the parent scenario doesn't expect any outputs therefore, you don't need to define any output fields click create scenario you will see a scenario diagram with the scenarios > start scenario and the scenarios > return outputs modules to add modules to your subscenario, click the big + icon between the modules add the google sheets > add a row module to store the participant's information in the module settings select the spreadsheet and sheet where registrations are stored map name and email values from the scenarios > start scenario module click save if you create a subscenario from the scenarios > call a scenario module, the scenarios > return output module is added automatically since in asynchronous execution, your subscenario will not return any output, you can right click this module and delete it your subscenario should now look like this all subscenarios should be active and scheduled on demand if you create a subscenario from the scenarios > call a scenario module, it's automatically scheduled on demand in this case, you only need to enable the toggle to activate the subscenario and save it return to the parent scenario to complete the configuration open the scenarios > call a scenario module and verify whether the correct subscenario is selected the subscenario is active (has a green active label) in the scenario inputs field, map the data you pass from the parent scenario to the subscenario in this example, it will be name and email from the jotform > watch for submissions module set wait for the scenario to finish to no in asynchronous execution, it indicates that a parent scenario will not wait for a subscenario's outputs and will continue execution after calling it once verified, click save if the subscenario has a grey inactive label, click preview this will open a subscenario in a new window, where you can activate and save it add the gmail > send an email module to send a welcome email to the registered participants here, you can map email returned from the scenarios > call a scenario module to the recipient email address field finally, save the parent scenario and submit a form in jotform to test the workflow when to use subscenarios reduce the complexity and simplify the maintenance of scenarios subscenarios are useful when you're building a complex workflow with multiple conditions and branching logic they help reduce overall complexity and make scenarios easier to read, debug, and maintain let's suppose you are creating a "b2b leads creation" scenario that receives new contact information, which includes the contact's identity the company they work for optionally, the affiliate who introduced them optionally, the campaign or event they are interested in creating a contact may seem simple, but the process can quickly become complex, as you need to check whether the company already exists in the crm (and create it, if it doesn't) check whether the contact already exists (and create or update it, if necessary) optionally, add the contact to campaigns or events optionally, link the contact to an affiliate partner if you process such a complex workflow in a single scenario, you may end up with multiple routes and nested filters leading to more routes as the workflow grows, it becomes harder to read, more difficult to debug, and increasingly complex to maintain a better approach is to divide the workflow into dedicated subscenarios for each task create or update a company create or update a contact add a contact to a campaign or event attach a contact to an affiliate with this structure, the parent scenario stays simple it can have a few routes, evaluate high level conditions, and call the appropriate subscenario when needed the subscenarios will focus on a single task each and have their own routes and conditions even if a subscenario becomes complex internally, it remains easier to maintain and troubleshoot r euse instead of duplicating subscenarios are also useful for avoiding duplicated logic across multiple workflows let's suppose you're managing product inventory and need to create or update products in several different business cases when a new order is placed in your online store, you decrease the stock when a b2b partner places a direct order, you also decrease the stock when new products are delivered, you update the product in the inventory when a customer returns a product, you increase its stock you can build separate scenarios for each of these cases for example, when a new order is placed in shopify, the scenario would check whether the product still exists in the inventory in your erp verify that stock is available return an error if the stock is 0 decrease the stock by the ordered quantity similarly, when adding a new product to the inventory via a form, the scenario would verify whether the sku already exists create the product if it doesn't exist update the stock level accordingly if you look closely, each use case follows the same pattern verify whether the product exists check stock levels increase or decrease stock update product information handle errors (e g , when stock equals 0) by having a workflow for each case, you're duplicating actions across multiple scenarios and spending more time on updating each of them additionally, if you want to add another step to the workflow (e g , add a new pos with access to update inventory), you have to duplicate the stock inventory logic again a better approach is to create a dedicated subscenario that will handle inventory and create products update products verify stock levels increase or decrease stock manage stock related errors all parent scenarios can simply call this subscenario whenever inventory needs to be checked or modified you will no longer need to duplicate the stock management operations as they are centralized in one subscenario that reuses the same logic you can also link any new parent scenario at any time, and if you change erp or handle more data, you just need to change one single scenario