Discovery

What You Will Be Able to Do

Describe the purpose of the Home Page, Search Bar, Entity Page, Domains, and Glossary
Navigate to a specific dataset using the search bar
Identify an asset's owner, domain, schema, and upstream lineage from its entity page
Know where to look for each question: the tabs on an asset's page (Columns, Lineage, Quality) and the sidebar sections beside them (Owners, Domain, Tags)

The Home Page

You can customize the home page — but its day-to-day use is simple
Browse: the left sidebar takes you everywhere — Domains, Glossary, and the rest
Search: the search bar at the top, available on every page

The home page is a convenience, not a command center. Think of it as a Recently Opened panel: great for returning to something you were just working on, but the wrong tool for finding something new. Glance at announcements occasionally; admins post notices there, like upcoming deprecations.

The Search Bar: Your Primary Navigation Tool

Located at the top of every page, always accessible

Searches across all entity types simultaneously (datasets, dashboards, pipelines, columns, terms, owners...)
Results page: a faceted filter bar across the top -- Type, Platform, Owner, Glossary Term, Tag, Domain
Each result shows entity name, type, platform, and tags; selecting a result opens a summary panel with its description, owner, and domain
Ranked by relevance: exact name matches are boosted to the top; the more complete an asset's metadata, the more search terms it can match on

Search results for the query 'pet': the faceted filter bar across the top (Type, Platform, Owner, Glossary Term, Tag, Domain, More) with platform quick filters, result rows showing entity name, type, and platform, and a summary panel for the selected result at right

Search is not scoped to one entity type: e.g. "revenue" can return datasets, dashboards, dbt models, and glossary terms at once -- that's a feature. Command-K on Mac, or Control-K on Windows,Cmd+K (Ctrl+K on Windows) jumps into search from anywhere.

This is the single most-used feature in DataHub and the one that is most worth drilling. The search bar is not scoped to one entity type -- if you type "revenue," you may get datasets, dashboards, dbt models, and glossary terms all at once. That is a feature, not a bug. Walk participants through the faceted filter bar at the top of the results page. Those filters are how you narrow down 200 results to the 5 that matter. The Platform filter is especially useful: if you know the data lives in Snowflake, filter by Snowflake immediately. Mention the Cmd+K / Ctrl+K keyboard shortcut to jump into search -- experienced users barely lift their hands off the keyboard when navigating DataHub. Facilitator note: this slide is a quick preview of the search bar. The Search module goes deeper -- filters, fuzzy matching, and URN search are all covered there. Keep this fast.

The Entity Page: Everything About One Asset

Every dataset, dashboard, pipeline, and term has one

Header: identity and status -- name, platform, deprecation status
Info panel beside the header: domain, owner, tags
Tabs: detailed metadata organized by topic
Tabs vary by entity type, but most datasets have: Summary, Columns, Lineage, Properties, Queries, Stats, Quality

A dataset entity page: name and platform header, tab row (Summary, Columns, View Definition, Lineage, Properties, Queries, Stats, Quality), created/owners/domain/tags strip, description, and the right-hand summary sidebar with documentation, owners, domain, tags, and glossary terms

Every road in DataHub leads here: search, lineage, and browsing all land on an entity page. The identity area answers "can I trust this, who owns it, where does it belong"; the tabs answer "what's inside, where did it come from, is it healthy". Tabs vary by entity type.

This slide introduces the mental model participants need for the rest of the training. The entity page is where everything converges: search brings you here, lineage navigation brings you here, clicking a result in a domain view brings you here. Emphasize that the identity area (header plus info panel) and the tabs are doing different jobs. The identity area answers "Can I trust this? Who owns it? What domain does it belong to?" The tabs answer "What does it actually contain, where did it come from, and is it healthy?" Spend a moment on the fact that tabs vary by entity type: a Glossary Term's page has a much shorter tab set (Summary, Related Assets, Related Terms, Properties) with no Lineage or Quality tab, while a Dataset gets the fuller set described above. This is normal and participants should not be alarmed when they land on an entity page that has fewer tabs than the example.

Check the Trust Signals First

Deprecated status: shown right next to the asset name -- this asset is being phased out, do not build on it
Domain: shown in the info panel beside the entity name -- tells you which business area owns this data
Owner name(s): also in that info panel -- the person or team to contact with questions
Verification note (orgs that use Compliance Forms): shows which data steward signed off and when
Rule: before reading columns, lineage, or documentation, scan these signals first

