Saved queries

A saved query is a named, reusable question about your data — written once in the visual query builder, runnable everywhere. Lookup tables, charts and the AI assistant all consume saved queries, which means a single query update propagates across every place it's used.

Why bother saving them

Three reasons:

1. Reproducibility. "Mean concentration at 4 h grouped by dose group" is a specific question. Saving it under that name means everyone in the workspace can re-ask it later, exactly the same way.
2. Surface area. A saved query becomes available as the data source for chart blocks, lookup tables, and the AI assistant. Without saving, the same logic has to be re-built in each block.
3. Update once. Change the saved query — for example, add an outlier filter — and every chart and lookup table that uses it updates next time it loads.

Two query modes

Dalea distinguishes two analytical shapes:

Traversal

Walk references between entity tables and pull rows. e.g. "Animals → their study group → its test article". Returns a row per entity with the joined fields you asked for.

Result

Aggregate measurements from a result table. e.g. "mean ± SD concentration grouped by timepoint and dose group". Returns rows per dimension combination with measurement aggregates.

You pick the mode when you create the query. Result-mode queries are the ones that drive most science charts; traversal queries are how you populate lookup tables.

Building a query

The query builder is visual — no SQL required. The four editing panels are:

1. Source

   Pick the environment and the starting table.

2. Joins (traversal mode) or dimensions (result mode)

   For traversal, follow reference columns to join in related tables. For result mode, choose which columns are dimensions (group/filter axes) and which are measurements (aggregates).

3. Filters

   Add filter chips. Filter values can be literal (dose_mg_per_kg = 30) or parametric (dose_mg_per_kg = $dose) — parametric queries accept inputs at run time.

4. Aggregates and sort

   Result mode: pick the aggregate per measurement (mean, median, SD, SEM, count, min, max, AUC). Add sort order. Optionally pin a row limit.

The builder shows a live preview of the first 50 rows as you edit, so you can sanity-check before saving.

A realistic example

For the DLA-7 PK study, a typical saved query is:

DLA-7 PK timecourse by dose group

Source: In-vivo PK environment, PK results table Mode: result Dimensions: timepoint_h, study_group (joined via the animal reference) Measurements: concentration_ug_ml → mean, SEM Filters: study_group.test_article = $article (parametric) Sort: timepoint_h ascending

This single query drives:

• the timecourse chart block in the protocol document
• a heatmap of concentration × dose × time embedded in the programme summary
• the lookup table the bench scientist watches during a fresh ELISA run
• whatever the AI assistant needs when you ask "summarise this study's PK"

If you later add a replicate filter (replicate is not null) to exclude QC failures, every consumer picks up the change.

Visibility scopes

Saved queries are workspace-scoped by default but support three visibility levels:

Promoting a query from private to workspace doesn't change the query — it just makes it discoverable.

Parametric queries

A query becomes parametric when its filters reference variables ($animal, $dose, $batch_id). When run, the query asks for the variable values via:

• A small input row at the top of the chart or lookup table
• A direct prompt in the AI chat ("which study?")
• An explicit value supplied by a parent document filter

The same query, parametrised by $study, can power separate views per study without duplication.

Tips

What's next