Sigma Tenants deployment use cases and examples (Beta)

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
• Collaborating business units with a parent company
• Embed content for individual customer tenants
• 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.

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.

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.

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.

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.

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.