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:
- 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.
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:
-
In the parent
Parent Companyorganization, create two user attributes:bunit_test_connectionsbunit_prod_connections
Assign each user attributes to the relevant business unit tenants. In this example, Assign the
Finance,HR, andSalestenants to the attribute, using the name or ID of each test and prod connection in each tenant as the attribute value. -
In the parent
Parent Companyorganization, create two source swap policies to manage swapping each test and prod connection from the parentParent Companyorganization to the connection mappings assigned in thebunit_test_connectionsattribute:Swap Business Unit Test ConnectionsSwap Business Unit Prod Connections
-
In the parent
Parent Companyorganization, create a deployment policy to deploy relevant documents each business unit:-
For example, to deploy finance-specific content to the
Financetenant:- Create a deployment policy called
Financewith a name in the tenant ofHQ Finance. - Add both source swap policies to the deployment policy.
- Add finance-relevant documents that you want to share with the users in the
Financetenant to the deployment policy. - Add the
Financetenant to the deployment policy.
- Create a deployment policy called
-
To deploy sales-specific content to the
Salestenant and HR-specific content to theHRtenant, 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:
- In the parent
Parent Companyorganization, grant theFinancetenant organization the deployment capability to deploy to theHRtenant. - In the
Financetenant organization, create a user attributeswap_tenant_prod_connections. Assign the user attribute to theHRtenant with the name or ID of a connection in theHRtenant. Contact a user in theHRorganization to retrieve the connection details. - In the
Financetenant organization, create a source swap policy to manage swapping a connection from theFinanceorganization to the connection mappings assigned in theswap_tenant_prod_connectionsattribute. - In the
Financetenant organization, create a deployment policy to deploy relevant documents to theHRtenant. If the documents are the same as those deployed from theParent Companyorganization, 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:
-
In the parent
Providerorganization, create one user attributes:tenant_connections. -
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 Awith the value ofConnection A,Customer Bwith the value ofConnection B, andCustomer Cwith the value ofConnection C. -
In the parent
Providerorganization, create a source swap policy to manage swapping a connection from the parentProviderorganization to the connection mappings assigned in thetenant_connectionsattribute. For example, name itSwap Customer Connections. -
In the parent
Providerorganization, 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:- Create a deployment policy called
Welcome Documents. - Add the
Swap Customer Connectionsswap source policy to the deployment policy. - Add a set of template welcome documents to the deployment policy.
- 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):- Assign the
tenant_connectionsattribute to theCustomer Dtenant with a value ofConnection D. - Add the tenant to the
Welcome Documentsdeployment policy.
- Create a deployment policy called
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:
-
In the parent
US Company HQorganization, create one user attributes:region_connections. -
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
EUwith the value ofDatabricks_EU,APACwith the value ofSnowflake_APAC. -
In the parent
US Company HQorganization, create a source swap policy to manage swapping a connection from the parentUS Company HQorganization to the connection mappings assigned in theregion_connectionsattribute. For example, name itSwap Regional Connections. -
In the parent
US Company HQorganization, 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:- Create a deployment policy called
Customer Data Tracking. - Add the
Swap Regional Connectionsswap source policy to the deployment policy. - 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.
- Add both region tenants to the deployment policy.
- Create a deployment policy called
For more details, see Deploy content from a parent organization to one or more tenants.
Updated 21 minutes ago
