Introduction
Filtering narrows down the data available in a workbook to aid focused analysis and to help answer specific business questions.
Helpful links
Filter Types
In Astrato the filtering capabilities help you create visual data stories and experiences with ease.
Semantic Layer Filters - Global Data Reduction
Astrato's Semantic Layer offers the option to apply a filter across all tables (applying a join), even if that table is not required in analytics/visualization result data. This extends the data reduction capability by always checking against data reduction lookups, to ensure users are always served the most relevant data.
You can enable this by using the "Apply across joins" option, on any table which has a filter applied.
Global filters (Workbook Filters)
Global filters apply across the entire workbook session for each user. If a user selects a year, all data in the workbook reflects this - unless a chart filter or measure filter has a rule that takes precedence.
Chart Filters
Want to set an object to look at specific criteria, like a date range or region - then chart filters are what you are looking for! Chart filters enable setting permanent filters for specific objects. This is accessed from the Filters tab.
Each filter has a plus sign (+) beside it, click the + to add more filters to an object.
To add chart filters to an object, select the field, operator, and value. Once completed, click the Apply button to confirm. Repeat the process with additional measure filters.
Measure Filters
Thinking of creating a comparison between measures containing different filter criteria? Measure filters are what you need. Compare sales between listed partners, and business units, all in measure filters, without needing to create new fields or groupings in your source data.
The example below shows revenue in two ways the first is revenue from won deals, and the second is potential revenue, from deals expected to be won this month.
The number in brackets next to the measure filter title indicates the number of measures that have filters applied.
Parameterized View Filtering (private preview for OEM users)
With parameterized views, you can build dynamic, user-driven queries without rewriting SQL each time.
Custom SQL statements can be created with parameters inside your view. When the view runs, Astrato swaps in the actual values — from users, variables, controls, or defaults — to generate the final query.
How it works
Supported for Custom SQL views (sourceType: "statement").
Declare parameters inline using {name:type} — e.g. {store_id:int}, {from_date:date}.
Types include string, int, float, boolean, date, and more.
Astrato auto-parses all parameters and handles substitution at runtime.
Example
A view with source:
SELECT * FROM users WHERE age > {min_age:int} AND status = {user_status:string}
Parameters:
min_age:
intuser_status:
string
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.
Filter bar
Enabling and configuring the filter bar
The filter bar is enabled automatically on new workbooks. To show or hide the filter bar, go to Workbook settings and use the field to select to hide or show the filter bar.
The filter bar can be styled to suit your workbook background. If you've set an image or color on your worksheet, the filter bar can blend in seamlessly by adjusting the Opacity or Background blur with an image or color on your worksheet.
Editable fields
The filter bar visible at the top of the worksheet is now enhanced with editable fields to simplify and speed up data analysis for you, and the teams you share your data with. The drop-down lists have a check mark beside the filters applied to the data object.
Select the filters you want, and a checkmark displays which filters are active on the data object.
Filter Object
The filter object enables end-users to quickly narrow down the global filter state across the workbook.
Measures and progress bars help visualize the general make-up of your data, helping you select right-first-time filters on the data that matters.
ℹ Filters are not synchronized across browser tabs
Tip: Enable Quickselect to bypass the apply/cancel buttons.
Date Picker
The date picker object enables users to select a range of dates easily.
Date Picker Settings
Collapsed\Expanded
Set the default display for the date picker.
Collapsed -Expanded-
Single day \ Range
Set the selection behavior of the date picker.
Week Start Day
Set the weekday for the start of the week display
Color
Set the color for the selected dates.
Slider
The slider filter is great for continuous numeric fields; users can easily pick a range of values. Furthermore, by showing the distribution of values, users can focus on the meaningful parts of the data.
The image shows a slider with a selection made. The overall distribution is visible, and the selected range is highlighted in blue.
Slider Settings
Data
Dimension
The dimension can be either a numeric field or a date field.
Custom min and max-
You can set the custom range manually. By default, it will be between the minimal and maximal values in the dimension field.Step distance-
You can set the unit for each step; for the date field, the step options are predefined.
Distribution bars
Display a bar above the values showing the significance of each range of values.
*distribution bars only work for numeric dimensions.Number of bars-
Set the number of bars for the display manually.
Style
Slider
Control the display of the labels.
Color
Set the coloring of the distribution bars
Object
Set the display of the slider object and borders.
Always One Selected Value
This feature lets you lock important filters so they always have exactly one value selected. It prevents reports from ever falling into an “unfiltered” or “multi-select” state.
Locked Filters
Locked Filters give report designers more control over how people use dashboards. They let you fix important filters in place so viewers can explore data safely without changing key context.
Think of it as guardrails for analytics. You decide which fields must stay fixed and which ones users can play with.
This feature is built for two main needs: visual data reduction and guided experiences. |
What it does
You can mark specific fields in a workbook as Always One Selected.
Once enabled:
The field must always have one active value
Users cannot clear it
Users cannot select multiple values
“Clear all filters” will ignore this field
If it’s the only filter, the Clear All button disappears
This keeps key business context locked in place.
How it works in the UI
Setup location
Workbook Panel → Filtering section → Always One Selected Fields
Two inputs are used:
Field selector – choose the dimension or filter field
Default value input – define the value that should always be selected
It uses the same style component as “Hidden Fields” for consistency.
Visual behavior
The filter chips in filter bars, cannot be removed when a single value is forced
Fields can be hidden using the dedicated "hide fields" setting in the filter bar
The normal “X” icon is replaced with a check-in-circle icon
Users cannot clear the field or remove it from the filter bar
Clear All ignores these fields completely
This makes it obvious which filters are mandatory.
Common Use Cases
Single Customer DashboardsYou embed a dashboard for a specific account.
Perfect for customer portals. | Region-locked ReportingYou want each user to stay in their own region:
Great for compliance and data security. | Parameter-driven AppsDashboards that must always be scoped to:
Ensures context is never lost. |
Use this for:
Core business context fields
Security-sensitive dimensions
Embedded analytics
Multi-tenant applications
Executive dashboards with strict scope
Filters in Astrato: SQL reference
Filters in Astrato are not one thing. Each kind does a different job, and each one maps to a different SQL clause. Knowing which filter to reach for, and where it sits in the query, is how you build fast, trusted reports without waste.
At a glance
There are four places a filter can live in Astrato's generated SQL:
Semantic layer table filter:
WHEREat the base table, before any joinChart filter:
WHEREon the joined resultMeasure filter:
CASE WHEN THENinside the aggregationResult filter:
HAVING, after the aggregation
Workbook filters, the filter bar, locked filters, date pickers and sliders all feed into one of these. They are how users set the values; the four clauses above are where those values land.
The SQL behind each filter
1. Semantic layer table filter = WHERE (before joins)
Runs at the lowest level. Shrinks the source table first. Then the join happens.
sql
SELECT c.region, SUM(s.sales_amount) AS total_sales FROM ( SELECT * FROM sales WHERE region_group = 'EMEA' -- semantic layer table filter ) s JOIN customers c ON s.customer_id = c.id GROUP BY c.region;
With "Apply across joins" switched on, that same filter rides along every related table, so data reduction stays global.
2. Chart filter = WHERE (on the joined result)
Applied after the joins, on the rows the chart consumes.
sql
SELECT c.region, SUM(s.sales_amount) AS total_sales FROM sales s JOIN customers c ON s.customer_id = c.id WHERE s.sale_date >= '2024-01-01' -- chart filter GROUP BY c.region;
3. Measure filter = CASE WHEN THEN (inside the aggregation)
Two measures, two rules, one chart.
sql
SELECT close_month, SUM(CASE WHEN deal_status = 'Won' THEN revenue END) AS won_revenue, SUM(CASE WHEN deal_status = 'Expected' THEN revenue END) AS expected_revenue FROM opportunities GROUP BY close_month;
4. Result filter = HAVING (after the aggregation)
For tests on the aggregate value, not on the rows.
sql
SELECT region, SUM(sales_amount) AS total_sales FROM sales GROUP BY region HAVING SUM(sales_amount) > 1000000; -- result filter
A worked sales example
One business question, four filter types at work.
"For EMEA base data only, show me regions with total sales above one million on premium products sold in 2024, split by won and expected revenue."
sql
SELECT c.region, SUM(CASE WHEN s.deal_status = 'Won' THEN s.revenue END) AS won_revenue, -- measure filter SUM(CASE WHEN s.deal_status = 'Expected' THEN s.revenue END) AS expected_revenue -- measure filter FROM ( SELECT * FROM sales WHERE region_group = 'EMEA' -- semantic layer table filter (before join) ) s JOIN customers c ON s.customer_id = c.id WHERE s.product_type = 'Premium' -- chart filter AND s.sale_date BETWEEN '2024-01-01' AND '2024-12-31' -- chart filter GROUP BY c.region HAVING SUM(s.revenue) > 1000000; -- result filter
Read it bottom to top if you like: the semantic layer filter cut the rows first, the join brought customers in, chart filters shaped the slice, the measure filters split the aggregate into two views, and the result filter kept only the regions worth talking about.
Quick guide: which filter, when?
Use this as a reach-for rule.
Trimming the source table before joins: semantic layer filter, with Apply across joins where the filter should be global.
Narrowing one chart to a slice: chart filter.
Different rules per measure on the same chart: measure filter.
Testing the aggregate itself, not the rows: result filter.
Global, whole-session context: workbook filter (filter bar, filter object, date picker, slider).
Fixed context for embed or multi-tenant: locked filters and Always One Selected.
Dynamic SQL with user values baked into the query: parameterized view.
Performance notes
A short list worth pinning above your desk.
Push down. The earlier a filter runs, the less data every later step touches.
Watch fan-out. Joins that multiply rows are where chart filters alone start to mislead totals. Move that rule into the semantic layer.
Keep Apply across joins on for anything that defines the analysis context (tenant, region, entitlement). Off for one-off questions.
Measure filters are cheap. They run inside the same aggregation pass, no extra scan.
Result filters are honest but blunt. They cannot shrink the work done before the group, only the rows returned after it.
Parameterized views are a scalpel for OEM and embed cases. Use them when the SQL itself needs to change, not just its inputs.
FAQ
Which filter runs first?
Answer: Semantic layer table filters. They sit at the base of the stack and run before any join. Because of this, they cut the data before Astrato stitches tables together, and every later step has less to carry.
Does the order of filters affect performance?
Answer: Yes, and often a lot. A filter that runs early trims rows sooner. A filter that runs late still has to pull those rows into the join or the group before it can remove them. For large fact tables and fan-out joins, push filters down into the semantic layer wherever you can. The "Apply across joins" switch is built for this.
What does "Apply across joins" actually do?
Answer: It lifts a single table filter so it rides along every query that touches a related table, even when that table is not in the chart. This extends data reduction to the whole workbook, not just one object, and keeps answers consistent across every view.
Will a chart filter replace a workbook filter?
Answer: No. The two stack. Workbook filters set the stage for the whole session. Chart filters narrow one object further. A user pick at workbook level plus a rule on one chart combine; neither cancels the other out.
When do I use a measure filter and not a chart filter?
Answer: When two measures on the same chart need different rules. Chart filters narrow the whole object. Measure filters split the logic inside, so you can show "won revenue" and "expected revenue" side by side, each with its own gate, without adding new columns or groupings to your source.
What is a result filter, and why can it not be a chart filter?
Answer: A result filter is a rule on the aggregated value, not on the rows. "Show regions where total sales pass one million." That test only makes sense after SUM has run, so it belongs in HAVING. A WHERE clause would never see the total.
Why are my totals off when I use a chart filter on a joined table?
Answer: Chart filters apply after the join. If the join fans out rows, the filter still works, but your aggregates may not match what the business expects. The fix is usually a semantic layer table filter, applied before the join, so the rows that cause the fan-out never enter the mix.
Can locked filters and Always One Selected be combined?
Answer: Yes. Locked filters pin state. Always One Selected stops a field ever sitting empty or multi-select. Put together, they are ideal for customer portals, region gated reports, and single-tenant embeds where context must never drift.
Are filters shared across browser tabs?
Answer: No. Each tab holds its own filter state. Treat each tab as its own analysis.
How do parameterized views fit in?
Answer: Parameterized views push filter values into the SQL of a custom view at run time. The value is written into the query itself, not added later as a WHERE. Use them for OEM cases, multi-tenant apps, and what-if inputs where the SQL needs to change shape with the user.
Do filters in the filter bar behave any differently?
Answer: No. The filter bar is a surface for setting values, not a fifth filter type. Values set there flow into the same workbook-level WHERE as any other global filter.
Will chart filters clash with global filters at query time?
Answer: They combine as AND. A region chart filter and a workbook year filter produce one query with both clauses in the WHERE. If a rule on the chart contradicts a rule at the workbook level, the chart sees no rows, which is the honest answer.




















