🔥 Feature Spotlight: System Variables & Custom Variables

Hey Makers :wave:

I’m stoked to let you know that the Make team is introducing system and custom variables
Not sure what that means? Why don’t you sit back and let me tell you what’s up. :tada:

System Variables


:purple_circle: What are they?

With system variables, error handling and scenario activity tracking are now easier and faster than ever before.

Thanks to system variables, you can see more information about

  • a scenario (scenario ID, scenario name, scenario URL)
  • a specific scenario execution (execution ID, operations consumed, data consumed, execution start date/time)
  • the team the scenario is in (team ID, team name)
  • the organization the scenario is in (organization ID, organization name, operations left, data left, domain)

All the above-mentioned information is newly available to all Makers in reusable elements that can be mapped to any module or filter.


:purple_circle: When to use them?

Yes, the theory is great but how can you put system variables into practice? Let’s go through a couple of examples of how they can be helpful.

  • Set email notifications to notify you once the ‘operations left’ value reaches a certain number.
  • Create a slack message, email, or support ticket that contains a link to the scenario that created the message.
  • Detect an error in your scenario by pinpointing the exact scenario execution and organization in which the error occurred.

watch system variables in action


Custom Variables


:purple_circle: What are they?

Makers on Pro and higher plans can now create custom variables for data that they want to use across multiple scenarios within an organization.

Custom variables can be defined at organization or team level.

A variable has a:

  • Name (permanent variable name)
  • Data type (text, number, Boolean, or date)
  • Value (the actual value of the variable)

:purple_circle: When to use them?

Thanks to custom variables you can avoid human errors and spend less time maintaining scenarios.



There is a whole bunch of situations where custom variables come in handy. To name a few, you can:

  • Set a number of outreach attempts before you stop contacting a potential customer.
  • Easily access a specific company name, address, and email address.
  • Send emails with a consistent email signature.

watch custom variables in action


Wanna learn more about working with variables on Make? You can check out

Helpful Links:

:make: The Guide
:make: Our Blog


Also, feel free to use the space below to let us know your thoughts on these new features :purple_heart:

4 Likes

One extremely helpful use of these variables, which was totally missed in the explainer video, is to build Make Scenario History Log URLs for each run of your scenario.

I have made it a regular practice to save the execution history URL of new records or assets that are created by Make scenarios. This can now be dynamically with these variables.

Simply paste the string below where you want to save the URL, and you’re all set!

https://us1.make.com/{{var.team.id}}/scenarios/{{var.scenario.id}}/logs/{{var.scenario.executionId}}

This string will dynamically create your history URL, like this:

7 Likes

I absolutely love that, thanks so much for sharing @andyoneil :purple_heart:

Even simpler version is

{{scenario url}}/logs/{{execution id}}

:wink:

4 Likes

I have found this doesn’t paste as well 100% of the time into make from my shortcut program. But it is definitely a shorter link to remember.

Hi, is it possible to define the same at the Scenario level?

I know there are the modules to set variables, but I’m more thinking as something like variables or constants to be defined at the scenario level, for example a link, id, address, etc.

Thanks

That’s the standard set variable or set multiple variables Tools modules.

To be sure constants are set the same way but aren’t protected from being edited in later scenario modules. We use a data store to store constants and structures for scenario data we wish to externalize.

1 Like

Oki thanks

The issue with these is that they execute at each execution run, which is useless in this case.

Data store values can stay constant between executions and only take one operation to read a ton of data.

How do you make your data store get module not to execute at each scenario execution?

I’m afraid that’s not possible. Any time a module is executed successfully it needs to run at least one operation.

1 Like