Feature Availability¶

This guide follows the complete Qualytics data trust platform. Start with the task you want to accomplish; the same guide covers connecting data, understanding it, defining trust, monitoring, investigating, and improving it.

Small DO, DQ, DC, or MDM tags beside page and section headings or specific actions identify a required module. Select a marker to return to its explanation here. A marker states a feature requirement, not whether your organization has that module. Your role and team permissions still apply.

Core platform¶

Connecting and syncing datastores, profiling, computed assets, manual tagging, integrations, Flows, and AgentQ are core capabilities. Their individual actions can have module requirements: for example, a Flow can run a Scan only when Data Observability is enabled.

The lineage graph, manual connections, lineage from data catalog integrations, and lineage generated by Qualytics are also core capabilities. Importing lineage directly from a datastore is a separate capability.

Data Observability¶

DO

Data Observability provides volume, freshness, schema, and metric checks and their monitoring workflows. It can be enabled on its own. Scans and quality score calculations require DO, including scans started by schedules or Flows.

With DO but without DQ, check creation is limited to DO rule types. Quality scores use only timeliness and volumetrics; the other six dimensions contribute zero weight.

Data Quality¶

DQ

Data Quality provides integrity checks and recipes for creating and validating checks. It can fully automate the detection of data quality concerns at the record level, using AI to learn what good data looks like and enforce those expectations as your data and business evolve.

A DQ tag on check-authoring guidance applies when you create a check or template, apply a template to additional containers, promote or migrate a check, make a template from a check, or restore an archived check. It does not prevent editing an existing check or activating an existing Draft. Template updates to checks already created can continue; adding checks needs the relevant module.

Data Catalog¶

DC

Data Catalog adds native lineage import, automated business naming, semantic analysis, automatic classification, and asset exploration by datastore or tag. Manual names, descriptions, tags, integrations, and the lineage graph remain core capabilities.

DC can be enabled with or without the other modules.

Master Data Management¶

MDM

Master Data Management adds recipe remediation, including golden-set creation, and the associated data cleaning and movement workflows. It requires DQ, which includes DO.

In an Entity Resolution or Data Reconciliation recipe, DQ covers creating and validating the check. MDM covers setting up the remediation and writing its golden set. An ordinary Materialize operation that copies data into an enrichment destination remains a core capability.

When a module isn't enabled¶

Features of a module your organization does not have stay visible, but the actions that need the module are blocked. Existing checks of a disabled module keep working: they can still be edited, activated from Draft, updated from templates, and run in scans. The platform tells you which module they belong to in one of these ways:

• A module tag beside the feature, such as DQ on a button, menu option, or tab. Hover it to see Part of <Module> and a sentence such as "Data Diff checks are part of the Data Quality module, which isn't enabled for your organization." Select it to open the module's details.
• A notice in a card, form, step, or in place of a whole page, headed <Module> isn't enabled. It says which module the feature belongs to, for example "Golden set creation is part of Master Data Management. Ask your administrator to enable it for your organization."
• A message after an action, when the platform refuses a request that needs the module. It is headed <Module> isn't enabled and explains which feature needed it.

Each of them offers the same two actions, except that a message after an action drops Ask admin to enable once you have asked, and shows only Learn more:

Ask an Admin to enable a module¶

Any user who is not an Admin can ask, from any of the places above.

1. Select Ask admin to enable. A Request sent confirmation appears: "Your administrators were asked to enable <Module>."
2. Every Admin in your organization gets an in-app notification, and an email when email delivery is set up for your deployment. It names you and the module, and the feature you asked from when there is one. The email links to the Status page with that module's details open.
3. The module tags, notices, and module details now show Requested followed by how long ago, for example Requested 5 minutes ago, including after you reload the page. Selecting it again does not notify the Admins a second time.
4. When an Admin enables the module, your request closes and you get a notification.

Admins see Contact Qualytics in place of Ask admin to enable, since requests go to them. It opens the Qualytics support site. Admins can see how many people asked for each disabled module on the Modules card of the Status page.

Continue your task¶

• Connect and profile your first datastore.
• Define checks.
• Monitor data health.
• Follow lineage.
• Investigate and remediate with recipes.