Skip to main content

Astrato Parameters vs Variables, and when to use them

This guide explains the difference between variables and parameters in Astrato and how they work together to create dynamic, context-aware analytics.

Piers Batchelor avatar
Written by Piers Batchelor
Updated this week

Overview

In Astrato, variables and parameters work together to make analytics dynamic and context-aware.

  • Variable = the value that can change during a user session

  • Parameter = the placeholder that receives that value inside the semantic model / SQL

Think of a parameter as the socket and the variable as the plug.

Variables

Variables drive interactivity across the workbook. Variable can also be nested inside other variables usinf $() notation, Dashboard: $(vCurrentSheet).

They store values that can be:

  • selected by a user

  • set by an action

  • controlled by embedding context

  • written back to a database

  • set to trigger actions on value update

What they control

  • Filters

  • Measures

  • Dimensions

  • Writeback context

  • Navigation & actions

  • Row-level logic (via semantic layer)

Typical use cases

  • Retrieve current customer name, group, date

  • Scenario selection

  • Currency / unit switch

  • Date comparison mode

  • “View as” user or role

  • Dynamic measure selector

  • Controlling writeback visibility

  • Toggle between chart types

  • Show / hide components

  • Storing SQL, which can be run using the Execute SQL action block


Parameters

Parameters are "placeholders" that receive a value when the paramter is used, they can utilize a default value, a custom value, or a value linked to a variable. Parameters are available in custom SQL and in measures created in the Semantic Layer.

Measure Parameters

SQL Parameters (and why they matter in Astrato)

Using parameters in SQL gives you control, speed, and safety. Parameters turn SQL from fixed code into a flexible engine that users can control.

Here are the real, practical wins:

One query, many uses
Write logic once and reuse it everywhere.
Change a value/filter without rewriting SQL.

Example:

  • Change date range

  • Adjust filters in real time

Faster to build and maintain
Instead of 10 almost-identical queries, you have 1 smart query.

Less code = fewer bugs and less upkeep.

Better performance
Instead of running big generic queries and filtering after, parameters push filters into the SQL itself.

That means:

  • Smaller result sets

  • Faster queries

  • Less warehouse cost

  • Better pruning on clustered tables


How they work together

  1. Variable gets a value in the workbook

  2. Variable is mapped to a parameter

  3. Parameter injects the value into the semantic model query

If a parameter is not mapped, its default value is used.

Naming best practice

Use identical names for variables and parameters.

Why:

  • Avoid manual mapping

  • Prevent falling back to default parameter values

  • Faster model setup

  • Lower risk of deployment mistakes

If names differ → manual mapping is required (works fine, easier to forget).

Did this answer your question?