> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://help.sigmacomputing.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://help.sigmacomputing.com/_mcp/server. # Configure access for organization-wide Sigma tables (Beta) > Configure access for organization-wide Sigma tables and their (optional) audit logs by granting permissions in your data platform, Sigma, or both. > **Note** > > 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](/docs/sigma-product-releases#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](/docs/grant-access-to-local-sigma-tables). For general information about Sigma tables, see [Sigma tables overview](/docs/sigma-tables-overview). > **Info** > > * 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](/docs/account-type-and-license-overview) 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](/docs/enable-service-account-for-sigma-tables-on-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. > **Tip** > > 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 ### 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](https://docs.snowflake.com/en/sql-reference/sql/grant-privilege) 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. ```sql -- 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; ``` #### Databricks ### Grant permissions in Databricks In Databricks (Unity Catalog), grant the connection's service principal the following privileges on the parent catalog and each schema where users need to create Sigma tables: | Object | Privilege | Description | | ------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Catalog | `USE CATALOG`, `USE SCHEMA` | Prerequisites to allowing the service principal to interact with schemas in the catalog and tables within those schemas. | | Schema | `CREATE TABLE`, `MODIFY` | Allows the service principal to create, modify, read, and write to tables in the schema. | For detailed instructions, see [Unity Catalog privileges and securable objects](https://docs.databricks.com/en/data-governance/unity-catalog/manage-privileges/privileges.html) in the Databricks documentation. The following example grants the required privileges on the `analytics_catalog` catalog and `sigma_tables` schema to a service principal. ```sql -- Allow the service principal to create and write tables in a schema -- Replace with the principal's application ID. GRANT USE CATALOG, USE SCHEMA ON CATALOG analytics_catalog TO ``; GRANT CREATE TABLE, MODIFY ON SCHEMA analytics_catalog.sigma_tables TO ``; ``` #### PostgreSQL ### Grant permissions in PostgreSQL In PostgreSQL, grant the connection's user the following privileges on each schema where users need to create Sigma tables: | Object | Privilege | Description | | ------ | ----------------- | ------------------------------------------------------------------- | | Schema | `USAGE`, `CREATE` | Allows the connection's user to access the schema to create tables. | For detailed instructions, see the [GRANT command reference](https://www.postgresql.org/docs/current/sql-grant.html) in the PostgreSQL documentation. The following example grants `USAGE` and `CREATE` to the `sigma_user` user on the `sigma_tables` schema. ```sql -- Allow the connection's user to create tables in a schema GRANT USAGE, CREATE ON SCHEMA sigma_tables TO sigma_user; ``` ### 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](/docs/create-local-sigma-tables), which are created in the connection's [write-back schema](/docs/set-up-write-access).
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.
1. 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. 2. In the data catalog, select the object you want to grant access to. 3. On the **Access** tab, click **Grant access**. 4. 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**. 5. 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](/docs/manage-data-permissions). ### Grant user access to Sigma table audit logs in Sigma If you enabled [Sigma table audit logging](/docs/configure-audit-logging-for-sigma-tables) 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.
> **Info** > > Audit logs aren't editable, so **Can own** and **Can write** don't apply. Only admins can manage audit log access grants. 1. 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. 2. In the data catalog, select the object you want to grant access to. 3. On the **Access** tab, click **Grant access**. 4. 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**. 5. 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](/docs/manage-data-permissions). ## 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. > **Tip** > > 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](/docs/enable-service-account-for-sigma-tables-on-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 ### 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](https://docs.snowflake.com/en/sql-reference/sql/grant-privilege) in the Snowflake documentation. 1. 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. > **Warning** > > 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. ```sql -- 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; ``` 2. 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. ```sql -- 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; ``` 3. If you enabled [Sigma table audit logging](/docs/configure-audit-logging-for-sigma-tables) 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. ```sql -- 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; ``` #### Databricks ### Grant permissions in Databricks In Databricks, grant the service principal the privileges required to create Sigma tables, then grant individual groups 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 [Unity Catalog privileges and securable objects](https://docs.databricks.com/en/data-governance/unity-catalog/manage-privileges/privileges.html) in the Databricks documentation. 1. Grant the service principal the following privileges on the parent catalog and each schema where users need to create Sigma tables: | Object | Privilege | Description | | ------- | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Catalog | `USE CATALOG`, `USE SCHEMA` | Prerequisites to allowing the service principal to interact with schemas in the catalog and tables within those schemas. | | Schema | `CREATE TABLE` | Allows the service principal to create tables in the schema. As the owner of each table it creates, the service principal can also modify their structure without an additional grant. | If you don't use a service principal, you can grant the privileges to individual groups with users who need to create Sigma tables. > **Warning** > > Without a service principal, a Sigma table's underlying database table in Databricks is owned by the individual user who created it. Only that user (or an owner of the parent schema) can rename the table or its columns, and if they leave your organization, the table can be orphaned until a metastore admin reassigns it. The following example grants the required privileges on the `analytics_catalog` catalog and `finance_sigma_tables` schema to the service principal. ```sql -- Allow the service principal to create tables in a schema -- Replace with the principal's application ID GRANT USE CATALOG, USE SCHEMA ON CATALOG analytics_catalog TO ``; GRANT CREATE TABLE ON SCHEMA analytics_catalog.finance_sigma_tables TO ``; ``` 2. Grant relevant groups access to the parent catalog 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 | | ------- | -------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | Catalog | `USE CATALOG` | Prerequisite to allowing users in the group to interact with objects in the catalog. | | Schema | `USE SCHEMA`, `SELECT` | Allows users in the group to access the schema and read existing and future tables (read-only access). | | Schema | `USE SCHEMA`, `SELECT`, `MODIFY` | Allows users in the group 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 principal 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` group on the Finance team's tables, and full read/write access to the `finance` group on the same tables. Grant any required `USE CATALOG` and `USE SCHEMA` privileges before running these statements. ```sql -- Allow a group to read existing and future tables in the schema -- Grant any required USE CATALOG and USE SCHEMA privileges first GRANT SELECT ON SCHEMA analytics_catalog.finance_sigma_tables TO `human_resources`; -- Allow a group to read and write existing and future tables GRANT SELECT, MODIFY ON SCHEMA analytics_catalog.finance_sigma_tables TO `finance`; ``` 3. If you enabled [Sigma table audit logging](/docs/configure-audit-logging-for-sigma-tables) on the connection, grant the following privileges on the parent catalog and audit log schema to each group that requires the ability to view the audit log tables: | Object | Privilege | Description | | ------- | ---------------------- | ------------------------------------------------------------------------------------ | | Catalog | `USE CATALOG` | Prerequisite to allowing users in the group to interact with objects in the catalog. | | Schema | `USE SCHEMA`, `SELECT` | Allows users in the group 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 group already has access to the associated Sigma table. The following example grants `SELECT` to the `finance` group on the `audit_logs` schema. Grant any required `USE CATALOG` and `USE SCHEMA` privileges before running these statements. ```sql -- Allow a group to view audit logs -- Grant any required USE CATALOG and USE SCHEMA privileges first GRANT SELECT ON SCHEMA analytics_catalog.audit_logs TO `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**1 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](/docs/create-local-sigma-tables), which are created in the connection's [write-back schema](/docs/set-up-write-access).
Table **Can own** Allows users to modify the table's structure and grant other users access to the table.
1. 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. 2. In the data catalog, select the object you want to grant access to. 3. On the **Access** tab, click **Grant access**. 4. 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**. 5. 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](/docs/manage-data-permissions).