Configure access for organization-wide Sigma tables (Beta)

This documentation describes one or more public beta features that are in development. Beta features are subject to quick, iterative changes; therefore the current user experience in the Sigma service can differ from the information provided in this page.

This page should not be considered official published documentation until Sigma removes this notice and the beta flag on the corresponding feature(s) in the Sigma service. For the full beta feature disclaimer, see Beta features.

To enable users to create organization-wide Sigma tables, modify their structure, or read and write table data, grant the required access in both your data platform and Sigma. If you enabled Sigma table audit logging on the connection, you must separately manage user access required to view the audit logs.

This page explains the access you must grant in both your data platform and Sigma for organization-wide Sigma tables, based on your connection type and authentication method. To manage access to local Sigma tables, see Grant access to a local Sigma table. For general information about Sigma tables, see Sigma tables overview.

Sigma tables are currently supported by Snowflake, Databricks, and PostgreSQL connections.
This page references “service accounts” to describe a shared identity (a single, connection-level credential that authenticates Sigma user queries to the data platform). In Databricks, the shared identity is called a “service principal.” In PostgreSQL, there is no built-in shared identity, but a connection user can be used as a connection-level credential. If you use a Databricks or PostgreSQL connection, apply the guidance in this document to your service principal or connection user, respectively.

Requirements

The ability to configure access to organization-wide Sigma tables requires the following:

In your data platform, you must have permission to manage grants on the target schemas. This permission is typically granted to platform administrators.
In Sigma, you must be assigned the Admin account type or be an owner of the Sigma table (requires Can own access).
If you have an OAuth connection and want to use a service account to create and modify the underlying database tables for Sigma tables, the service account must be configured on the connection and enabled for Sigma tables. See Enable a service account for Sigma tables on an OAuth connection.

Non-OAuth connection

A non-OAuth connection uses a service account to perform Sigma table operations in your data platform, initiated when users interact with Sigma tables directly in Sigma.

On a non-OAuth connection, governance splits between your data platform and Sigma as follows:

Your data platform governs the service account’s ability to create underlying database tables and modify their structure. Creating a database table makes the service account its owner, which includes full access to modify the table’s structure and read and write table data.
Sigma governs each user’s ability to create Sigma tables, modify their structure, and read and write table data.

Grant access in your data platform first to ensure users can create and modify Sigma tables immediately after you grant them access in Sigma. Nothing prevents you from granting access in Sigma first, but users could encounter errors when attempting to create or modify Sigma tables if you have not yet granted the required access in your data platform.

Select the tab for your connection type to view the relevant data platform guidance.

Snowflake

Databricks

PostgreSQL

Grant permissions in Snowflake

In Snowflake, grant the service account’s role the following privileges on the parent database and each schema where users need to create Sigma tables:

Object	Privilege	Description
Database	`USAGE`	Prerequisite to allowing the service account’s role to interact with objects in the database.
Schema	`USAGE`, `CREATE TABLE`	Allows the service account’s role to access the schema to create tables.

For detailed instructions, see the GRANT command reference in the Snowflake documentation.

The following example grants USAGE to the SIGMA_SERVICE role on the ANALYTICS_DB database and SIGMA_TABLES schema, then also grants CREATE TABLE on the schema.

-- Allow the service account's role to create tables in a schema
GRANT USAGE ON DATABASE ANALYTICS_DB TO ROLE SIGMA_SERVICE;
GRANT USAGE ON SCHEMA ANALYTICS_DB.SIGMA_TABLES TO ROLE SIGMA_SERVICE;
GRANT CREATE TABLE ON SCHEMA ANALYTICS_DB.SIGMA_TABLES TO ROLE SIGMA_SERVICE;

Grant user access to Sigma tables in Sigma

In Sigma, grant individual users access to create, own, and write to organization-wide Sigma tables.

Object	Access level	Description
Schema	Can create table	Allows users to promote or create Sigma tables in the target schema. The schema selector only displays schemas the user has Can create table access to. Can create table access is not required for users to create local Sigma tables, which are created in the connection’s write-back schema.
Table	Can own	Allows users to modify the table’s structure, edit cell data, and grant other users access to the table.
	Can use, write & annotate	Allows users to edit cell data and annotate the table. Table annotations are changes that apply in Sigma only and are not written to the database (e.g., modified column details like friendly names and descriptions, or the addition of metrics and links).
	Can write	Allows users to edit cell data.

