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

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

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

They store values that can be:

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.

Admins can assign and persist Global Parameters directly on user profiles from the admin portal, a fast alternative to managing user-specific parameters via actions or API. Not only is UI editing supported, but also bulk upload via CSV/XLSX.

Use cases:

• Pre-filter data per user (e.g. region, team, customer)

• Personalised row-level access for embedded and internal analytics without reliance on database user/role linking

• Default dashboard settings or layout per user

• Auto-scoped operational dashboards (e.g. a manager only sees their stores on open)

• Feature flags to control beta access or workbook variants by user

• Sales and customer success views preloaded with their own account portfolio

The user-parameter is automatically linked to any parameters of the same name and type. For example, in the semantic layer.

[1] Setup the user parameter

[2] Set a table filter, using a the same parameter name in the Semantic Layer.

This will pass any user-level parameter values, where the parameter name is the same.

An example structure for file upload is as follows:

Measure parameters open an opportunity for end-users to change the result of a measure by changing the parameter values.

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:

What it does

When the view runs, Astrato swaps in the actual values — from users, variables, controls, or defaults — to generate the final query.

How it works

Example

A view with source: SELECT * FROM users WHERE age > {min_age:int} AND status = {user_status:string}

Parameters:

This allows one reusable view to power many scenarios — filters, what-if inputs, user-personalised data slices — all without duplicating SQL.

In each object, you can link a variable (or hardcode a value) to each parameter you have in use.

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

Use identical names for variables and parameters.

Why:

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