A dataset entity page with highlight boxes calling out the trust signals: the dataset name in the header, the owner name, and the domain label

Here's the failure this prevents: someone finds a dataset, builds on it for two days, and only then discovers it was deprecated months ago. The signals sit at the top of the entity page -- read them before you read the columns.

This best practice prevents a specific, common mistake: a user finds a dataset, dives deep into the columns, builds a report on top of it -- and only later discovers that it was marked deprecated three months ago. DataHub surfaces these trust signals prominently at the top of the entity page so they cannot be missed, but people still miss them. Make this visceral for participants: ask them to imagine spending two days building a dashboard on a dataset that was quietly retired. That is the problem the Deprecated status exists to prevent. The verification note works the other way: when you see it, you can trust that a data steward has reviewed and signed off on this asset. Mention that verification depends on your org using Compliance Forms -- not every asset will have one, and building the forms themselves is an admin task.

Summary and Columns Tabs: What You See When You Open a Dataset

Summary tab: description, high-level overview, creation and ownership info
Columns tab: full column list with data types, per-column descriptions and tags
Change History (within the Columns tab): shows historical schema changes -- column additions and removals over time

The Columns tab on a dataset: column names with nullability badges, data types, and per-column descriptions, with the change-history toggle highlighted at the top right of the tab

Most users spend their time on the Columns tab: names, types, descriptions, and any column-level tags. The current view is a snapshot of now -- schema history lives separately, under Change History.

Historical Schema Changes Are Not in the Main Column View

The Columns tab shows the current column layout

Historical changes (columns added, renamed, or removed) are under Change History, found at the top-right of the Columns tab
Easy to miss: Change History is a toggle within the Columns tab, not a separate top-level tab
Why it matters: if a column disappeared and your pipeline broke, Change History tells you when and what changed

The Columns tab with the Change History panel open, listing dated schema events such as documentation and column additions, with the change-history toggle highlighted at the top right of the tab

A column dropped last week is not in the Columns tab at all -- it's in Change History. Look for the view-change-history toggle at the top right of the Columns tab. If a pipeline breaks and you suspect a schema change, that's where you confirm it.

Lineage Tab: Tracing the Data Journey

Interactive graph showing upstream and downstream assets

Upstream: where did this data come from? (source tables, dbt models, Airflow jobs that produced it)
Downstream: what uses this data? (reports, dashboards, downstream tables)
Column-level lineage: toggle to see which upstream column maps to which downstream column
Navigate the graph: click any node to open that entity page

The Lineage tab in Explorer mode: the interactive lineage graph with upstream source tables at left flowing into the opened dataset and its downstream table at right, and the Explorer / Impact Analysis toggle above the graph

Picture a table like finance.revenue_summary: lineage shows it was built by a dbt model from a raw Salesforce sync loaded by Fivetran. Downstream, it shows the dashboards that read from it. The whole chain is visible and clickable, so when something breaks or changes you can see the full blast radius.

Lineage is often described as DataHub's "killer feature" and it is worth taking a moment to make it real. Give participants a concrete mental model: imagine a Snowflake table called finance.revenue_summary. On the Lineage tab, you might see it was built by a dbt model, which pulled from a raw Salesforce sync table, which was loaded by a Fivetran job. That entire chain is visible and clickable. Downstream, you might see three dashboards and a Tableau report that all read from finance.revenue_summary. When something breaks or something needs to change, lineage tells you the full blast radius. Column-level lineage goes one level deeper: it shows exactly which columns flow into which. Mention that lineage is only as complete as what has been ingested -- if an upstream system has not been connected to DataHub, it will not appear in the graph.

Use Downstream Lineage as an Impact Analysis Tool

When you need to know who depends on a table before changing it, open the entity's Lineage tab and switch to the Impact Analysis view (defaults to downstream)
Covered in depth in Lineage -- this is an early preview so you can apply it during the Discovery exercises

The Lineage tab's Impact Analysis view set to Downstreams: a degree-of-dependency filter panel at left and the list of downstream assets, with the affected downstream table highlighted

Before renaming a column or changing a table, open the Lineage tab first: seeing eleven downstream assets before you touch anything is the difference between a planned change and a dashboard going blank two days later. Make it a habit, not a rescue.

