Setting Up Domains for Data Product Management

Learn about adding data sources to domains manually or dynamically using tags

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 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. Once a user creates new data objects in the data platform, they must be registered in Immuta as data sources and assigned to a domain so that they can be published as data products.

Once an application admin registers the data platform as a connection, data will automatically be synced:

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.

Connections tags

Requirement: Data sources from a connection

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 HR Domain and selects dynamic assignment based on the tag Immuta Connections . Snowflake . business . hr-data-products.
3. User with USER_ADMIN permission provides the data engineers with permission 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 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.

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, Databricks Unity Catalog, or AWS Lake Formation to ingest tags.
3. User with GOVERNANCE permission creates the domain HR Domain and selects dynamic assignment based on the tag HR Domain.
4. User with USER_ADMIN permission provides the data engineers with permission 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 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.

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 HR Domain.
3. User with GOVERNANCE permission creates the domain HR Domain and selects dynamic assignment 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). 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 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.