A catalog is only as useful as what is written in it. SelectZero’s AI enrichment drafts that writing for you. Descriptions for catalog objects and their attributes, related glossary terms, and values for custom fields. It runs on the objects you select in the catalog, across connections, and nothing is applied until a person has reviewed each suggestion.

The problem

Most catalogs start out as a list of names. After the first metadata sync there are thousands of tables and columns, and almost none of them say what they hold. The description on fct_payments.amount is empty. Nobody has linked customer.email to the glossary term that defines it. The PII flag your data protection officer asked for exists as a custom field, but it has been filled in for a few dozen columns out of several thousand.

Filling that in by hand is weeks of steward time, and it rarely finishes before the next source is connected. Until it does, searching by business term returns little, and the catalog is not context anyone can rely on, whether that is an analyst or an AI assistant.

What enrichment does

For each selected object and its attributes, enrichment suggests:

• Descriptions for the object and for every attribute.
• Related glossary terms, drawn only from the terms already defined in your business glossary.
• Values for custom fields, for example a domain on a table or a PII or CDE flag on a column, for whichever custom fields your organisation has defined.

Suggestions are built from context the platform already holds: technical metadata, profiling and sampled values, and related glossary terms. Every suggestion is shown next to the current value and is reviewed and applied one at a time. A steward can accept a description, keep the existing domain and drop one of two proposed terms in the same pass.

Use cases

• Onboarding a new source. A data engineer connects a new warehouse schema, selects its tables and runs enrichment. Stewards start from a reviewed draft instead of an empty page.
• Flagging critical data elements. A governance lead wants every column in mart_credit_exposure marked as CDE or not. Enrichment proposes a value per column, the steward confirms or corrects it, and the flag becomes searchable across the catalog.
• Connecting the glossary to physical data. The term Customer is defined but linked to nothing. Running enrichment across the warehouse and CRM connections suggests it on the matching columns, so the term’s Assets tab shows where the concept actually lives.

How to run it

1. In the Catalog view, select the objects to enrich in the catalog and click “Enrich”
   • Or open an individual object click “Enrich”
2. Define the fields to enrich and add context if needed
3. Review each suggestion and compare against the current value.
4. Apply the selected suggestions.

If you want to try it out, start with one schema nobody has documented yet. The review queue will quickly show how much writing your stewards no longer start from scratch, and how much your glossary is carrying. If the suggestions come back thin, that tells you where to invest next.

SelectZero 2026.8 is centred on access control and lineage. Roles now behave the way regulated environments expect them to, with visibility scoped down to the individual database and schema, and directory groups can drive role membership directly. Lineage becomes substantially more complete for calculated and aggregated columns. Around those, the AI assistant, alerting and the dbt integration each gain flexibility.

Lineage can now connect two columns of the same table or view, for example a total derived from its sibling columns or a self join, shown as brackets inside the object’s node in the graph. Calculated columns are also covered: when a result column is built with SUM, arithmetic, ROUND, COALESCE or CASE, every input column is linked to that one output column, where previously such expressions produced no lineage at all.

A privilege granted by a role now applies only to the connections that the same role allows. Previously a user with a read-only role on one database and an editing role on another could edit on both. That combination no longer grants extra rights, and profiling results, sample data and test results are restricted the same way.

Each schema within a connection can now be limited to selected roles. A role without access to a schema does not see it in the catalog, in profiling or when generating tests.

Until now single sign-on, whether AD/LDAP or OAuth providers such as Entra ID, could only assign one default role to every user who logged in. Directory groups can now be mapped to existing SelectZero roles, so a user’s access is derived from their group membership rather than set by hand after first login.

Alerts for a single test case can now include the list of rows that failed the check, not just the count. Previously that list was only available in test suite reports.

The AI assistant, which drafts test-case suggestions and catalog descriptions, can now run on Anthropic or Google Gemini alongside OpenAI, Azure OpenAI and Ollama. Both are selected as the API type in Settings and authenticate with an API key.

SelectZero 2026.7 is one of the broadest releases so far, reaching nearly every part of the platform. The interface has been rebuilt end to end, and profiling takes a significant step forward in how it detects change. Automation across the catalog and glossary goes deeper, while alerting and source coverage both widen.