This is the pro tip that pays for itself the first time someone uses it. The scenario: a data engineer is asked to rename a column in a core Snowflake table. Without DataHub, they search their codebase, find two or three references, make the change, and declare victory. Two days later, a BI dashboard that pulled from a view that pulled from that table goes blank. With DataHub, they open the Lineage tab first, see 11 downstream assets, and immediately understand the scope of what they are touching. Impact Analysis is not just a DataHub feature -- it is a discipline. Encourage participants to make it a personal policy: before you touch anything, check what depends on it. In the current DataHub UI, this view is labeled "Impact Analysis" within the Lineage tab and defaults to showing downstream dependencies.

The Remaining Tabs at a Glance

Quality: check if the dataset is fresh, passing assertions, or has recent failures
Queries: see sample queries that have referenced this asset (from query logs)
Properties: raw properties ingested directly from the source system
Documentation: rich-text documentation written by the team

If a stakeholder asks "is this data up to date?", Quality is your first stop, with assertion results and freshness checks. And when query-log ingestion is configured, the Queries tab shows how the asset is actually used in practice.

These four tabs are less visited than Columns and Lineage but each serves a specific purpose. Quality is the "is this healthy right now?" tab: it shows assertion results (pass/fail/unknown), freshness checks, and assertion history. If a stakeholder asks "is this data up to date?", Quality is your first stop. Queries is only populated if query log ingestion has been configured -- it shows the actual SQL or queries that have been run against this asset. It is useful for understanding how a dataset is actually used in practice. Properties is mostly for power users and engineers: it contains the raw metadata as ingested, which can be helpful for debugging or for finding fields that have not yet been surfaced in the UI. Documentation is where the team writes freeform descriptions, runbooks, or usage guides. Encourage participants to contribute to Documentation when they learn something useful about a dataset.

Domains and Glossary: Browsing Without Searching

Domains (left navigation, under Govern): organized by business area (Finance, Marketing, Engineering...); click a domain to see all assets assigned to it -- good for "I want to see everything in the Finance domain"
Glossary (left navigation, under Govern): browse business terms and their definitions; each term links back to all assets tagged with it

Video with captions: from the home page establishing shot, the cursor opens Domains from the left sidebar, browses into the Finance domain and its assets, then opens the Glossary and the Monthly Recurring Revenue term — narrated at an unhurried pace

Search is for when you roughly know what you want; browsing is for orientation. New on the Finance team? Open the Finance domain -- that's your starting inventory. Heard "Monthly Active Users" in a meeting? Open the term in the Glossary and follow it to the source of truth.

Search is for when you know (or roughly know) what you are looking for. Domains and Glossary are for when you want to browse and discover. Use a concrete example for Domains: imagine you just joined the Finance analytics team. You do not know the names of the datasets yet. Go to Domains in the left nav, click Finance, and DataHub shows you every dataset, dashboard, and pipeline assigned to that domain. That is your starting inventory. Glossary works similarly but from the term side: if someone uses "Monthly Active Users" in a meeting and you want to know which dataset is the source of truth for that metric, you go to the Glossary, find the term, and see the linked assets. Collections (introduced on the Home Page slide) are worth a brief mention here too: whether hand-picked or filter-based, a collection is only as good as whoever configured it. A well-maintained collection for a critical business area can be very valuable; a stale or badly filtered one can be misleading. Creating or editing a collection requires DataHub Cloud.

Make DataHub Part of Your Daily Workflow

Bookmark the DataHub home page in your browser
Before writing a query: check if the dataset is Verified, not deprecated, and you're using the right columns
Before building a dashboard: check ownership and domain to confirm you have the right authoritative source
Before deprecating or changing an asset: run impact analysis via the Lineage tab
When something breaks: check the Columns tab's Change History and the Quality tab before filing a ticket

The barrier is almost never "I don't know how" -- it's "I didn't think to check." Treat DataHub as a pre-flight checklist before you start work, not a rescue tool after something breaks, and keep it one click away.

Summary and What's Next

Navigate DataHub from the home page, search bar, and Domains
Read an entity page's header and info panel to assess trust signals
Choose the right tab (Columns, Lineage, Quality) based on the question you're answering
Use downstream lineage to assess impact before making changes
Key rule: search bar for discovery, Domains for browsing