Business Ontology access control¶

Snowflake enables Business Ontology on selected accounts. After your account is enabled, grant privileges to roles on individual ontology domains. A domain is the smallest grantable unit: you can’t grant privileges on an individual node, relationship, or representation.

This topic describes the access model for the private preview. For general role-based access control concepts, see Overview of Access Control.

Domain privileges¶

The following privileges control access to an ontology domain:

Privilege	Usage
`READ`	Allows a role to read approved and deprecated nodes, their visible relationships, and their representations. Doesn’t allow reading drafts or changing content.
`SUGGEST`	Allows a role to read approved and deprecated nodes, their visible relationships, and their representations, and to propose changes for review: draft new nodes, draft edits to existing nodes, and draft relationships and representations. The role can read, edit, and discard the drafts it creates, but can’t approve any draft, including its own, and can’t change published content.
`MODIFY`	Allows a role to read published content, create and read drafts, approve changes, edit and delete nodes, manage relationships and representations, and change the domain’s comment.
`OWNERSHIP`	Includes `READ`, `SUGGEST`, and `MODIFY` and allows a role to drop the domain.
`ALL [ PRIVILEGES ]`	Grants all domain privileges except `OWNERSHIP`. This includes `USAGE`, which currently has no effect on a domain. Doesn’t allow a role to drop the domain.

Important

To separate proposing a change from approving it, grant SUGGEST to the roles that propose changes and MODIFY only to the roles that review them. A role with SUGGEST can’t approve its own drafts, and after one of its drafts is approved, the role can no longer edit or delete that node directly.

MODIFY by itself doesn’t separate the two: a role with MODIFY can approve its own drafts. If your organization requires a different reviewer for those roles, enforce that requirement through your review process.

Privileges required for operations¶

The following table lists the required privileges for each operation:

Operation	Required privilege
Change a domain’s comment.	`MODIFY` on the domain.
Apply a tag to a domain.	`MODIFY` on the domain and `APPLY` on the tag.
Drop a domain.	`OWNERSHIP` on the domain. `MODIFY` and `ALL PRIVILEGES` aren’t sufficient.
Create a draft node.	`SUGGEST` or `MODIFY` on the containing domain.
Propose an edit to an approved node.	`SUGGEST` or `MODIFY` on the containing domain, or ownership of the node.
Read, edit, or discard a draft node.	`MODIFY` on the containing domain, or ownership of the node. A role with `SUGGEST` owns the drafts it creates, and can read, edit, and discard those drafts.
Approve a draft node, or change its status from draft.	`MODIFY` on the containing domain. Ownership of the node isn’t sufficient.
Edit, delete, or tag an approved or deprecated node, or apply or reject a proposed edit.	`MODIFY` on the containing domain. Ownership of the node isn’t sufficient.
Read an approved or deprecated node.	`READ`, `SUGGEST`, or `MODIFY` on the containing domain.
Draft a relationship for review.	For each endpoint node: `SUGGEST` or `MODIFY` on its domain, or ownership of the node.
Create or approve a relationship.	For each endpoint node: `MODIFY` on its domain, or ownership of that node while it is a draft.
Delete a relationship.	For each endpoint node: `MODIFY` on its domain, or ownership of that node while it is a draft.
Draft a representation for review. The representation links a node to a table, view, column, or Semantic View.	`SUGGEST` or `MODIFY` on the node’s domain, or ownership of the node.
Create or approve a representation that links a node to a table, view, column, or Semantic View.	`MODIFY` on the node’s domain, or ownership of the node while it is a draft.
Read the ontology graph.	`READ`, `SUGGEST`, or `MODIFY` on each domain whose published nodes the role needs to see. A relationship is visible only when both endpoint nodes are visible.

The role that creates a node owns it. Node ownership isn’t a separately grantable node-level privilege: it lets the author work on its draft. After the node is approved, directly editing, deleting, or tagging it requires MODIFY on the domain. The owner can still propose an edit. Use domain grants to delegate access to other roles.

There isn’t a separate privilege for choosing a relationship type. Creating a relationship requires permission on both endpoint nodes, regardless of the type. For supported types and custom labels, see Business Ontology relationships.

Grant access to a domain¶

The following examples assume that the finance domain and the named roles already exist. Run the grants using a role authorized to grant privileges on that domain.

To let a reader role read published content without changing it:

GRANT READ ON ONTOLOGY DOMAIN finance TO ROLE ontology_reader;

To let a contributor role read published content and propose changes for a steward to review:

GRANT SUGGEST ON ONTOLOGY DOMAIN finance TO ROLE finance_contributor;

To let a steward role read published content, create drafts, and approve and manage changes:

GRANT MODIFY ON ONTOLOGY DOMAIN finance TO ROLE finance_steward;

To limit a steward role to proposing changes, grant SUGGEST and then remove the domain-level MODIFY grant:

GRANT SUGGEST ON ONTOLOGY DOMAIN finance TO ROLE finance_steward;
REVOKE MODIFY ON ONTOLOGY DOMAIN finance FROM ROLE finance_steward;

Removing this grant doesn’t remove other authorization, such as ownership or privileges inherited from another role. Review those sources of access before treating the role as limited to proposing changes.

Preview limitations¶

The following limitations apply to access control in this preview. Most are known issues that Snowflake expects to resolve soon:

Top-level domain creation: The preview doesn’t require a separate privilege to create a top-level domain. Manage top-level domain creation through your organization’s provisioning process.
SUGGEST availability: SUGGEST isn’t enabled on every preview account yet. If GRANT SUGGEST ON ONTOLOGY DOMAIN returns a syntax error, contact your account team to enable it.
Grant visibility: Ontology-domain grants aren’t listed by SHOW GRANTS TO ROLE, and SHOW GRANTS ON ONTOLOGY DOMAIN isn’t supported. Keep grant and revoke statements in source control as a record of intended access. To verify effective read access, use the intended role to inspect the domain or node. An absent grant in SHOW GRANTS isn’t evidence that access has been revoked.
Domain inspection and lifecycle: SHOW ONTOLOGY DOMAINS, DESCRIBE ONTOLOGY DOMAIN, and renaming a domain aren’t supported. Use Snowsight to inspect domains. Dropping a domain requires OWNERSHIP, and there’s no UNDROP operation.
Denied lookups: Looking up a domain by name without the required privilege returns a not-found result. Check domain grants before concluding that the domain doesn’t exist.
Search results: A role can find a node in Business Ontology search when it has READ, SUGGEST, MODIFY, or OWNERSHIP on the node’s domain. A grant or revoke shows up in search results at the next index refresh. See Use Business Ontology with Cortex Agents (Preview).