All views now share one layout, with the same navigation, tables, filters and detail panels throughout, so a pattern learned in one place holds everywhere. The whole platform is quicker to work in and simpler to manage.

Enrichment now suggests related glossary terms and values for custom fields alongside descriptions, each reviewed and applied one suggestion at a time. Terms are drawn from those already defined in the glossary, and enrichment runs on the objects selected in the catalog, across connections.

Seasonal forecasting joins the existing prediction models in profiling, which tracks the shape of a table over time, so thresholds follow a predicted band per object instead of a fixed allowed-change percentage and a recurring weekly peak stops reading as an anomaly. Past days can be backfilled in the background, and profiled rules are easier to add, search and manage.

Drilldown on any tile with a quality score opens the entities contributing to it, so the number can be traced to the checks that produced it. Layout is more versatile as well: tile height is now adjustable alongside width, and tiles can sit anywhere on the grid. Executions, Schedule and Alerts have become manageable tiles, and a new Entity details tile tracks a single object.

The term graph can be switched to a mode where each term appears exactly once and can sit under several parents as well as children, with movable nodes and search to jump straight to a single term.

A business rule can be linked to a dynamic rule and to any number of glossary terms, and test cases can be generated from the rule modal for each term-linked attribute. Attributes that already have a matching test case are excluded from the suggestions.

Catalog objects gain a Data tab that fetches a read-only sample from the source on demand and caches it encrypted. Viewing and refreshing are separate privileges, and sampled values can feed per-column context into AI enrichment.

Filters on the main list pages are retained automatically, so an earlier set can be brought back instead of rebuilt. A set can also be saved deliberately or copied as a link and passed to a colleague.

Alerts can be configured for a whole schema rather than object by object, triggering when an object is created, changed or deleted within it.

Metadata and lineage from the SAP BusinessObjects BI platform can be read into the catalog alongside database sources.

Most organizations don’t have a data quality problem in just one system, they have one spread across ten different databases, dashboards, and pipelines that nobody fully understands anymore. SelectZero exists to close that gap: a single platform for validating, cataloging, and tracing data across every system it touches, built to be usable by data engineers and business teams alike.

Over time, G2 users have backed that up independently. SelectZero was recognised as a High Performer across six categories in G2’s Summer 2026 reports, covering both Data Governance and Data Quality, with our strongest results coming from Europe, where we ranked #4 in Data Quality and #8 in Data Governance across the region. G2 rankings are based entirely on verified customer reviews, so these results reflect what our users actually experience day to day. Here’s a closer look at what customers say they value most, and separately, where the broader data quality and governance market is headed next.

What our users value

Across reviews, a consistent set of strengths comes up again and again, regardless of company size or industry.

• Early detection, clear diagnosis. Reviewers run scheduled tests that flag anomalies and schema changes before they cause damage, and when a check fails, it’s easy to pinpoint exactly what went wrong.
• Ease of use. Reviewers consistently describe SelectZero as intuitive enough for both data engineers and business users, with fast setup and no dedicated implementation project required.
• Responsive support. Fast, friendly support is the most-cited strength across reviews, often including same-day fixes and feature requests shipped in upcoming releases.
• One platform instead of multiple tools. Our users prefer to manage data quality, governance, glossary, and lineage across multiple systems in a single place, rather than stitching together point solutions.

Why this matters for your data stack

A few broader shifts are reshaping the data quality and governance market in 2026, which is why it’s worth knowing SelectZero already delivers on several of them.

• AI-ready, agent-accessible data. With trust in data quality now a top blocker for AI initiatives, SelectZero’s new MCP server puts its catalog and lineage directly in front of AI clients like Claude and Cursor, meeting a demand that’s only growing.
• Modern data stack integration. Native lineage capture from tools like dbt is becoming table stakes for governance platforms, and SelectZero’s dbt Core and dbt Cloud integration keeps it aligned with how modern data teams actually work.
• End-to-end lineage and a shared business glossary. Analyst buying guides repeatedly flag these as must-haves for real data trust, and they remain core, well-reviewed strengths of the platform.

If you want to see what our users are saying, head over to our G2 profile. Or if you’re ready to see SelectZero in action, book a demo to see how SelectZero fits into your data stack.