Use one of the following methods to open the connection’s data catalog:
- Home: In the left navigation, select the connection name. If you have access to four or more connections, first select Connections, then select the connection name on the Connections page.
- Administration portal: In the Connections page, select the connection name, then click Browse connections. This option is available if you’re an organization admin, or if you’re assigned an account type with the Manage connections permission enabled.
In the data catalog, select the object you want to grant access to.
On the Access tab, click Grant access.
In the Grant access to modal, complete the following:
1. Search for and select one or more users or teams, or select All members of your organization.
2. In the Access field, choose an access level.
3. Click Save.
Confirm the new grants appear in the Access list.

For information about how to edit or revoke access, see Manage access to data and connections.

Grant user access to Sigma table audit logs in Sigma

If you enabled Sigma table audit logging on the connection, each audit log is a separate table in the data catalog with its own access grants, distinct from those on the associated Sigma table.

When Sigma creates an audit log, it automatically grants Can use & annotate access to every user who has Can own access on the associated Sigma table at that time. Afterward, Sigma doesn’t keep the audit log’s grants in sync with the Sigma table, so you can manually manage individual user access going forward.

Object	Access level	Description
Audit log table	Can use & annotate	Allows users to view the audit log and annotate it. Table annotations are changes that apply in Sigma only and are not written to the database (e.g., modified column details like friendly names and descriptions, or the addition of metrics and links).
Can use	Allows users to view the audit log.

Object

Access level

Description

Audit log table

Can use & annotate

Allows users to view the audit log and annotate it.

Table annotations are changes that apply in Sigma only and are not written to the database (e.g., modified column details like friendly names and descriptions, or the addition of metrics and links).

Can use

Allows users to view the audit log.

Audit logs aren’t editable, so Can own and Can write don’t apply. Only admins can manage audit log access grants.

Use one of the following methods to open the connection’s data catalog:
- Home: In the left navigation, select the connection name. If you have access to four or more connections, first select Connections, then select the connection name on the Connections page.
- Administration portal: In the Connections page, select the connection name, then click Browse connections. This option is available if you’re an organization admin, or if you’re assigned an account type with the Manage connections permission enabled.
In the data catalog, select the object you want to grant access to.
On the Access tab, click Grant access.
In the Grant access to modal, complete the following:
1. Search for and select one or more users or teams, or select All members of your organization.
2. In the Access field, choose an access level.
3. Click Save.
Confirm the new grants appear in the Access list.

For information about how to edit or revoke access, see Manage access to data and connections.

OAuth connection

An OAuth connection uses a service account and each user’s own identity to perform Sigma table operations in your data platform. The identity used depends on the type of operation initiated when a user interacts with Sigma tables directly in Sigma.

On an OAuth connection, governance splits between your data platform and Sigma as follows:

Your data platform governs the service account’s ability to create database tables and modify their structure. It also governs each user’s ability to read and write table data.
Sigma governs each user’s ability to create Sigma tables and modify their structure.

You aren’t required to use a service account for Sigma tables on an OAuth connection, but Sigma recommends it to centralize Sigma table ownership governance. For more information, see Enable a service account for Sigma tables on an OAuth connection.

If you enabled Sigma table audit logging on the connection, you must also use data platform permissions to manage user access required to view the audit logs. See step 3 for your connection type below.

Select the tab for your connection type to view the relevant data platform guidance.

Snowflake

Databricks

Grant permissions in Snowflake

In Snowflake, grant the service account’s role the privileges required to create Sigma tables, then grant individual roles the privileges required to read and write table data. If you enabled audit logging for Sigma tables, you must also grant privileges that allow users to view the audit logs.

For detailed instructions, see the GRANT command reference in the Snowflake documentation.

Grant the service account’s role the following privileges on the parent database and each schema where users need to create Sigma tables:

Object	Privilege	Description
Database	`USAGE`	Prerequisite to allowing the service account to interact with objects in the database.
Schema	`USAGE`, `CREATE TABLE`	Allows the service account to access the schema and create tables.

If you don’t use a service account, you can grant the privileges to individual roles with users who need to create Sigma tables.

Without a service account, a Sigma table’s underlying database table in Snowflake is owned by the role of the user who created it. Any other user with that role can alter or drop the table directly in Snowflake, whether or not they’re granted ownership of the corresponding Sigma table in Sigma.

The following example grants USAGE and CREATE TABLE to the SIGMA_TABLES_SA role on the ANALYTICS_DB database and FINANCE_SIGMA_TABLES schema.

-- Allow the service account's role to create tables in a schema
GRANT USAGE
 ON DATABASE ANALYTICS_DB
 TO ROLE SIGMA_TABLES_SA;
