Parameters
A parameter turns a fixed value in your SQL into a named placeholder that’s filled in at run time, so the same saved query serves different filter values instead of being copy-pasted per value.
Referencing a parameter
Write {{ name }} anywhere in your SQL. The first time arcodash sees a new {{ name }} token, it
prompts you to configure that parameter — pick its type and, for some types, its options — and an
input for it appears above the editor from then on.
[!NOTE] A
{{ name }}token that has no matching parameter definition is a hard error when the query runs, not a silently blank substitution — if you rename a parameter, update every{{ }}token that references it.
There are exactly 7 parameter types. One subsection per type follows, with its substitution syntax and behavior.
Text
WHERE customer_name = '{{ name }}'The raw string value is dropped into the SQL exactly as typed, unescaped — you’re responsible for quoting it, the same as any hand-written string literal.
[!TIP] Because a Text parameter’s value is substituted raw, running a query that uses one requires manage access to its data source, not just execute permission — anyone who could set the value could otherwise run arbitrary SQL through it. The same restriction applies to a Query-based Dropdown, since its option list is also sourced from a query rather than a fixed, checkable set of values. A plain
Dropdownparameter only ever substitutes one of its own predefined options, so it doesn’t carry that risk and isn’t restricted this way.
Number
LIMIT {{ row_limit }}Renders the value as a plain numeric literal — no quotes.
Date
WHERE created_at::date = '{{ report_date }}'Renders an ISO YYYY-MM-DD string, dropped in as-is.
Date Range
WHERE created_at BETWEEN '{{ window.start }}' AND '{{ window.end }}'A range parameter’s value is a {start, end} pair, so it can’t be referenced with a bare
{{ window }} — use the .start / .end accessors to pull out each half. Both render as ISO
YYYY-MM-DD dates.
Date/Time Range
WHERE event_ts BETWEEN '{{ window.start }}' AND '{{ window.end }}'Same {start, end} shape and .start/.end syntax as Date Range, but with datetime-precision
values instead of plain dates.
Dropdown
WHERE region = '{{ region }}'Value comes from a fixed list of options you type in when configuring the parameter (one per
line). Enable Allow multiple values to let a user select several at once — the selected
values are joined into the SQL as a comma-separated, quoted list, so {{ region }} used inside
IN ({{ region }}) becomes IN ('us', 'eu').
Query-based Dropdown
WHERE product_id = {{ product }}Same as Dropdown, except the option list is sourced from another saved query’s result instead of
a typed-in list — pick which query when configuring the parameter. Useful for a filter whose
valid values live in the database itself (e.g. every product currently in a products table)
rather than a list you’d have to keep in sync by hand.
[!NOTE] A Query-based Dropdown can’t load its options until the query it belongs to has been saved at least once — the source query is referenced by id.
[!NOTE] This restriction is about who’s allowed to run a query with a live Text or Query-based Dropdown parameter — it has nothing to do with public or embed links. Neither of those ever re-executes a query; both only ever serve an object’s already-cached result, so there’s no parameter value to substitute on that path at all. See Public links for what a public link actually shows.
Where to go next
- Scheduled refresh — parameterized queries need fixed values to run unattended on a schedule.
- Versions, drafts, and publishing — parameter definitions are part of a query’s draft/published content like everything else.