Hi Community!
I’ve set Scenario (1) to run with the last element of the scenario set to run another Make Scenario (2). In (1), I have a “Set Variable” module which takes the result and places the result value in variable called “requestid”. So, then Scenario(2) executes. However, I am unsure how to pass/reference Scenario 1 variable in Scenario 2.
I have the PRO plan.
Is this possible to achieve in the current plan?
1 Like
Hey Simon,
You need to use HTTP module in scenario 1 to make POST API call to send a variable, And Webhook as a trigger for scenario 2 to catch this variable.
@mania_braun thanks for your prompt reply!
So what you’re saying with the HTTP method is don’t use the “Run Make Scenario” within Scenario 1 but instead just do an HTTP request? ok, but I dont know what HTTP API request to make here? or what to pass… sorry if I’m being dumb.
And in terms of ‘System Variables’, my need is for a ‘Scenario Variable’ because I do not have the value of the variable until I’ve run Scenario 1.
First, create a Webhook trigger and copy the link:
Then Create the HTTP module “Make a request” in scenario 1, paste a webhook link, choose method POST, Body Type RAW, content type json, and your variable in the content. You may need to convert the variable to JSON, I’m not sure.
@mania_braun I see! That works well. Thank you so much.
Is it possible to pass two separate variables in the HTTP request? I can see the “Request Content” but I’d like to pass and “ID” and a “Result” values to the HTTP request and then map the two different values to two different fields in the other scenario
You can use an aggregator and create an array of what you want to send then send it over using the http as you are doing already. Once the data gets to the scenario iterate on the array to separate the values. BOOM!
Have you considered scenario inputs on Scenario 2 and use the Make app to execute scenario 2 from scenario 1? The scenario inputs feauture should be available on your Pro plan. All the different type of variables are possible as scenario inputs so you’re not limited by what you can pass from scenario 1 to scenario 2. On scenario 2 to setup scenario inputs click the input icon:
You will be able to define the name of the input and the data type as well. You can make as many inputs as necessary. Think of these as set variables that are dynamically provided when you run the scenario. You must set the scenario to on-demand execution, as scenario-input powered scenarios cannot be scheduled, since they are executed on demand.
The Make app has a moduled called “Run a Scenario” that can execute another scenario (ie your scenario 2) and make any scenario inputs defined available for you to populate from Scenario 1.
Once you find your senario and enter the scenario ID, all your scenario inputs from scenario 2 will appear in the Run a Scenario definition and you can map them using data generated in scenario 1.
What’s nice about this is you can execute Scenario 2 “on demand” and populate the inputs manually if you just want to run scenario 2 manually.
No need to setup webhooks or use HTTP and you can modify the scenario inputs on scenario 2 at any time and update the Make app, Run a Scenario quickly to support any new scenario inputs.
3 Likes
@alex.newpath that worked!
That is exactly what I was looking for. It’s cleaner than using webhooks and https calls.
I didn’t understand how “Scenario Inputs” worked and now see the light :). Great explanation so thank you.
I setup two Scenario Inputs in the 2nd scenario and these became visible inside Scenario 1 after adding the Make module “Run a Scenario” and hooking up Scenario 2.
It’s a masterpiece of engineering. Well done to the Make.com developers!!
3 Likes
It is actually quite clever, I agree. The Make API is used instead of webhooks so I expect it is more reliable. BTW, you can schedule the calling scenario (Scenario 1) to execute the full Scenario 1->Scenario 2 execution of course, in case you were wondering. You just can’t schedule Scenario 2 which has scenario inputs.
I expect they will encourage the chaining and breaking down of more complex scenarios to be called this way in the future with more features to support this process.
3 Likes