When you monitor data quality, finding out that something is wrong is only the beginning. The harder question is what is wrong. Is this a brand-new problem that appeared overnight or a recurring issue you thought you’d fixed last week? A single pass/fail result can’t tell you any of that. To answer it, teams have traditionally exported results from two runs and compared them by hand, row by row, which is slow, error-prone, and the kind of work nobody does consistently.

SelectZero answers the question for you with tracking row-level differences.

What are row-level differences?

Test case results show the differences between the previous and the latest execution, directly in the execution history. Every run is automatically compared against the one before it, and each invalid row is classified into one of three states:

• New – issues that appeared in the latest run and weren’t there before.
• Resolved – rows that were flagged previously but are now valid.
• Active – issues that persist across runs and are still unresolved.

Instead of a single number that went up or down, you get a clear, row-level picture of exactly what changed since last time, and you get it without leaving the platform or cross-referencing spreadsheets.

What is the impact

You can tell whether a fix actually worked. When a team addresses a data quality issue, the obvious question is “did that resolve it?” The difference view answers it directly: the affected rows move into the Resolved state, or they don’t. No guesswork, no manual reconciliation.

You catch regressions and slow deterioration early. A check that’s been passing can start failing again, or a known issue can quietly get worse run over run. Because new and active problems are separated out, a recurring issue stops hiding inside an aggregate count and surfaces as soon as it reappears.

You spot the unexpected overnight. New rows flagged between one run and the next are exactly the early warning that something upstream changed, before it propagates into reports, models, or regulatory submissions.

For teams running complex pipelines or high data volumes, this is the shift from reactive firefighting to proactive quality management. You’re no longer just reacting to a red status, you’re tracking the trajectory of every issue over time and acting on what genuinely changed.

The outcome

Knowing that a data quality check failed tells you to look. Knowing what has changed since last time tells you what to do. Row-level execution differences turn each data validation into a running record of progress, so your team can confirm fixes, catch recurring problems, and stay ahead of new ones.

Want to see it in action? Explore SelectZero in the sandbox and walk through execution history on a sample test case, no setup required.

SelectZero now ingests metadata from both dbt Core and dbt Cloud. Your dbt models, sources, seeds, snapshots, tests, and lineage flow into the SelectZero catalog and merge with metadata from every other system you connect – your BI tools, ETL jobs, operational databases, and warehouses. dbt teams get a single place to see how their models are actually used downstream. Data teams outside dbt get visibility into what dbt is doing upstream. Everyone gets one catalog, one lineage graph, one source of truth.

The problem dbt users keep running into

dbt is excellent at what it does. You version your transformations, test them, document them, and ship them with confidence. The dbt docs site gives you a clean view of your project: models, sources, tests, lineage between them.

But your dbt project is not the whole picture. It is a slice in the middle.

Upstream, data arrives from operational databases, SaaS systems, files, message queues, and CDC pipelines. Downstream, your models feed dashboards, reports, reverse-ETL jobs, ML pipelines, and exports to other teams. dbt sees the part it owns. It does not see where the source tables actually come from, and it does not see where the marts actually end up.

This creates familiar pain:

• An analyst changes a column in a core model and breaks a Power BI report nobody linked to the dbt project.
• A platform team deprecates a source table without realising six dbt models depend on it.
• Compliance asks “where does this PII column end up” and dbt docs can answer for the warehouse but not for the BI layer or the export jobs.
• New engineers spend weeks learning which dbt models are actually important versus abandoned.

dbt docs solve the in-project problem. SelectZero solves the cross-system problem.

What the integration actually does

SelectZero connects to your dbt project and ingests the standard dbt artifacts: manifest.json, run_results.json, and catalog.json. For dbt Cloud, we pull these from the Cloud Admin API and enrich them with metadata from the Discovery (GraphQL) API, using a service token. For dbt Core, we read the same three artifacts from S3 or any S3-compatible object store – point your CI job at a bucket and we’ll pick them up from there.

From those artifacts we extract:

• Models, sources, seeds, and snapshots as first-class catalog objects, tagged with their dbt project, schema, and materialization.
• Column-level lineage linking each dbt model to the warehouse table it materialises and through to its upstream sources and downstream consumers, so a column in a mart connects back through staging to the raw source it came from.
• Tests registered as SelectZero test cases, with the latest pass/fail outcomes pulled from run_results.json so dbt test history shows up next to the rest of your data-quality runs.
• Source freshness captured from the manifest and attached to the source.
• Descriptions, tags, and meta fields from your schema.yml files (merged with column comments from catalog.json), so the documentation you already wrote shows up in the catalog without duplication.

