Deployment use cases and examples

Explore end-to-end examples for deploying content to tenant organizations in different scenarios, including SDLC workflows, business unit collaboration, customer tenants, and data sovereignty compliance.

🚩

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.

🚩

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:

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.

graph TD
    DEV[DEV]
    TEST[TEST]
    PROD[PROD]

    DEV --> TEST
    DEV --> PROD

    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.

Then after a document is approved, a user in the test tenant can deploy the approved document to the production tenant:

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.

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.

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.

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:

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.

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

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.

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:

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.