Connections allow you to register your data objects in a technology through a single connection, making data registration more scalable for your organization. Instead of registering schema and databases individually, you can register them all at once and allow Immuta to monitor your data platform for changes so that data sources are added and removed automatically to reflect the state of data on your data platform.

Once you register your connection, Immuta presents a hierarchical view of your data that reflects the hierarchy of objects in your data platform:

• Account (Snowflake) or Metastore (Databricks Unity Catalog)

• Database

• Schema

• Tables: These represent the individual objects in your data platform, and when enabled, become data sources

Beyond making the registration of your data more intuitive, connections provides more control. Instead of performing operations on individual schemas or tables, you can perform operations (such as object sync) at the connection level.

Requirements

See the how-to guides for a list of requirements:

Supported object types

See the integration's reference guide for the supported object types for each technology:

Object sync

Immuta will ensure the objects in your database stay synchronous with the registered objects in Immuta. To do this, Immuta uses the account credentials provided during registration to check the remote technology for object changes like a table being created, new columns being added to a table, or a table being deleted.

• If tables are added, new data sources are created in Immuta.

• If remote tables are deleted, the corresponding data sources in Immuta will become disabled; however, the data object representing the table will still appear in the connections view until manually deleted.

• If a column changes in a table, those changes will be reflected in the Immuta data source data dictionary.

Your connection can be synced in two ways:

• Periodic object sync: This happens once every 24 hours (at 1:00 AM UTC). Currently, updating this schedule is not configurable.

• : You can manually run object sync on your whole connection or on any object in your connection.

Object sync is designed to pull in the user’s data objects from the connected backing technology, so it specifically excludes internal Immuta-managed objects. These objects reside within the Immuta database or catalog, which is , and are used solely for Immuta's internal processes. Because these objects are only for Immuta processes and cannot be queried by users, the objects will be ignored by object sync and will not be ingested into Immuta.

Connection tags

All data sources within the registered connection and found by object sync after will get an automated tag that represents the connection. These tags can be used like any other in Immuta to , , , etc. However, they cannot be edited or deleted.

The tag will be formatted as follows and applied to data sources from table data objects:

Immuta Connections . The Technology . Your Connection Name . Your Schema . Your Database

Tracking new data source columns

When new columns are detected and added to Immuta, they will be automatically tagged with the New tag. This allows governors to use the to mask columns with the New tag, since they could contain sensitive data.

The New Column Added global policy is staged (inactive) by default. See the to activate this seeded global policy if you want any columns with the New tag to be automatically masked.

Data source requests

When there is an active policy that targets the New tag, Immuta sends validation requests to data owners for the following changes made in the remote data platform:

• Column added: Immuta applies the New tag on the column that has been added and sends a request to the data owner to validate if the new column contains sensitive data. Once the data owner confirms they have validated the content of the column, Immuta removes the New tag from it and as a result any policy that targets the New column tag no longer applies.

• Column deleted: Immuta deletes the column from the data source's data dictionary in Immuta. Then, Immuta sends a request to the data owner to validate the deleted column.

For instructions on how to view and manage your tasks and requests in the Immuta UI, see the . To view and manage your tasks and requests via the Immuta API, see the section of the API documentation.

Default settings

When registering a connection, Immuta sets the connection to the recommended default settings to protect your data. The recommended settings are described below:

• Object sync: This setting allows Immuta to monitor the connection for changes. When Immuta identifies a new table, a data source will automatically be created. Similarly, if remote tables are deleted, the corresponding data sources and data objects will be deleted in Immuta. This setting is enabled by default and cannot be disabled.

• Default run schedule: This sets the time interval for Immuta to check for new objects. By default, this schedule is set to 24 hours.

• Impersonation: This setting enables and defines the role for user impersonation, available with . This setting is disabled by default.

Tag ingestion

If you want all data objects from connections to have data tags ingested from the data provider into Immuta, ensure the credentials provided on the Immuta app settings page for the external catalog feature can access all the data objects. Any data objects the credentials do not have access to will not be tagged in Immuta. In practice, it is recommended to just use the same credentials for the connection and tag ingestion.

Permissions

Within the connection, the Data Owner permission can be granted on any data object, and will allow that user to manage that object and any within it. For example, granting a user Data Owner on a schema will grant them Data Owner on tables within that schema as well. Data owners can complete the following actions:

• View the connections UI

• Access any connection where they are granted Data Owner anywhere in the hierarchy

• Trigger object sync for their data objects

• Delete their data objects

Deregistering a connection

Deregistering a connection automatically deletes all of its child objects in Immuta. However, Immuta will not remove the objects in your Snowflake or Databricks account.

Requirement: GOVERNANCE or APPLICATION_ADMIN global permission or Data Owner within the hierarchy

Prerequisite: A connection registered

Run object sync on a connection

1. Click Data and select the Connections tab in the navigation menu.

2. Click the more actions menu for the connection you want and select Run Object Sync.

3. Opt to click the checkbox to Also scan all disabled data objects.

4. Click Run Object Sync.

Run object sync on a database

1. Click Data and select the Connections tab in the navigation menu.

2. Select the connection.

3. Click the more actions menu in the Action column for the database you want to sync and select Run Object Sync.