The result is that every dbt object appears in the SelectZero catalog with a dbt badge, and its lineage connects on both sides: backwards into the warehouse tables and operational sources that feed it, forwards into the BI dashboards, reports, and downstream consumers that depend on it.

The built-in dbt Explorer

Alongside the unified catalog view, SelectZero ships a dedicated dbt explorer: a tree of every model, source, seed, snapshot, and test in your project, grouped by type, with a detail panel that shows columns, dependencies, the compiled metadata, and the latest run status for whatever you click. If your team already lives in dbt docs, the explorer gives them something they recognise – but with everything else SelectZero knows about that object one click away.

Concrete value by audience

For dbt developers

You stop guessing at downstream impact. Before you change a model, you can see every Power BI report, Tableau dashboard, Looker explore, reverse-ETL sync, and ad-hoc consumer that touches the columns you are about to modify. dbt’s –defer and state comparison tell you what changed inside the project. SelectZero tells you who outside the project will feel it.

You also get a public surface for your work. The descriptions and tests you write in schema.yml are visible to business users who would never open a dbt docs site – they search the catalog, find your model, and trust it because the tests next to it are green.

For data platform and governance teams

dbt becomes a transparent part of the estate instead of a black box that produces tables. You can answer “where does customer email show up” in one query, across operational DBs, dbt models, marts, BI tools, and exports. PII tags follow dbt lineage automatically. Access reviews, retention policies, and data contracts apply uniformly whether a column lives in a source table, a dbt staging model, or a downstream report.

For BI and analyst teams

When a dashboard breaks or a number looks wrong, you trace it backwards through SelectZero’s lineage into the exact dbt model and the exact source table, with the latest test results and freshness right there. No more “ask the dbt team” tickets to find out why a metric shifted.

For leadership and compliance

One catalog covers the whole estate. Audit questions about data flow, ownership, and quality get answered from a single system instead of stitched together from dbt docs, warehouse metadata, BI tool catalogs, and tribal knowledge.

dbt test results land where the rest of your DQ lives

Every dbt test we find in the manifest is registered as a SelectZero test case against the column or model it covers. Each time we sync run_results.json we attach the latest outcomes as test-case executions, so dbt tests live in the same execution history as every other SelectZero check. Failed runs and stale models surface immediately in the catalog, not after someone notices a broken dashboard.

Row-level issues are immediately available to users with the right privileges.

dbt Core and dbt Cloud, same experience

We support both.

• dbt Cloud users provide an account ID and a service token. SelectZero pulls artifacts from the Admin API and enriches the model graph through the Discovery (GraphQL) API. Access and Discovery URLs are configurable, so regional dbt Cloud instances work out of the box.
• dbt Core users point us at an S3 or S3-compatible bucket (with an endpoint override for MinIO, R2, GCS-with-HMAC, etc.) where your CI uploads manifest.json, run_results.json, and catalog.json. No agent, no local file path, no extra service to host.

The catalog experience is identical from there. If you run a mixed setup – multiple dbt projects across Core and Cloud – they all land in the same SelectZero catalog and lineage graph.

Getting started

1. Add your dbt project in Settings → dbt. Pick dbt Cloud (account ID + service token) or Artifacts (S3 bucket + credentials), and link the warehouse connection it builds against.
2. Connect at least one upstream source (your warehouse or operational DB) and one downstream consumer (BI tool, reverse-ETL, or export job). The value of cross-system lineage scales with what is connected.
3. Open the catalog or the dbt explorer. Your dbt models are there, with tests, freshness, descriptions, and full upstream/downstream lineage.

That is the whole setup. No changes to your dbt project, no new YAML, no required tags or conventions. SelectZero reads what dbt already produces.

Closing

dbt gave the industry a great pattern for transformation. SelectZero extends that pattern across the rest of the estate. For teams running dbt who care what happens to data before it arrives and after it leaves, the integration is built for exactly that.

