Make.com scenario variables hold values while a scenario runs. The Set variable module stores a value under a name, and Get variable reads it later in the same run, which is useful after routers and iterators where earlier values are hard to reach. Variables reset when the run ends. When you need to keep data between runs, like a list of processed IDs or a counter, use a data store, which is a small database inside Make. Scenario inputs are different again: they are values you pass into a scenario when you start it, so the same scenario can run with different parameters.
These three tools solve most of the "how do I remember this?" problems in Make. This guide explains each one, when to use which, and the patterns I use in agency builds.
Variables inside a run: Set variable and Get variable
The Tools app in Make has modules for variables:
- Set variable and Set multiple variables store one or several named values.
- Get variable and Get multiple variables read them back.
Each variable has a lifetime. You can set it to last for one cycle or for the whole execution. For most uses, one execution is what you want.
When to use variables
- After a router. You calculated something before the router and need it in a later module on a different route. Set it once, get it wherever needed.
- After an iterator and aggregator. Values from before the loop can be awkward to map after aggregation. A variable keeps them handy.
- Cleaner mapping. Instead of repeating a long formula in five modules, compute it once into a variable, like a formatted client name or a Slack channel ID.
- Flags. Set a "has_error" or "is_priority" value that later filters check.
Variables are not persistent
When the run ends, they are gone. If you need a value next run, use a data store.
Make.com data stores: state between runs
A data store is a simple table inside Make. You define a data structure (the fields and their types), and scenarios can add, get, search, update and delete records. Records persist across runs and across scenarios.
Setting one up
- Go to Data stores in Make and create a new data store.
- Define a data structure with the fields you need, for example: key, client_id, status, last_processed_at.
- Choose the size. Data store storage counts toward your plan's allowance. Make's pricing page lists 1 MB of data storage on the free plan and more storage as your licensed credits increase.
- In a scenario, add the Data store app and use modules like "Add/replace a record", "Get a record", "Search records", "Update a record" and "Delete a record".
Every record has a key. Use a meaningful key, like the lead ID or invoice number, so you can get a record directly instead of searching.
Data store patterns I use
Deduplication
Problem: a webhook sometimes sends the same event twice, and you do not want two Slack alerts.
- Trigger receives an event with an ID.
- Data store: check whether a record with that key exists.
- Filter: only continue if it does not.
- Do the work.
- Data store: add a record with that key and the timestamp.
I use this pattern for alert scenarios like the failed-payment alerts, where the same billing email can be forwarded more than once.
Last processed marker
Problem: an API has no proper trigger, so you poll it, and you need to know where you left off.
- Data store: get the record "last_run" with the timestamp of the last successful run.
- Call the API for items updated since that timestamp.
- Process them.
- Data store: update "last_run" to now.
Counters
Problem: you want to count how many leads each rep got today for round robin, or how many alerts fired this week.
Use a data store record per counter, read it, add one, and write it back. For high-volume concurrent runs, enable sequential processing on the scenario so two runs do not read the same value at once.
Lookup tables
Problem: you need to map a client ID to a Slack channel, owner and ClickUp list.
A data store works, but for anything your team wants to edit, a Google Sheet is easier for non-technical staff. I usually put lookup tables in a sheet and use data stores for state the scenario manages itself. The client health monitor reads its routing context from Google Sheets for this reason. See Make.com Google Sheets.
Work queues
Problem: work arrives in bursts and a scenario that processes it all at once times out.
- Intake scenario adds each item to a data store with status "pending".
- Worker scenario runs every few minutes, searches for a handful of pending items, processes them and marks them "done".
See Make.com scenario timeout for the full pattern.
Make.com scenario inputs
Scenario inputs let you define parameters a scenario expects when it starts, a bit like the arguments to a function. You set up the inputs in the scenario, and when the scenario is run on demand or called from another scenario, the caller provides the values.
Uses:
- One reporting scenario that runs for a specific client ID passed in as input.
- A "run backfill for date range" scenario where you supply the start and end dates when you run it.
- A sub-scenario that a parent calls with the record to process.
How inputs work, and which triggers support them, is evolving in Make, so check Make's help documentation for the current setup in your account. If inputs do not fit your case, a Custom webhook trigger with a JSON body does the same job: the caller sends the parameters in the request.
Custom variables at organization or team level
Some Make plans include custom variables defined at the organization or team level, which every scenario can read. They are handy for values shared across many scenarios, like a default error channel ID or an environment flag. Availability depends on your plan, so check Make's pricing page. If you do not have them, a small data store or a settings sheet can play the same role.
Which one should you use?
- Need a value later in the same run? Set variable and Get variable.
- Need to remember something between runs? Data store.
- Need a human-editable lookup table? Google Sheets.
- Need to pass parameters when starting a scenario? Scenario inputs, or a webhook with a JSON body.
- Need a value shared by many scenarios? Organization or team custom variables if your plan has them, otherwise a data store or settings sheet.
Common mistakes
- Expecting variables to persist. They reset every run.
- Searching data stores when you could get by key. Use meaningful keys and Get a record.
- Letting data stores grow forever. Delete or archive old records on a schedule, because storage is limited by plan.
- Race conditions on counters. Two runs reading and writing the same record at once. Use sequential processing where it matters.
- Storing secrets in data stores. Use connections and credentials for secrets, not plain records.
How I build this
I use variables, data stores and inputs to make agency scenarios reliable: no duplicate alerts, clean resumes and parameterised reports. See my workflow automation service, or if a scenario is sending duplicates or losing track of what it processed, the Automation Rescue fixes it in 48 hours. You can also request a free 15-minute Loom teardown.
FAQ
How do I set a variable in Make.com?
Add the Tools app and use Set variable, give it a name and a value, then use Get variable later in the same run to read it.
Do Make.com variables persist between runs?
No. Variables set with Set variable last only for the cycle or execution you choose. Use a data store to keep values between runs.
What is a data store in Make.com?
A data store is a small table inside Make where scenarios can add, get, search, update and delete records that persist across runs and scenarios.
Are Make.com data stores free?
Data stores are available on the free plan with a small storage allowance, according to Make's pricing page. Larger storage comes with higher credit allowances.