GRANT USAGE
 ON SCHEMA ANALYTICS_DB.FINANCE_SIGMA_TABLES
 TO ROLE SIGMA_TABLES_SA;
GRANT CREATE TABLE
 ON SCHEMA ANALYTICS_DB.FINANCE_SIGMA_TABLES
 TO ROLE SIGMA_TABLES_SA;

Grant relevant roles access to the parent database and one of the following sets of schema privileges on each schema where users require read-only or read/write access to Sigma table data:

Object	Privilege	Description
Database	`USAGE`	Prerequisite to allowing users with the role to interact with objects in the database.
Schema	`USAGE`, `SELECT`	Allows users with the role to access the schema and read existing and future tables (read-only access).
Schema	`USAGE`,`ALL PRIVILEGES`	Allows users with the role to access the schema and read and write existing and future tables (read/write access).

This step is required whether or not you use a service account to create Sigma tables because Sigma must use each user’s own credentials to read and write table data.

The following example grants read-only access to the HUMAN_RESOURCES role on the Finance team’s tables, and full read/write access to the FINANCE role on the same tables. Grant any required USAGE privileges before running these statements.

-- Allow a role to read existing and future tables
-- Grant any required USAGE privileges first
GRANT SELECT
 ON ALL TABLES IN SCHEMA ANALYTICS_DB.FINANCE_SIGMA_TABLES
 TO ROLE HUMAN_RESOURCES;
GRANT SELECT
 ON FUTURE TABLES IN SCHEMA ANALYTICS_DB.FINANCE_SIGMA_TABLES
 TO ROLE HUMAN_RESOURCES;
-- Allow a role to read and write existing and future tables
GRANT ALL PRIVILEGES
 ON ALL TABLES IN SCHEMA ANALYTICS_DB.FINANCE_SIGMA_TABLES
 TO ROLE FINANCE;
GRANT ALL PRIVILEGES
 ON FUTURE TABLES IN SCHEMA ANALYTICS_DB.FINANCE_SIGMA_TABLES
 TO ROLE FINANCE;

If you enabled Sigma table audit logging on the connection, grant the following privileges on the audit log schema to each role that requires the ability to view the audit log tables:

Object Privilege Description
Database USAGE Prerequisite to allowing users with the role to interact with objects in the database.
Schema USAGE,SELECT Allows users with the role to view the audit log.

Because each audit log is a separate table with its own access grants in the Sigma data catalog, you must grant this privilege even if the role already has access to the associated Sigma table.

The following example grants SELECT to the FINANCE role on the AUDIT_LOGS schema. Grant any required USAGE privileges before running these statements.
```
-- Allow a role to view audit logs
-- Grant any required USAGE privileges first
GRANT SELECT
 ON ALL TABLES IN SCHEMA ANALYTICS_DB.AUDIT_LOGS
 TO ROLE FINANCE;
GRANT SELECT
 ON FUTURE TABLES IN SCHEMA ANALYTICS_DB.AUDIT_LOGS
 TO ROLE FINANCE;
```

Grant user access to Sigma tables in Sigma

In Sigma, grant individual users access to create and own organization-wide Sigma tables. Read and write access comes from each user’s data platform permissions, so the Can use, write & annotate and Can write grants don’t apply the way they do for a non-OAuth connection.

Object	Access level	Description
Schema	Can create table¹	Allows users to promote or create Sigma tables in the target schema. The schema selector only displays schemas the user has Can create table access to. Can create table access is not required for users to create local Sigma tables, which are created in the connection’s write-back schema.
Table	Can own	Allows users to modify the table’s structure and grant other users access to the table.

Object

Access level

Description

Schema

Can create table¹

Allows users to promote or create Sigma tables in the target schema.

The schema selector only displays schemas the user has Can create table access to.

Can create table access is not required for users to create local Sigma tables, which are created in the connection’s write-back schema.

Table

Can own

Allows users to modify the table’s structure and grant other users access to the table.

Use one of the following methods to open the connection’s data catalog:
- Home: In the left navigation, select the connection name. If you have access to four or more connections, first select Connections, then select the connection name on the Connections page.
- Administration portal: In the Connections page, select the connection name, then click Browse connections. This option is available if you’re an organization admin, or if you’re assigned an account type with the Manage connections permission enabled.
In the data catalog, select the object you want to grant access to.
On the Access tab, click Grant access.
In the Grant access to modal, complete the following:
1. Search for and select one or more users or teams, or select All members of your organization.
2. In the Access field, choose an access level.
3. Click Save.
Confirm the new grants appear in the Access list.

For information about how to edit or revoke access, see Manage access to data and connections.