SelectZero now ships a built-in Model Context Protocol (MCP) server. Point Claude Desktop, Cursor, Claude Code, VS Code, or any other MCP-aware client at your SelectZero instance, and your AI assistant gets first-class access to your catalog, glossary, lineage, tests, and audit history – scoped to whatever the user behind the token is allowed to see. Twelve read-only tools and three guided “recipes” mean an analyst, engineer, or steward can have a conversation with their data stack instead of clicking through screens.

The problem

Every team is now running AI clients next to their work. Engineers live in Cursor and Claude Code. Analysts open Claude Desktop. PMs paste schemas into ChatGPT. The pattern is the same everywhere: ask a question, hope the model has enough context.

The catch is that none of these clients know anything about your data estate. They cannot tell the engineer that the column they are about to drop feeds three Power BI dashboards. They cannot tell the analyst that “customer_email” is tagged as PII and lives in eleven tables. They cannot tell the on-call engineer that the failing test was added two weeks ago by someone who has since left the company.

You end up either:

• Pasting fragments of context into prompts and hoping for the best.
• Asking the AI questions it has no way to answer, and getting confident-sounding fabrications back.
• Switching out of your AI client into a separate catalog UI, doing the lookup by hand, switching back. The exact manual work the AI was supposed to eliminate.

MCP fixes this. SelectZero now speaks it.

What the integration actually does

SelectZero embeds an MCP server directly in the Spring Boot backend. It is exposed over streamable HTTP at /api/v1/mcp, switched on from the settings page, and authenticated with Personal Access Tokens (PATs) – user-bound tokens each person generates in their own profile.

A PAT carries the user’s role. Every MCP tool call runs through the same privilege and per-connection access checks as the rest of SelectZero – if a user cannot see a connection in the UI, the MCP server will not return its objects, columns, lineage, or test cases either. The same license tier rules apply. There is no separate permissions surface to keep in sync.

The server exposes twelve read-only tools, grouped into three areas:

Catalog and metadata

• searchCatalogObjects – filtered, paginated search across tables and views, with column counts, row counts, test coverage, profiling status, and any custom fields you have configured.
• getCatalogColumns – column-level drilldown: data types, nullability, PK status, null percentage, unique count, linked glossary terms, per-column custom fields.
• getColumnLineage – one-hop column-level upstream/downstream, across connections.
• getObjectDependencies – multi-hop object lineage (1–10 hops), with direction and relation type, deduplicated to object level so downstream analysis stays readable.
• searchGlossaryTerms – search the business glossary by name or description; returns term hierarchy, linked columns, and custom field values.
• discoverCustomFields – list every custom field configured in SelectZero, by entity type, with allowed option values inline. Let the AI client adapt to your taxonomy on the fly.

Quality and audit

• searchTestCases – find data-quality checks by description, connection, target object, suite, severity, or custom field.
• getExecutionHistory – execution timeline for a specific test case, with date range and status filters.
• getAuditHistory – version history for any entity (catalog object, term, test case, column) – what changed, who changed it, when.
• getAuditSnapshot – the full JSON state of an entity at a specific audit event, so the AI can diff versions for you.

Suggestions

• suggestProfiling – deterministic, rule-based profiling suggestions derived from existing profiling history (uniqueness, value sets, patterns, bounds).
• suggestTestCases – AI-backed test suggestions, optionally scoped to columns plus a free-text hint. This is the one tool that calls out to your configured LLM (OpenAI, Azure, or Ollama) – it composes the prompt from real column schema, optional profiling examples, and optional glossary terms, and returns structured test-case suggestions. Off by default; turn it on per deployment.

Every tool is read-only. The MCP server cannot create, edit, or delete anything in SelectZero. Mutations stay in the UI and the REST API where they get the full audit treatment.

Recipes: guiding less-capable clients through multi-step workflows

Calling one tool is easy. The interesting questions need three or four tools chained together – and not every AI client is great at deciding which to call next. SelectZero ships three curated recipes, exposed as MCP Resources that any client can pull on demand:

• Root-cause analysis – start from a failing test, walk through execution history, audit history, audit snapshots, and upstream dependencies to find the change that broke things.
• Coverage gaps – discover custom fields, find catalog objects in a given domain, identify which have no tests, and propose profiling for the gaps.
• Impact analysis – given an object, find its downstream dependencies and surface the tests on each, so you know what to verify before a change.

