Ownership and Access

You Found a Dataset. Now What?

You search DataHub and find finance.quarterly_revenue -- the table looks relevant, but there is no owner listed
Who do you contact if the numbers look wrong? Who can tell you what "net revenue" means here, or when it last refreshed?
Answer: nobody. The asset is orphaned -- this module fixes that.

Brief: Screenshot of a DataHub dataset page with the Owners field empty (showing "+ Add Owner" with no owners listed), illustrating an asset with no owner.

Two Concepts, One Goal

Ownership: who is responsible for this asset? Domain: which part of the business does this asset belong to?
Ownership answers "Who do I call?" Domain answers "Where does this fit in our organization?"
Together they make every asset findable, contactable, and governable

The Three Ownership Types

Technical Owner: the team or person who built and maintains the pipeline -- contact for "Why is this column NULL?", "When does this table refresh?", "Is this dataset safe to join with X?" (e.g. team:data-platform or team:finance-engineering)
Business Owner: the stakeholder who defines the business rules and requirements -- contact for "What does 'active user' mean in this context?", "Why does this metric differ from what Finance reports?" (e.g. team:finance-business or a specific VP of Finance)
Data Steward: the person responsible for governance quality (descriptions, tags, glossary terms)
Best practice: assign at minimum a Technical Owner and a Business Owner for every critical dataset

One Asset, Three Owners

finance.quarterly_revenue -- example ownership: team:finance-engineering (Technical Owner), team:finance-business (Business Owner), jsmith / Finance Compliance (Data Steward)
All three can -- and should -- co-exist on the same asset
They do not conflict -- they cover different domains of responsibility
An asset with all three is significantly more trustworthy and useful

Brief: Screenshot of the Owners section in a DataHub entity page's right-hand sidebar, showing three owner entries each with a different ownership-type badge (Technical Owner, Business Owner, Data Steward).

How to Claim Ownership in DataHub

Navigate to any entity page (dataset, dashboard, pipeline, etc.)
In the right-hand sidebar, click the + next to "Owners"
Search for your name or your team's group name
Select the appropriate ownership type from the dropdown
Click Save
Ownership is visible to everyone immediately after saving; you can assign it to individuals or groups
Tip: prefer team/group ownership, especially for Technical Owner -- individual ownership breaks when that person leaves

Brief: Screenshot of a DataHub entity page's right-hand sidebar with the Owners "+" control clicked open, showing the name/group search box and the ownership-type dropdown mid-selection.

This is the first procedural slide, so slow down slightly. If you are running this as a live session with DataHub open, this is a good moment to navigate to a real entity page and demonstrate the click path. The UI is straightforward but participants often miss the dropdown for ownership type -- they add an owner but forget to select the type, which means the ownership is assigned with no type label. Point that out explicitly. Mention that the search box for owners works by user display name and email, so participants can search for their own name or their team's name. Ownership assigned to an individual breaks when that person leaves; use team/group ownership for Technical Owner wherever possible. Business Owner is often more appropriate as an individual since it represents a named accountable person. If your team does not have a DataHub group yet, ask your admin to create one before the lab.

Use Groups, Not Individuals

Assign ownership to a group, not an individual
team:data-platform outlasts any single team member -- jsmith is gone the moment jsmith leaves the company
When jsmith leaves, the asset becomes silently orphaned; groups persist through turnover, individuals do not
If your team does not have a DataHub group yet, ask your admin to create one

Don't Claim Ownership You Don't Have

Do not add yourself or your team as owner of an asset you do not actually own
Ownership is a contract, not a label -- if someone contacts you based on your ownership listing, you need to be able to help them
Phantom owners are worse than no owners: they create false confidence
If the real owner is unknown, leave it blank and escalate to your data governance team; if you're not sure whether you own something, ask your team lead first

This is the counterbalance to the enthusiasm participants often have after learning they can claim ownership. The watch-out here is not hypothetical: in early DataHub rollouts, people sometimes add themselves as owner of high-profile datasets to "help with governance" without actually having the knowledge or authority to answer questions about those datasets. When an incident happens and someone contacts that phantom owner, the phantom owner cannot help, and the real owner is still unknown. Ownership is a form of accountability. If you do not have the accountability, do not take the label. Acknowledge that there are gray areas (for example, a dataset that was built by someone who has left) and suggest that ambiguous cases should be escalated to the data governance team rather than claimed opportunistically.

Domain Assignment in Practice

Domains were introduced in Core Concepts: every asset belongs to one named business domain
How to assign: open any entity page, click the Domain badge, select from the admin-configured list
Who assigns: data stewards or domain owners -- not individual contributors
Governance rule: agree on the full domain list before bulk ingestion -- retroactive reassignment is slow
Policies and Data Products can be scoped to a domain; if an asset spans two domains, assign the primary one and note the other in the description

How to Assign a Domain in DataHub

Navigate to any entity page
Locate the Domain section in the entity's right-hand sidebar (it shows "No Domain" if unassigned)
Click the "+" icon in that section (a pencil icon instead, if a domain is already set)
Select the appropriate domain from the list
Save -- if the correct domain does not exist, contact your DataHub admin to create it. Assignment is immediate and visible to all users
Watch out: an asset can belong to only one domain -- moving it overwrites the previous assignment
Best practice: align domains with business units (Finance, Marketing, Customer), not technical systems -- keep top-level domains to 5-15
Watch out: domains aren't your access boundary -- access control belongs in policies

