> 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.

# Enable a service account for Sigma tables on an OAuth connection (Beta)

> Use a service account to create and modify underlying database tables for Sigma tables on an OAuth connection, centralizing table ownership governance in Sigma.

> **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).

On an OAuth connection, you can enable a service account to create and modify the underlying database tables for Sigma tables. Using a service account allows you to centralize Sigma table ownership governance, avoiding issues that can occur when Sigma uses individual users' own data platform credentials.

This document explains why it's beneficial to configure a service account for Sigma tables on an OAuth connection and how to enable it. For general information about access to Sigma tables, see [Configure access for organization-wide Sigma tables](/docs/configure-data-access-for-org-wide-sigma-tables).

> **Info**
>
> * Sigma tables are currently supported by Snowflake, Databricks, and PostgreSQL connections.
>
> * In Databricks, a service account is referred to as a "service principal." If you use a Databricks connection, apply the guidance in this document to your service principal.

## Requirements

Configuring a service account to create and modify Sigma tables requires the following:

* You must be assigned the Admin [account type](/docs/account-type-and-license-overview).
* The connection must have OAuth enabled and a service account configured. To configure a service account, see the **Complete your OAuth configuration** step for your connection type: [Snowflake](/docs/connect-to-snowflake-oauth#complete-your-oauth-configuration) or [Databricks](/docs/connect-to-databricks-oauth#complete-your-oauth-configuration).

## Why use a service account for Sigma tables

By default, an OAuth connection doesn't use a service account for Sigma tables. In this scenario, when a user creates or modifies a Sigma table, Sigma uses the user's own data platform credentials to create or modify the underlying database table, and the resulting table is owned by whichever identity performed the operation (i.e., the user's role in Snowflake, or the individual user in Databricks). If you use Snowflake, this means all other users who share that role can alter or drop the table. If you use Databricks, this means the table can be orphaned if its owner leaves your organization.

You can avoid these risks by using a service account to create and modify the underlying database tables for Sigma tables. Instead of a role or individual user, the service account owns every table it creates, and Sigma access grants like **Can create table** and **Can own** continue to determine who can perform each operation.

> **Info**
>
> Read and write access to Sigma table data is unaffected, and continues to be determined by each user's own data platform permissions.

## Enable the service account for Sigma tables

If a service account is configured on your OAuth connection, you can enable it for Sigma tables in the **Administration** portal. Sigma can then use the service account to create and modify underlying database tables for newly created Sigma tables, centralizing ownership governance in Sigma.

> **Warning**
>
> Enabling the service account for Sigma tables doesn't transfer ownership of existing underlying database tables. Modifying those tables from Sigma fails until a data platform admin reassigns ownership to the service account using `GRANT OWNERSHIP` in Snowflake or `ALTER TABLE ... OWNER TO` in Databricks.

1. In Sigma, go to **Administration** > **Connections** and select the relevant connection.

2. In the connection's overview page, click **Edit**.

   ![The connection details section for a Databricks OAuth connection, with the cursor clicking the Edit button.](/_fern-files/_img/ca24aa74a78bb2d223fbfda026d3ebd806d4d9166bb6081429423dbb7bd16b14.webp)

3. In the **Service account configuration** section, turn on the **Use for Sigma tables** toggle.

   ![The Service account configuration section with the Service account and Use for Sigma tables toggles turned on, and the cursor clicking the Use for Sigma tables toggle.](/_fern-files/_img/b0091af492b33605529074a0749e3fa8dba7c58a7c536c5c11f0e47a8330b0e8.webp)

4. Click **Save** to update the connection.

## Disable the service account for Sigma tables

If you no longer want Sigma to use the service account to create and modify underlying database tables for Sigma tables, you can disable it in the **Administration** portal. Sigma then uses each user's own data platform credentials to create and modify underlying database tables for newly created Sigma tables.

> **Warning**
>
> Disabling the service account for Sigma tables doesn't transfer ownership of existing underlying database tables. Modifying those tables from Sigma fails until a data platform admin reassigns ownership to the relevant user using `GRANT OWNERSHIP` in Snowflake or `ALTER TABLE ... OWNER TO` in Databricks.

1. In Sigma, go to **Administration** > **Connections** and select the relevant connection.
2. In the connection's overview page, click **Edit**.
3. In the **Service account configuration** section, turn off the **Use for Sigma tables** toggle.
4. Click **Save** to update the connection.