These are not hardcoded workflows. They are markdown documents the AI reads, decides whether to apply, and adapts to your specific question. Think of them as institutional memory for how SelectZero is best used, shipped alongside the tools themselves.

Concrete use cases

Engineer about to change a column (in Cursor or Claude Code)

“I’m about to rename customer.email to customer.email_address in the orders schema. What breaks?”

The agent calls searchCatalogObjects to locate the table, getColumnLineage to find downstream columns, getObjectDependencies for the dashboards and reports that read from it, and searchTestCases for the checks it would invalidate. You get a precise impact summary in your IDE without leaving your IDE.

Analyst chasing a number (in Claude Desktop)

“The weekly revenue dashboard dropped 12% – start with mart_revenue_weekly and tell me what changed in the last seven days.”

The agent walks the root-cause recipe: latest run on tests covering that table, audit history on the model, audit snapshots to diff the SQL, upstream lineage to find a source that started returning fewer rows. End-to-end investigation, conversational.

Data steward auditing coverage

“List every table in the customer_360 domain that has no critical test, and propose what to add.”

The agent uses discoverCustomFields to find the domain field, searchCatalogObjects to filter, searchTestCases to identify gaps, and suggestProfiling (or suggestTestCases if copilot is enabled) to propose checks. A coverage audit that used to be a multi-day task becomes an afternoon.

Compliance and governance

“Show every column tagged PII across our warehouses, who owns each table, and whether each has an active test.”

discoverCustomFields → searchCatalogObjects filtered by PII tag → getCatalogColumns per match → searchTestCases per object. A single conversation produces an evidence pack instead of a multi-day spreadsheet exercise.

New team member onboarding

“Tell me everything you know about the orders table – columns, glossary terms, upstream sources, downstream consumers, current tests, recent changes.”

One question, six tools, a complete picture. The conversation transcript itself becomes onboarding documentation.

On-call during an incident

“Tests on fct_payments started failing 40 minutes ago. Walk it back.”

getExecutionHistory for the failures, getAuditHistory on the table and its upstream dbt model, getAuditSnapshot to diff the change, getObjectDependencies to scope the blast radius. The investigation runs at conversation speed.

Setup

1. In Settings → General → Modules, toggle the MCP server on. If you want AI-backed test suggestions (suggestTestCases), enable the Copilot MCP toggle as well – it requires Copilot to be configured under AI settings.
2. Have each user generate a Personal Access Token in their profile.
3. Point your MCP client at https://<your-selectzero>/api/v1/mcp with the PAT in the auth header.

That is the whole setup on our side. Whatever your AI client of choice – Claude Desktop, Claude Code, Cursor, VS Code, any MCP-aware tool – will pick up the twelve tools and three recipes automatically and start using them.

What is not in scope yet

• Read-only. Creating a test case, editing a glossary term, or tagging a column still happens in the UI. Write functionality is a future roadmap item; we want the read surface to be rock-solid first.
• No streaming tool calls. Synchronous request/response; long-running operations are not exposed yet.
• Per-tool audit logging is not separately recorded. Permissions are enforced at every call, but the existing audit log captures mutations only.

Closing

MCP turns your data catalog from a place people visit into a service every AI client can use. SelectZero already has the metadata, lineage, tests, glossary, and history – the MCP server just makes all of it available to the assistant your team is already talking to.

If your engineers, analysts, and stewards are spending half their day in an AI client, they should be talking to your catalog, not around it.

Documentation – https://selectzero.com/docs/mcp-setup.html

SelectZero 2026.5 brings the platform’s biggest expansion yet into the modern data stack, with native dbt integration, AI-powered catalog enrichment, and MCP support that opens SelectZero data to AI assistants. This release also introduces a centralised alerts view, organisation-wide guest access for broader collaboration, customisable table layouts across the platform, and a range of connectivity and lineage improvements that make daily work faster and more transparent.

SelectZero now natively integrates with dbt, ingesting manifest, catalog, and run artifacts to give teams a live, always-current view of their dbt project. A new dbt Model Catalog page lets anyone browse models, sources, seeds, and snapshots without touching the CLI or static docs. Lineage nodes show a dbt badge where a matching dbt model exists, and historical run storage keeps a full timeline of freshness, failures, and schema changes so teams can answer not just “is it working now” but “when did it break.”

Read more about SelectZero dbt integration here.