4. Opt to click the checkbox to Also scan all disabled data objects

Run object sync on a schema

1. Click Data and select the Connections tab in the navigation menu.

2. Select the connection.

3. Select the database.

4. Click the more actions menu in the Action column for the schema you want to sync and select Run Object Sync.

Run object sync on a data source

You can run object sync from the data source health check or from the connection,

1. Click Data and select the Connections tab in the navigation menu.

2. Select the connection.

3. Select the database.

4. Select the schema

Connections are an improvement from the existing process for not only onboarding your data sources but also managing the integration. However, there are some differences between the two processes that should be noted and understood before you start with the upgrade.

1. API changes: See the API changes page for a complete breakdown of the APIs that will not work once you begin the upgrade. These changes will mostly affect users with automated API calls around schema monitoring and data source registration.

2. Automated data source names: Previously, you could name data sources manually. However, data sources from connections are automatically named using the information (database, schema, table) and casing from your data platform. For example, on Snowflake this will typically mean that my_table will become My Connection.MY_DATABASE.MY_SCHEMA.MY_TABLE.

   If you are leveraging Immuta APIs, you may need to adjust code to allow for the new data source names.

3. Schema projects phased out: With integrations, many settings and the connection info for data sources were controlled in the schema project. This functionality is no longer needed with connections and now you can control connection details in a central spot.

4. New hierarchy display: With integrations, tables were brought in as data sources and presented as a flat list on the data source list page. With connections, databases and schemas are displayed as objects too.

5. Change from schema monitoring to object sync: Object metadata synchronization between Immuta and your data platform is no longer optional but always required:

   1. If schema monitoring is off before the upgrade: Once the connection is registered, everything the system user can see will be pulled into Immuta and, if it didn't already exist in Immuta, it will be a disabled object. These disabled objects exist so you can see them, but policy is not protecting the objects, and they will not appear as data sources.

   2. If schema monitoring is on before the upgrade: Once the connection is registered, everything the system user can see will be pulled into Immuta. If it already existed in Immuta, it will be an enabled object and continue to appear as data source.

6. Enabling a connection will enable all databases, schemas, and tables in the hierarchy: If the connection is disabled after completing your upgrade to connections, only enable the host if you want to enable all databases, schemas, and tables within it.

   Enabling a table that is ordinarily disabled will elevate it to a data source. Immuta will then apply data and subscription policies on that data source.

Supported technologies

Change the status of a data object

1. Click Data in the navigation menu and select Connections.

2. Navigate to the connection and go to the level of data object you want to change the status of.

3. Go to the Settings tab and change the Data Object switch to the status you want:

To update the status using the API, see the .

Change the status of new data objects found by object sync

1. Click Data in the navigation menu and select Connections.

2. Navigate to the connection and go to the level of data object you want to change the settings of.

3. Go to the Settings tab and change the Object Sync switch to the status you want:

To update the status using the API, see the .

Assign data object permissions

1. Click Data in the navigation menu and select Connections.

2. Navigate to the connection and go to the level of data object you want to assign permissions to.

3. Go to the Permissions tab and click + Add Permissions.

4. Choose how to assign the permission:

To assign permissions using the API, see the .

If you attempted the upgrade and receive the message that your upgrade is Partially Complete, find the un-upgraded data sources by navigating to the Upgrade Manager and clicking the number in the Available column for the relevant connection.

Use the options below to resolve those un-upgraded data sources in order to finish your upgrade. See the linked how-to's for more details on the actions to take.

Note that these un-upgraded data sources still exist and are still protected by policy.

1. : The easiest solution is to delete the data sources that did not upgrade. Note that disabled data sources that no longer exist in your data platform will never be upgraded. Only do this if you no longer need these data sources in Immuta.

Connections allow you to register your data objects in a technology through a single connection, making data registration more scalable for your organization. Instead of registering schema and databases individually, you can register them all at once and allow Immuta to monitor your data platform for changes so that data sources are added and removed automatically to reflect the state of data on your data platform.

How-to guides

• Register a connection:

  • : Register a connection with a Snowflake account and register the data objects within it.

  • : Register a connection with a Databricks Unity Catalog metastore and register the data objects within it.

• Manage a connection:

  • : Change the object sync settings and manage user permissions for the connection.

  • : Trigger object sync manually for the entire connection or a single object to sync your remote data platform objects with Immuta.

• : Complete the upgrade path from the existing integrations and data sources to a connection.

Reference guides

• : This reference guide discusses the major concepts, design, and settings of connections.

• : This reference guide discusses the differences when upgrading from the existing integrations and data sources to a connection.

Deprecated endpoints

The following endpoints have been deprecated with connections. Use the recommended endpoint instead.

Impacted endpoints

If you have any automated actions using the following APIs, ensure you do the required change after the upgrade to ensure they continue working as expected.

Connections allow you to register your data objects in a technology through a single connection, making data registration more scalable for your organization. Instead of registering schema and databases individually, you can register them all at once and allow Immuta to monitor your data platform for changes so that data sources are added and removed automatically to reflect the state of data on your data platform.

This document is meant to guide to you to connections from a configured integration. If you are a new user without any current integrations, see the instead.