Governed datasets

Prepare a dataset once. Control how its definition changes.

Create a reusable dataset for analysis and reporting. Compare versions of its query and columns, keep the source reference, and choose when a report adopts a changed definition.

See how reports use datasets

Turn a useful query into a reusable dataset.

Keep a dataset's source, query, columns, meaning and lifecycle together with fixed versions of its definition. A saved query remains an editable working draft; a report records how the dataset will be analysed.

Change a definition without silently changing existing reports.

Changes to a dataset's SQL, joins, source, structure or column metadata create a new version. Metrics, row-access rules and report permissions remain separately managed. Existing report versions keep their accepted dataset version until a user validates and saves a new report version.

Distinguish a saved definition from a historical data snapshot.

A versioned query can read newer source records on its next run. Keeping the same definition does not freeze the underlying rows. Reconstructing an exact historical result requires its execution hash and retained result, or an explicitly stored data snapshot.

Review what changed before accepting the next version.

Compare SQL, columns, types and recorded source relationships side by side. See what was added, removed or changed, and where information is unavailable. The comparison does not infer downstream business effects for relationships that have not been recorded.

Keep the data definition separate from the way it is analysed.

Datasets manage the reusable data asset and its versions. Analytics manages metrics, row-level access, report permissions, analytical requests and report execution. This separation makes it possible to review a data change without confusing it with a change in reporting or access.

Turn a useful query into a reusable dataset.

Create a dataset from SQL Console execution, a saved query, a physical table or a controlled transformation.

Keep the known column structure and profiling information with the exact dataset version.

Creating a dataset from SQL Console also makes its analytical description available to Analytics, while dataset ownership and analytical rules stay separate.

Change a definition without silently changing existing reports.

Report v4 → Dataset v2 · Report v5 → Dataset v2 · Report v6 → Dataset v3

Distinguish a saved definition from a historical data snapshot.

Review what changed before accepting the next version.

Exact identities of both compared versions and a SHA-256 fingerprint of their SQL

SQL changes shown by line, including additions and removals

Changes to columns, types, whether empty values are allowed and other known metadata

Clear unchanged, changed, added, removed and unavailable states

Keep the data definition separate from the way it is analysed.

Adopt a new dataset version through a deliberate review.

Compare the definition, validate dimensions and metrics, and preview the generated query before saving a report against a new dataset version. The decision is explicit. Earlier report versions and runs keep their original dataset references.

Compare dataset versions 2 and 3.
Review the changed SQL, columns and types.
Open a report draft using dataset version 3.
Validate the metadata and prepare a read-only query.
Preview using current permissions and row-access rules.
After acceptance, save report version 6 linked to dataset version 3.

Business situations

See the example

Who qualifies for this benefit?

Connect membership, previous benefit use and contact rules. Separate candidates, exclusions and cases needing review, with a reason for each.

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 flow

In brief

What does this part of advanexus do?