SelectZero data is now exposed as Model Context Protocol resources, making catalog metadata, lineage, test cases, and data quality results directly accessible to AI assistants and copilots. This unlocks a new class of LLM-powered workflows on top of SelectZero, from natural language queries over your catalog to automated impact analysis through your assistant of choice.

Read more about SelectZero MCP here.

Catalog object and attribute descriptions can now be generated by AI, either individually or as a mass action across multiple tables and attributes at once. Suggestions take metadata, profiling values, and related glossary terms as context, and every suggestion is shown in a preview where users can pick exactly what to apply.

A new alerts view brings every enabled alert across the platform into one place, with an admin perspective spanning all users and a personal view for end users. No more checking each test case, object, or term individually to understand what is currently being monitored and by whom.

A new user type makes it easy to give broader, view-only access across the organisation without full user provisioning. Perfect for stakeholders, auditors, or wider business teams who need visibility into data catalog and quality without becoming managed users.

Catalog page tables now supports column customisation. Choose which columns to display, reorder them via drag-and-drop, and reset to defaults at any time. Layouts persist locally, so teams can tailor each view to how they actually work.

Webhook notifications can now include a direct link to the test result report, opening either as a downloadable Excel file or as an in-browser HTML page with authentication checks in place. Teams using Slack, Teams, or Jira can jump straight from a notification to the full report, with no extra steps. The webhook configuration view has also been rebuilt with copyable parameters and ready-made samples for popular destinations.

Procedure parsing has been extended to SAP IQ, joining the existing TSQL support. Teams running SAP IQ data warehouses can now extract statements from stored procedures for lineage and validation, with no manual workarounds required.

Linked entities on business terms are now real navigable links. Clicking a linked asset, attribute, or rule takes users straight to the entity, making it faster to move between the glossary and the rest of the platform.

Lineage evidence SQLs now show when each relation was first detected, giving full transparency into the origin of every lineage edge. Stale lineage from old DDL is no longer permanent: users with manage rights can delete individual query references one by one.

OAuth providers now support a configurable default display name field, matching the existing LDAP and Active Directory experience. The login screen layout has also been refined for a cleaner sign-in flow.

Building a shared view of data quality across the public sector

Case study with Estonia’s Ministry of Education and Research

THE CUSTOMER

The Ministry of Education and Research plans national policies for education, research, youth, and language. It oversees all levels of education, from pre-primary through higher education, as well as hobby and adult learning, research and development, youth work, and the drafting of related legislation. The Ministry strategically manages several state agencies, foundations, and institutions by setting their goals, analyzing results, determining budgets, and providing supervision.

CHALLENGES

Prior to this initiative, the Estonian Ministry of Education and Research did not have a real time, consolidated view of data quality across its datasets, nor a single, centralized place for defining and managing data quality requirements. As a result, data validation was handled almost exclusively by analysts, placing the full responsibility for data quality on a limited group of specialists.

This operating model led to the increase of assumptions and differing interpretations of data and its quality. Data quality was frequently discussed and presumed, but validating or disproving these claims required significant time and manual effort. At the same time, there was a clear perception that data stakeholders lacked a shared understanding of the true state of the data. Teams expressed a need for faster access to reliable answers, reduced coordination overhead, and more consistent data checks across domains.

IMPACT

The Ministry’s data strategy aims to enable precise, evidence-based decision-making. A key prerequisite for this is the easy accessibility of necessary data and verified data quality. Using the platform allows the Ministry to conduct regular data quality checks, provide agreed-upon updates on key data quality aspects to relevant stakeholders, reduce decisions based on gut feeling or hearsay, and build greater confidence in existing data. In particular, the ability to assemble test suites is considered especially valuable.

Early results already show increased transparency and a more accurate picture of the available data, and as the Ministry continues to scale the platform internally, even greater benefits are expected.

In the long term, the Ministry aims to engage data providers more quickly and regularly than before, track compliance with data updates more easily, and monitor the impact of interventions. Increasingly, analysts, policymakers, and data support teams are seeing tangible benefits from using the software.

WHY SELECTZERO?

“Its flexibility and alignment with the Ministry’s data strategy make it a practical solution for evidence-based decision making and improved trust in data“

– Katre Seema, Head of Data Management at Estonia’s Ministry of Education and Research