# Setting Up Domains for Data Product Management Domains are the foundation of federated governance in Immuta. They group related data sources and assign responsibility to the teams closest to the data. When using [data products](/SaaS/request/access-data-products/reference-guide/data-products-and-assets.md#data-products) with the Request app, this structure decentralizes access decision-making while preserving enterprise-wide visibility and control. To set up your domain(s) for a successful implementation of a request and approve workflow in the Request app, 1. **Use dynamic assignment**: Leverage metadata—such as connections tags, catalog tags, or tags curated in Immuta—to automatically place new data sources into the right domain as they’re onboarded. This ensures governance workflows are applied consistently without manual effort. 2. **Set user permissions strategically**: Assign users or groups with `Manage Data Products` permissions to create and publish data products from this domain. Users with any domain-specific permission can also act as approvers for access requests if needed. ## Use case for the Request app Typically, the user assigned the `Manage Data Products` permission is a data engineer with `CREATE` permissions in the underlying data platform. This allows them to generate new tables or views using data engineering tools like dbt and be experts on the data. Those newly generated tables or views (or even S3 objects) are what will then be [data sources for the data products](/SaaS/request/access-data-products/reference-guide/data-products-and-assets.md#data-sources-and-columns). Once a user creates new data objects in the data platform, they must be [registered in Immuta as data sources](#user-content-fn-1)[^1] and [assigned to a domain so that they can be published as data products](#implementation). Once an application admin [registers the data platform as a connection](/SaaS/configuration/integrations/data-and-integrations/registering-a-connection.md), data will automatically be synced: ```mermaid sequenceDiagram autonumber participant DP as Data platform participant DE as Data engineer (Domain owner) participant IM as Govern app participant M as Request app Note over DP, DE: Step 1: Initial data setup DP->>DE: Grant CREATE permissions on schema DE->>DP: Create new tables/views Note over DP, IM: Step 2: State management IM->>DP: Detects new objects (Object sync or schema monitoring) IM->>IM: Matches tag to domain (Dynamic assignment) Note over M, DE: Step 3: Productization IM->>IM: Data source appears in domain DE->>M: Create and publish Data Product Note over DE, M: Step 4: Consumption IM->>M: Data product is visible to users M->>DE: User discovers and requests access ``` ## Implementation See the examples in the tabs below to understand your options when dynamically assigning data sources to domains for data products. In this example, the `GOVERNANCE` user will be able to limit what data sources land in the `HR Domain` by limiting the scope of power where the data engineer could apply tags. In the first two examples, they are limited to applying tags only in the schema where they have `CREATE` permission in the data platform. In the last example, they are limited to where they can apply tags by where they were made data owners. {% tabs %} {% tab title="Connections tags" %} **Requirement**: [Data sources from a connection](/SaaS/configuration/integrations/data-and-integrations/registering-a-connection/reference-guides/connections-overview.md) 1. An administrator of the data platform GRANTs CREATE permission to the hypothetical schema `business.hr-data-products` to the data engineers. 2. User with `GOVERNANCE` permission [creates the domain](/SaaS/configuration/domains/configure-domains.md#create-a-domain) `HR Domain` and selects [dynamic assignment](/SaaS/configuration/domains/domains.md#domain-data-sources) based on the tag `Immuta Connections . Snowflake . business . hr-data-products`. 3. User with `USER_ADMIN` permission [provides the data engineers with permission](/SaaS/configuration/domains/configure-domains.md#assign-domain-permissions) `Manage Data Products` in that domain. 4. Data engineer creates 6 new tables in the schema `business.hr-data-products` and wants to now have them available as data sources for a data product. 5. When Immuta registers those objects, it will include the connection tag to represent the schema and database. 1. If Immuta hasn't yet found those new tables through periodic polling, the data engineer executes [object sync](/SaaS/developer-guides/api-intro/connections-api/how-to-guides/manage-a-connection.md#post-data-crawl-objectpath) over the Immuta API so that Immuta will find them. 6. Those 6 tables will appear as data sources within the domain and are now available for data products. {% endtab %} {% tab title="Data platform tags" %} **Requirement**: Snowflake, Databricks Unity Catalog, or AWS Lake Formation data sources 1. An administrator of the data platform GRANTs CREATE permission to the hypothetical schema `business.hr-data-products` to the data engineers. This administrator also creates the tag `HR Domain` in the data platform to tag the tables. 2. User with the `APPLICATION_ADMIN` permission configures [Snowflake](/SaaS/configuration/integrations/snowflake/how-to-guides/enterprise.md#opt-to-enable-snowflake-tag-ingestion), [Databricks Unity Catalog](/SaaS/configuration/integrations/databricks/databricks-unity-catalog/how-to-guides/connect-unity-catalog.md#opt-to-enable-databricks-unity-catalog-tag-ingestion), or [AWS Lake Formation](/SaaS/configuration/integrations/aws-lake-formation/register-an-aws-lake-formation-connection.md) to ingest tags. 3. User with `GOVERNANCE` permission [creates the domain](/SaaS/configuration/domains/configure-domains.md#create-a-domain) `HR Domain` and selects [dynamic assignment](/SaaS/configuration/domains/domains.md#domain-data-sources) based on the tag `HR Domain`. 4. User with `USER_ADMIN` permission [provides the data engineers with permission](/SaaS/configuration/domains/configure-domains.md#assign-domain-permissions) `Manage Data Products` in that domain. 5. Data engineer creates 6 new tables in the schema `business.hr-data-products` and wants to now have them available as data sources for a data product. 6. Data engineer tags those data sources with the `HR Domain` tag directly in the data platform. When Immuta registers those objects, it will include the data platform tag(s). 1. If Immuta hasn't yet found those new tables through periodic polling, the data engineer executes [schema monitoring](/SaaS/developer-guides/api-intro/immuta-v1-api/data-sources.md#trigger-schema-monitoring-jobs) over the Immuta API so that Immuta will find them. 7. Those 6 tables will appear as data sources within the domain and are now available for data products. {% endtab %} {% tab title="Immuta tags" %} 1. An administrator of the data platform GRANTs CREATE permission to the hypothetical schema `business.hr-data-products` to the data engineers. This administrator also creates the tag `HR Domain` in the data platform to tag the tables. 2. User with `GOVERNANCE` permission [creates the new tag](/SaaS/configuration/tags/manage-tags/how-to-guides/managing-tags.md#create-tags) `HR Domain`. 3. User with `GOVERNANCE` permission [creates the domain](/SaaS/configuration/domains/configure-domains.md#create-a-domain) `HR Domain` and selects [dynamic assignment](/SaaS/configuration/domains/domains.md#domain-data-sources) based on the tag `HR Domain`. 4. User with `GOVERNANCE` permission [configures the data engineers to be data owners of all the tables in the schema `business.hr-data-products` (includes future tables)](/SaaS/configuration/integrations/data-and-integrations/registering-a-connection/how-to-guides/manage-connection-settings.md#assign-domain-permissions-2). Being the data owner allows you to manage tags on the tables in the Govern app. 5. Data engineer creates 6 new tables in the schema `business.hr-data-products` and wants to now have them available as data sources for a data product. 1. If Immuta hasn't yet found those new tables through periodic polling, the data engineer executes [schema monitoring](/SaaS/developer-guides/api-intro/immuta-v1-api/data-sources.md#trigger-schema-monitoring-jobs) over the Immuta API so that Immuta will find them. 6. Data engineer tags those data sources with the `HR Domain` tag from within the Govern app (or with the API). 7. Those 6 tables will appear as data sources within the domain and are now available for data products. {% endtab %} {% endtabs %} [^1]: If object sync or schema monitoring is enabled, Immuta automatically registers objects through periodic polling (24 hours by default) to detect changes in the data platform and represent those changes in Immuta, as data sources. These checks can also be [manually triggered](/SaaS/developer-guides/api-intro/immuta-v1-api/data-sources.md#trigger-schema-monitoring-jobs). --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://documentation.immuta.com/SaaS/configuration/domains/setting-up-domains-for-marketplace.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.