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

# Sigma Tenants deployment use cases and examples (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](/docs/sigma-product-releases#beta-features).

This is a premium feature. To enable it for your Sigma organization, contact your Sigma Account Executive.

Depending on how you use Sigma Tenants, you might set up different deployment configurations. This page provides end-to-end examples for common use cases:

* [Software development lifecycle](#example-software-development-lifecycle)
* [Collaborating business units with a parent company](#example-collaborating-business-units-with-a-parent-company)
* [Embed content for individual customer tenants](#example-embed-content-for-individual-customer-tenants)
* [Comply with data sovereignty requirements](#example-comply-with-data-sovereignty-requirements)

## Example: Software development lifecycle

If you use Sigma Tenants for a software development lifecycle (SDLC) use case, deploy content from a parent organization to a tenant organization.

For example, to configure an end-to-end SDLC workflow that uses version tagging and tenant-to-tenant deployments, do the following:

1. In the parent `DEV` organization, create a user attribute `swap_dev_to_test`. Assign the user attribute to the `TEST` tenant with the name or ID of the connection in the `TEST` tenant.
2. In the parent `DEV` organization, create a source swap policy to manage swapping a connection from the parent `DEV` organization to the connection mappings assigned in the `swap_dev_to_test` attribute.
3. In the parent `DEV` organization, create a deployment policy to deploy relevant documents to the `TEST` tenant for QA testing:

   * Add the source swap policy created in step 2 to the deployment policy.
   * Add the version tag `TEST` to the deployment policy.
   * Add relevant documents to the deployment policy.
   * Add the `TEST` tenant organization to the deployment policy.

```mermaid
graph TD
    DEV[DEV]
    TEST[TEST]
    PROD[PROD]

    DEV --> TEST

    style DEV fill:#4CEC8C
    style TEST fill:#FF9A74
    style PROD fill:#FF9A74
```

For more details, see [Deploy content from a parent organization to one or more tenants](/docs/deploy-content-from-parent-organization-to-tenant-organizations).

To allow the `TEST` tenant organization to deploy documents to the `PROD` tenant, do the following:

1. In the parent `DEV` organization, grant the `TEST` tenant organization the deployment capability to deploy to the `PROD` tenant.
2. In the `TEST` tenant organization, create a user attribute `swap_test_to_prod`. Assign the user attribute to the `PROD` tenant with the name or ID of a connection in the `PROD` tenant. Contact a user in the `PROD` organization to retrieve the connection details.
3. In the `TEST` tenant organization, create a source swap policy to manage swapping a connection from the `TEST` organization to the connection mappings assigned in the `swap_test_to_prod` attribute.
4. In the `TEST` tenant organization, create a deployment policy to deploy relevant documents to the `PROD` tenant after they pass QA testing:

   * Add the source swap policy created in step 3 to the deployment policy.
   * Add the version tag `PROD` to the deployment policy.
   * Add relevant documents to the deployment policy.
   * Add the `PROD` tenant organization to the deployment policy.

```mermaid
graph LR
    TEST[TEST]
    PROD[PROD]

    TEST --> PROD

    style TEST fill:#FF9A74
    style PROD fill:#FF9A74
```

For more details, see [Deploy content from one tenant to other tenants](/docs/deploy-content-from-one-tenant-to-other-tenants).

After configuring the deployment workflow, users in each tenant can follow a software development lifecycle like the following:

1. Users in the `DEV` organization build documents. When a document is ready to deploy, add it to the relevant deployment policy, then set the `TEST` tag on the relevant version.

   When the document is tagged, the document is automatically deployed to the `TEST` tenant organization.
2. Users in the `TEST` organization review documents. If changes are needed, communicate with users in the `DEV` organization to make updates and tag a new version of the document when they are ready for testing.
3. After a document passes QA testing, users in the `TEST` organization tag the relevant document version with the `PROD` version tag.

   If the document is already added to the relevant deployment policy, the document is automatically deployed to the `PROD` tenant organization.

## Example: Collaborating business units with a parent company

If you use Sigma Tenants to isolate business units across a parent company, but those units collaborate with each other, you might want to occasionally deploy documents from the parent organization to tenant organizations.

For example, to configure deployment policies for collaborating business units with multiple connections in each tenant:

1. In the parent `Parent Company` organization, create two user attributes:

   * `bunit_test_connections`
   * `bunit_prod_connections`

   Assign each user attributes to the relevant business unit tenants. In this example, Assign the `Finance`, `HR`, and `Sales` tenants to the attribute, using the name or ID of each test and prod connection in each tenant as the attribute value.
2. In the parent `Parent Company` organization, create two source swap policies to manage swapping each test and prod connection from the parent `Parent Company` organization to the connection mappings assigned in the `bunit_test_connections` attribute:

   * `Swap Business Unit Test Connections`
   * `Swap Business Unit Prod Connections`
3. In the parent `Parent Company` organization, create a deployment policy to deploy relevant documents each business unit:

   * For example, to deploy finance-specific content to the `Finance` tenant:

     1. Create a deployment policy called `Finance` with a name in the tenant of `HQ Finance`.
     2. Add both source swap policies to the deployment policy.
     3. Add finance-relevant documents that you want to share with the users in the `Finance` tenant to the deployment policy.
     4. Add the `Finance` tenant to the deployment policy.

   * To deploy sales-specific content to the `Sales` tenant and HR-specific content to the `HR` tenant, repeat the same steps.

```mermaid
graph TD
    Parent[Parent Company]
    Finance[Finance]
    HR[HR]
    Sales[Sales]

    Parent -.->|Deploy| Finance
    Parent -.->|Deploy| HR
    Parent -.->|Deploy| Sales

    style Parent fill:#4CEC8C
    style Finance fill:#FF9A74
    style HR fill:#FF9A74
    style Sales fill:#FF9A74
```

For more details, see [Deploy content from a parent organization to one or more tenants](/docs/deploy-content-from-parent-organization-to-tenant-organizations).

Separately from the parent company deploying content to tenant organizations, the business units might collaborate with each other. As such, tenant organizations frequently deploy content to other tenant organizations:

```mermaid
graph LR
    Finance[Finance]
    HR[HR]
    Sales[Sales]

    HR -->|Deploy| Finance
    Sales -->|Deploy| Finance
    Finance -->|Deploy| HR

    style Finance fill:#FF9A74
    style HR fill:#FF9A74
    style Sales fill:#FF9A74
```

To allow the `Finance` tenant organization to deploy documents created in the `Finance` tenant to the `HR` tenant, do the following:

1. In the parent `Parent Company` organization, grant the `Finance` tenant organization the deployment capability to deploy to the `HR` tenant.
2. In the `Finance` tenant organization, create a user attribute `swap_tenant_prod_connections`. Assign the user attribute to the `HR` tenant with the name or ID of a connection in the `HR` tenant. Contact a user in the `HR` organization to retrieve the connection details.
3. In the `Finance` tenant organization, create a source swap policy to manage swapping a connection from the `Finance` organization to the connection mappings assigned in the `swap_tenant_prod_connections` attribute.
4. In the `Finance` tenant organization, create a deployment policy to deploy relevant documents to the `HR` tenant. If the documents are the same as those deployed from the `Parent Company` organization, use version tags to ensure that the relevant content is deployed.

To support deploying content from `Sales` to `Finance` or `HR` to `Finance`, repeat the steps.

For more details, see [Deploy content from one tenant to other tenants](/docs/deploy-content-from-one-tenant-to-other-tenants).

## Example: Embed content for individual customer tenants

If you use Sigma Tenants to provide embedded content for individual customers, and use tenants to isolate data for each customer, you likely plan to deploy content exclusively from the parent organization to tenant organizations (and embed the deployed content).

```mermaid
graph TD
    Provider[Embed Provider]
    CustomerA[Customer A]
    CustomerB[Customer B]
    CustomerC[Customer C]

    Provider --> CustomerA
    Provider --> CustomerB
    Provider --> CustomerC

    style Provider fill:#4CEC8C
    style CustomerA fill:#FF9A74
    style CustomerB fill:#FF9A74
    style CustomerC fill:#FF9A74
```

For example, to configure deployment policies for deploy content as a managed service provider to isolated customer tenants, where each customer tenant has one connection defined:

1. In the parent `Provider` organization, create one user attributes: `tenant_connections`.
2. Assign the attribute to each tenant organization, using the name or ID of the connection in each tenant as the attribute value. For example, assign the attribute to `Customer A` with the value of `Connection A`, `Customer B` with the value of `Connection B`, and `Customer C` with the value of `Connection C`.
3. In the parent `Provider` organization, create a source swap policy to manage swapping a connection from the parent `Provider` organization to the connection mappings assigned in the `tenant_connections` attribute. For example, name it `Swap Customer Connections`.
4. In the parent `Provider` organization, create a deployment policy to deploy relevant documents to the customer tenants. You might use the same deployment policy for all tenants, or different deployment policies for different customers, depending on which documents you want to deploy. For example, to share the same set of onboarding documents with customers:

   1. Create a deployment policy called `Welcome Documents`.
   2. Add the `Swap Customer Connections` swap source policy to the deployment policy.
   3. Add a set of template welcome documents to the deployment policy.
   4. Add all three customer tenants to the deployment policy.

   If you onboard a new customer in the future, after creating and configuring the tenant organization for the new customer (`Customer D`):

   1. Assign the `tenant_connections` attribute to the `Customer D` tenant with a value of `Connection D`.
   2. Add the tenant to the `Welcome Documents` deployment policy.

For more details, see [Deploy content from a parent organization to one or more tenants](/docs/deploy-content-from-parent-organization-to-tenant-organizations).

## Example: Comply with data sovereignty requirements

If you use Sigma Tenants to comply with data sovereignty and residency requirements, such as that required by the European Union (EU) General Data Protection Regulation (GDPR), you might deploy content from a parent organization hosted in a cloud region where your company headquarters is located (such as the United States), to tenant organizations hosted in cloud regions with data sovereignty laws, such as the EU or Australia:

```mermaid
graph TD
    HQ[US Company HQ]
    EU
    APAC

    HQ --> EU
    HQ --> APAC

    style HQ fill:#4CEC8C
    style EU fill:#FF9A74
    style APAC fill:#FF9A74
```

For example, to configure deployment policies to deploy content to tenants in other regions, where each tenant has one connection defined:

1. In the parent `US Company HQ` organization, create one user attributes: `region_connections`.
2. Assign the attribute to each tenant organization, using the name or ID of the connection in each tenant as the attribute value. For example, assign the attribute to `EU` with the value of `Databricks_EU`, `APAC` with the value of `Snowflake_APAC`.
3. In the parent `US Company HQ` organization, create a source swap policy to manage swapping a connection from the parent `US Company HQ` organization to the connection mappings assigned in the `region_connections` attribute. For example, name it `Swap Regional Connections`.
4. In the parent `US Company HQ` organization, create a deployment policy to deploy relevant documents to the tenants in other regions. You might use the same deployment policy for all tenants, or different deployment policies for different tenants, depending on which documents you want to deploy. For example, to share the same set of customer data tracking apps to each region:

   1. Create a deployment policy called `Customer Data Tracking`.
   2. Add the `Swap Regional Connections` swap source policy to the deployment policy.
   3. Add a set of customer data tracking apps to the deployment policy, such as one that analyzes website analytics and another that analyzes store purchase analytics.
   4. Add both region tenants to the deployment policy.

For more details, see [Deploy content from a parent organization to one or more tenants](/docs/deploy-content-from-parent-organization-to-tenant-organizations).

## Related resources

* [Sigma Tenants (Beta)](/docs/multitenancy-at-sigma)
* [Deploy content to tenant organizations (Beta)](/docs/deploy-content-to-tenant-organizations)
* [Deploy content from a parent organization to one or more tenants (Beta)](/docs/deploy-content-from-parent-organization-to-tenant-organizations)
* [Deploy content from one tenant organization to one or more tenants (Beta)](/docs/deploy-content-from-one-tenant-to-other-tenants)