Responsibilities

Master data is only as good as the people who maintain it. The Responsibilities Matrix makes ownership explicit (who enters data, who approves it) and lets you notify those people the moment their attention is needed.

Why a Responsibilities Matrix?

Governance fails quietly when nobody is sure whose job it is. The matrix answers that question per table: who is responsible for entering data, and who is responsible for approving it. Because it also shows pending queues and error counts alongside the names, it doubles as an operational view of where the work is piling up, and gives you a one-click way to email the right people about it.

The two table-level roles

Role	Responsibility
Data Steward (Entry)	Adding, editing, and importing records into the table.
Approver	Reviewing pending records and approving them as Golden.

Table-specific, not enterprise-wide Both roles are assigned per table. The same person can be a steward on one table and an approver on another. Global enterprise roles (SuperAdmin, Admin, Editor, Viewer) are managed separately in Settings.

Reading the matrix

Content is organized along the familiar hierarchy: Enterprise → Data Model → Table. Each enterprise is an expandable section labeled with aggregate counters (tables, data models) and inline pills for total pending and error records. Expand All and Collapse All buttons in the header control the whole page at once.

Each table row shows:

Column	What it shows
Table name	The entity in question.
Responsible (Entry)	Blue user pills. Solid pills are people who have actually created records recently; dashed pills are formally assigned stewards who have not acted yet.
Approver	Purple user pills, with the same solid/dashed convention.
Golden	Green chip with the count of golden records.
Pending	Amber chip with the count of pending records.
Errors	Red chip with the count of records currently in Draft.
Actions	Three icon buttons: view pending, manage team, notify.

Solid versus dashed pills The solid/dashed distinction is a quiet health check on your governance model. A dashed steward who never acts, or activity from people who are not formally assigned, both suggest the matrix and reality have drifted apart: worth a conversation.

The three actions

View pending

Jumps to the Records screen pre-filtered to the table with the status set to Pending. Disabled when the table has no pending records: nothing to review, nothing to click.

Manage Team

Opens the Manage Table Responsibilities dialog, with two multi-select controls: Data Stewards (who can add, edit, or import records) and Approvers (who can approve pending records). The picker is filtered to people with access to the enterprise that owns the table, plus SuperAdmins. Click Save Changes to apply.

Who can change assignments Only SuperAdmins and Admins of the enterprise can change table responsibilities. Everyone else sees the dialog in read-only mode.

Notify Responsibles

Opens the Notify Responsibles dialog with the recipient list pre-filled from the table's assigned stewards and approvers; untick anyone you do not want to email. A default message is provided ("Action required on entity '<table>'. Please review pending records.") which you can edit freely. Clicking Send Alert does two things: it logs the alert in the system audit table, and it sends a real email through Snowflake's native SYSTEM$SEND_EMAIL, using the email integration configured in Settings.

The alerts log

At the bottom of the page, the Recent Alerts Log (Audit Trail) expander lists past notifications with sender, recipient, table, message body, and timestamp. Use it to verify that alerts actually went out, and to whom.

How responsibilities become permissions

Assigning someone in the matrix does more than display their name. It actively grants table-level capabilities that override their global role:

Data Stewards can create, edit, and import records on their assigned tables, even if their global role is Viewer.
Approvers can approve, reject, and revoke records on their assigned tables, even if their global role is Editor.

This enables a least-privilege pattern: keep most users on a low global role (Viewer), and grant elevated access only on the specific tables each person actually owns.

Common questions

What is the difference between a Steward and an Editor?

Editor is a global role granting edit rights across an entire enterprise. Steward is a table-level assignment granting entry rights on one specific table. A Viewer who is steward of one table can edit that table and nothing else.

Can the same person be both steward and approver of a table?

The platform allows it, but for meaningful governance it is better to separate the two: the person who enters data should generally not be the one who approves it. Use separate assignments wherever your team size permits.

Why did my notification email not arrive?

Check three things: the Snowflake email integration name in Settings matches an existing notification integration; the recipient's address is in the integration's ALLOWED_RECIPIENTS list; and the Recent Alerts Log confirms the alert was sent. The log entry tells you whether the problem is in MDM or in the Snowflake email configuration.

Someone left the company. What happens to their assignments?

Their pills remain in the matrix until an Admin updates the team via Manage Team. They will show as dashed (assigned but inactive) once they stop acting. Reviewing the matrix periodically for dashed pills is a good governance habit.