Save dimensions, metrics, aggregations, charts, filters, interactions and dataset versions as one fixed report version. Applying a filter when viewing a report creates a new execution context, without silently changing its saved definition.
Controlled analytics
Show the numbers. Explain the result behind them.
Build reports and charts from an accepted dataset version. Explore dimensions and filters, then return to the saved report definition and run context when someone asks how a result was obtained.
Choose authorized columns and metrics; the platform validates the request and prepares a read-only SQL query. Filters applied in the browser cannot replace the protected rules that determine which rows the user may access.
Use bars, lines, areas, scatter plots, pie and donut charts, tables, KPIs and multiple series. Keep time grouping, comparisons, drill-down, reference lines and Top N with a consistent Other category in the saved chart definition, with an accessible alternative view.
Each run retains versions, status, filters, access scope, row count, diagnostics and result files. A report with several dataset bindings runs them in sequence and shows each outcome. Overlay, union and merge behavior must be configured explicitly; relationships are not guessed.
Each dashboard and widget run stays linked to its report and execution record. A failed widget can remain visible alongside successful ones, so the dashboard does not hide an exception or present incomplete work as complete.
Retained samples, profiles, charts, results and diagnostics keep integrity checks, size, retention and origin. Local and S3 reads are bounded and integrity-checked; public links conceal storage paths. Cached results distinguish dataset and report versions, permissions, row access, chart settings, execution rules, limits and query parameters.
Keep saved results linked to their report definition.
Save dimensions, metrics, aggregations, charts, filters, interactions and dataset versions as one fixed report version. Applying a filter when viewing a report creates a new execution context, without silently changing its saved definition.
Explore results within the user's current access.
Choose authorized columns and metrics; the platform validates the request and prepares a read-only SQL query. Filters applied in the browser cannot replace the protected rules that determine which rows the user may access.
Choose the view that explains the business question.
Use bars, lines, areas, scatter plots, pie and donut charts, tables, KPIs and multiple series. Keep time grouping, comparisons, drill-down, reference lines and Top N with a consistent Other category in the saved chart definition, with an accessible alternative view.
Filter operators and input formats follow the type of the selected column.
Inspect the data with limited pages, sorting and selected columns without redefining the saved report.
Export limited CSV, JSON and image results with their origin and any truncation recorded.
Automatic refresh records a new run instead of changing the saved report version.
See partial results without mistaking them for full success.
Each run retains versions, status, filters, access scope, row count, diagnostics and result files. A report with several dataset bindings runs them in sequence and shows each outcome. Overlay, union and merge behavior must be configured explicitly; relationships are not guessed.
Execution records support duplicate-request protection, bounded retries, timeouts, cancellation and recovery of abandoned runs.
Follow recorded progress live, with periodic updates when streaming is unavailable.
Each failed dataset binding keeps its own safe diagnostic; another successful result does not make the whole run successful.
Reuse results without losing their origin or access rules.
Retained samples, profiles, charts, results and diagnostics keep integrity checks, size, retention and origin. Local and S3 reads are bounded and integrity-checked; public links conceal storage paths. Cached results distinguish dataset and report versions, permissions, row access, chart settings, execution rules, limits and query parameters.
Check the supported route from source to report.
Dataset-based report queries currently target PostgreSQL. Other source families need a supported materialized dataset or an appropriate dialect adapter. Having a connector does not by itself mean that a source can follow this analytical path.
Next step
Start with the flow that cannot afford ambiguity.
Bring the systems, owners, rules, delivery obligations and evidence requirements that matter.
Discuss a critical flowIn brief
What does this part of advanexus do?
Build reports and charts from an accepted dataset version. Explore dimensions and filters, then return to the saved report definition and run context when someone asks how a result was obtained.
What should I check before using it?
Other sources require an accepted materialization or dialect-adapter path.