Owners, stewards and responsibilities
Who answers for what, and how responsibility is inherited.
On this page
A responsibility records who answers for an asset and in what role. This page covers how to assign one, how responsibilities pass down from a domain or a container, and where to see everything a person or team is responsible for.
Before you start
- To assign or remove a responsibility on an asset you need Assign responsibilities (RESPONSIBILITY_ASSIGN). In the starter model it comes with Data Owner and Sysadmin.
- To change how responsibilities pass down you need Manage users and roles (ACCESS_MANAGE). This is normally an administrator's job.
The roles
Your repository decides its own roles. The starter model has these roles, each held over an asset:
| Role | What it means |
|---|---|
| Data Owner | Accountable for the asset, and decides who else is responsible for it. |
| Data Steward | Looks after the asset's meaning and quality day to day. |
| Technical Custodian | Runs the platform the asset physically lives on. It can only be assigned on source systems, databases, schemas, tables and views. |
| Subject Matter Expert | Knows what the data means and is consulted, but isn't accountable. |
| Consumer | Uses the asset. Recorded so the people a change affects can be told. |
Other roles, such as Metadata Manager, Sysadmin and Viewer, are held over the whole repository rather than one asset. An administrator assigns those. See People, roles and access.
A role also carries permissions. A Data Steward of a domain can edit what the domain owns, for example. So assigning somebody here changes what they may do as well as recording who to ask.
Assign somebody
- Open the asset and find Responsible, near the top of the page.
- In the row under the table, choose a role from Make someone….
- Choose a person or a team from choose a person or team…. Teams are marked team.
- Press Assign.
You'll see Assigned. and a new row whose Assigned on column names this asset. If the role can't be held at this level, or is locked from above, the message says so and where it can be held.
Assign a team rather than a person
A responsibility can be held by a person or by a team. Assign a team when the accountability belongs to a function rather than to whoever does the job today, such as Platform Engineering or Head of Customer Data. Everyone in the team gets the role's permissions. A team with nobody in it can still hold a responsibility, waiting to be filled.
Remove somebody
- In Responsible, press the × at the end of the row.
- Press Remove to confirm, or Keep to leave it.
You can only remove a responsibility on the asset it was assigned on. An inherited row has no ×. Follow its inherited from link and remove it there.
How responsibility is inherited
You rarely need to name a steward on every table. A responsibility held higher up passes down to everything beneath it:
- Down the containment tree: a source system holds databases, a database holds schemas, a schema holds tables, and a table holds columns.
- Through ownership: an asset owned by a data domain takes the domain's responsibilities.
The Assigned on column shows where each row comes from. It is either this table (or whatever kind of thing you're on), or inherited from a named asset above it.
Two rules decide who applies:
- Direct beats inherited. Somebody named on the asset itself takes precedence over anyone passed down.
- The nearest wins. A column with no steward of its own takes its table's steward, not the source system's. If two sources are equally near, both apply. A table owned by two domains can therefore have two Data Owners.
Where inheritance stops
Each asset that has something beneath it passes responsibility down in one of three ways. The Passes down line on its page shows which one.
| Setting | What it means |
|---|---|
| inherit | Flows down; can be overridden below. Anything beneath may name its own, and that wins. |
| inherit locked | Flows down; can't be overridden below. Anything beneath has to accept it. |
| none | Stops here. Everything beneath names its own or has none. |
The repository has a default, which is inherit unless your administrator changed it, and an asset can set its own. A domain run centrally might be inherit locked, and one that delegates to its teams might be inherit.
An administrator changes the default and per-asset settings under People and Persona, on the Inheritance tab. The tab groups assets by data domain, so each domain can be worked through in turn. The same settings are on the Inheritance sheet of the access workbook.
If you try to assign a role that is locked above, the assignment is refused. The message names the asset where the lock is set, so you know where to change it.
A person's or a team's page
Click a name in any Responsible table to open that person's or team's page.
- A person's page shows their name, email, whether they're active, and the teams they're in. Responsible for lists what's assigned to them directly, and And through their teams lists what they hold as a team member.
- A team's page shows its members and Responsible for, the assets the team holds a role over.
These lists show direct assignments. Assets that inherit the responsibility from one of them aren't listed separately.
Good to know
- If a page says nobody is responsible and nothing above confers anybody, assign the responsibility on the domain or container. It then covers the whole branch.
- Changing who is responsible can start a review workflow, if one is set up to watch for it. See Requests and approvals.
- Every assignment and removal is recorded in the asset's History.