Brief: Screenshot of a DataHub entity page's right-hand sidebar showing the Domain section in its "No Domain" placeholder state with the domain-picker modal open, listing selectable domains.

Again, if you have DataHub open, demonstrate this click path. The "No Domain" state is easy to spot because the sidebar section is visually empty or shows a placeholder. One thing to clarify: unlike ownership, which supports multiple entries, domain is a single-value assignment. You cannot put an asset in both Finance and Marketing. If an asset genuinely spans two business units, the convention is to pick the primary owner and use tags or documentation to note the cross-functional nature. Also reinforce the note about non-existent domains: participants should not try to create domains themselves unless they have admin rights. They should contact their DataHub admin. Moving an asset to a new domain overwrites the previous assignment, so plan your domain structure carefully before bulk-assigning assets. The goal of domain naming is business discoverability, not technical inventory -- use nested subdomains for more specific groupings. Domains are for curation and discovery, not primary access control; using them as the sole access mechanism can degrade performance and creates an inflexible design.

Access Policies -- Who Can Do What in DataHub

DataHub has built-in role-based access control -- separate from ownership
Policies control which users or groups can view, edit, or manage which entities and operations
Managed under Settings > Permissions > Policies
Ownership = organizational accountability. Policies = access authorization. Both are needed.

Platform Policies vs. Metadata Policies

Platform policies: DataHub-level actions -- create tokens, manage users, create domains, view analytics
Metadata policies: entity-level actions -- view entity, edit description, deprecate, delete
Set independently -- a team can have full metadata edit rights with no platform admin access
Most day-to-day governance work uses metadata policies

Brief: Screenshot of the DataHub Settings > Permissions > Policies list page, showing a mix of policy rows with their Type column visible distinguishing "Platform" and "Metadata" policies.

Built-in Roles -- A Starting Point

Admin: full access to everything -- platform and metadata
Editor: can edit all metadata; no platform admin actions
Reader: read-only across the catalog
Most organizations start with these three and add custom policies for domain-scoped exceptions (e.g. "Finance data stewards can deprecate Finance assets only")

Scope Sensitive Privileges by Domain

Create a metadata policy: grant "Edit Deprecation" to the Finance steward group, scoped to the Finance domain only
Prevents stewards from deprecating assets they don't govern
Pattern: one policy per domain per sensitive privilege (edit deprecation, delete, manage data products)
Always document the reason in the policy description field -- this is your audit trail

Brief: Screenshot of the DataHub Settings > Permissions > Policies "Create Policy" form, with the Privileges field set to "Edit Deprecation" and the Resources/domain filter scoped to a single domain (e.g. Finance).

Orphaned Assets: The Hidden Cost

An orphaned asset has no owner and no domain
Discovery: it does not surface in domain browsing; it relies on users knowing the exact name
Accountability: no one can be contacted when something goes wrong
Governance: with no domain, domain-scoped policies and Data Products can't apply to it
Trust: users who find it cannot tell if it is maintained or abandoned

Filter by Owner to Audit Your Portfolio

Use the owners filter in DataHub search to find everything your team owns -- then review it
Steps: run a blank search (or search for *), find "Owners" in the left filter panel, type your team's group name and apply it
Review the results: are all assets documented? Do they have domains assigned? Are descriptions complete?
A five-minute quarterly habit that prevents ownership debt from accumulating
Claiming ownership isn't just documentation -- an owner-based metadata policy can automatically grant you edit rights on the assets you own
Reader role: search, browse, view schema/lineage/quality, no editing. Editor role: also edit descriptions, tags, and glossary terms, and generate Personal Access Tokens

Brief: Screenshot of the DataHub search results page with the left filter panel's "Owners" filter expanded and a team group name entered/selected in the filter search box.

This is a practical, immediately actionable tip that participants can use the same day. The goal is to make ownership auditing feel lightweight rather than like a major governance project. Frame it as a five-minute quarterly habit: filter by your team, scan for gaps, fix what you can. If participants ask how to find assets with no owner at all (not scoped to their team), mention that DataHub admins can run governance-level reports across all assets, but individual contributors can at minimum audit their own team's portfolio using this filter. Connect this tip back to the orphaned asset problem from the previous slide: the filter is your tool for finding and fixing orphans on your team. If you cannot edit a dataset's description, ask your admin to check your role assignment.

Check for Understanding

You receive an email from a downstream team saying the numbers in finance.quarterly_revenue do not match what was presented in the board report. Which ownership type do you contact, and why?
Your colleague adds herself as Technical Owner of a dataset she did not build because she "wants to make sure it has an owner." What is the problem with this?
A new analyst wants to browse all Risk-related datasets in DataHub without running a search query. What DataHub feature makes this possible, and what needs to be in place for it to work?

Summary + What's Next

Three ownership types: Technical Owner, Business Owner, Data Steward -- each answers different questions
How to assign ownership on any entity page (use groups, not individuals)
Domains: the organizational layer that enables browsing, scoped governance, and business context
How to assign a domain on any entity page
Orphaned assets: the cost of skipping both, and how to audit your team's portfolio