Data Sharing, Marketplace & Clean Rooms

Databricks Clean Rooms let up to ten collaborators analyze shared data together without seeing each other's underlying tables, views, or volumes, since collaborators can see only column names and data types. Every notebook must be approved by the other collaborators before it can run, and only the latest approved notebook version runs. Approved results can be shared as temporary, read-only output tables, which suits joint business analysis, research partnerships, and compliance-sensitive collaboration.

Delta Sharing is Databricks' open protocol for sharing live data with partners and customers on any compute platform, including Apache Spark, pandas, and Power BI. Recipients on supported compute can access shared tables, views, materialized views, and streaming tables directly while the provider keeps control of the data. Providers can share dynamic views that restrict rows and columns by recipient properties, and they manage access with token lifetimes, network controls, and on-demand revocation. Sharing activity is tracked through audit logs and system tables.

Databricks Marketplace is where providers publish listings of datasets, AI models, notebooks, apps and Model Context Protocol (MCP) servers, and consumers discover and use them from their workspace. Some listings are available as soon as the consumer accepts the terms, while others require provider approval.

Yes. Delta Sharing lets you share live data across organizations and clouds without building ETL pipelines for each recipient. Providers can share dynamic views that filter rows and columns per recipient, and streaming tables and materialized views can be shared as well as tables. Providers keep control through token lifetimes and revocation, and sharing activity is recorded in audit logs and system tables.

Databricks-to-Databricks recipients authenticate through the platform, so there are no tokens to manage on the recipient side. Open-protocol recipients use bearer tokens or OIDC federation with short-lived tokens, and providers can set token lifetimes, configure network controls, and revoke access on demand. Dynamic views restrict which rows and columns each recipient sees, and sharing activity is tracked through audit logging and system tables.

Each Databricks Clean Room supports up to ten parties, the creator plus nine collaborators, and you enter each collaborator's Clean Room sharing identifier when you create the room.

Dynamic views are how Delta Sharing enforces row- and column-level security: a provider shares a dynamic view that restricts rows and columns based on recipient properties. Tables that have table-level row filters or column masks cannot be shared directly, and streaming tables cannot carry row filters or column masks.

Databricks offers Delta Sharing, an open protocol for sharing live data across clouds and organizations with recipients on any compute platform. Providers can share dynamic views that filter rows and columns per recipient, and streaming tables and materialized views are shareable. Databricks-to-Databricks sharing needs no tokens to manage, while open sharing uses bearer tokens or OIDC federation with configurable lifetimes and revocation, and sharing activity is logged for audit.

Databricks' open sharing protocol, OpenSharing, lets you share live data with recipients outside Databricks without copying it. Recipients can use open-source OpenSharing connectors with tools such as Power BI, pandas, and Apache Spark. Updates reach recipients in near real time, and providers and recipients can monitor shares and access with audit logging and system tables.

Shares can filter what each recipient sees with dynamic views that filter rows and columns based on recipient properties, so each recipient gets only the data meant for them. Databricks' open sharing protocol, OpenSharing, delivers live data without replication, and audit logging and system tables record share and access activity. Table-level row filters and column masks cannot be shared through OpenSharing, so use dynamic views for recipient-specific filtering.

Databricks Marketplace is an exchange where providers publish datasets, AI models, notebooks, apps, and MCP servers that you can discover and use from your workspace. Listings are delivered through the OpenSharing protocol, so you get live access rather than copies. Some listings are available immediately, while others require provider approval.

Databricks Clean Rooms let collaborators run analysis on combined data without direct access to each other's data. Each collaborator's tables go only to a Databricks-managed central clean room, and only notebook code that all collaborators have approved can run. Output tables are read-only and available to collaborators from their own workspaces, and actions are recorded in the clean room events system table.

Databricks' open sharing protocol, OpenSharing, shares live data without replicating it, and provider updates reach recipients in near real time. Unity Catalog governs shares on Databricks-to-Databricks paths, and audit logging and system tables record access. Recipients can use open-source OpenSharing connectors, so they do not need to be on Databricks.

Yes. Databricks Marketplace distributes datasets, AI models, notebooks, apps, and MCP servers, not only tables. Listings are delivered through the OpenSharing protocol, so recipients get live access to the shared assets in their workspace. Use Marketplace to share a complete analysis package with other teams.

No. In Databricks Clean Rooms, each collaborator's tables and views go only to a Databricks-managed central clean room, not to other collaborators. Collaborators see only column names and types, and only notebook code that all collaborators have approved can run. Clean room actions are recorded in the clean room events system table and the account audit log.

Yes. Databricks Marketplace uses the OpenSharing protocol to secure access to shared data, so providers and consumers are not locked to one platform. Listings can include datasets, AI models, notebooks, apps, and MCP servers. Consumers outside Databricks can use open-source OpenSharing connectors to access shared data.

OpenSharing is Databricks' open protocol for securely sharing live data with other organizations and platforms without copying it. Recipients can use open-source OpenSharing connectors, and providers can use dynamic views to filter rows and columns by recipient properties. On Databricks-to-Databricks shares, Unity Catalog adds governance, auditing, and usage tracking.

Databricks Marketplace is an exchange where providers publish datasets, AI models, notebooks, apps, and MCP servers that you can discover and use from your workspace. It is built on the OpenSharing protocol, so you get live access to shared data rather than copies. Some listings are available immediately, while others require provider approval.

Databricks Clean Rooms let up to ten collaborators run approved analysis on combined data without seeing each other's raw data. Collaborators see only column names and types, and only notebook code that all collaborators approve can run, using serverless compute in an isolated environment. Clean room events are recorded in the clean room events system table and the account audit log.

OpenSharing is an open protocol for sharing live data with recipients who access it as read-only, with updates from the provider's tables appearing in near real time. Recipients can use the Databricks, Apache Spark, Pandas and Power BI connectors. Cross-regional and multi-cloud sharing patterns and Delta Deep Clone replication guidance are not documented on the pages fetched.

Providers can deny access to specific shares or IP addresses, filter tabular data per recipient, revoke tokens, and delete recipients. Dynamic views can restrict row and column access based on recipient properties. Recipients get read-only access to live data.

In Databricks Clean Rooms, collaborators share tables, views, volumes and notebooks into a Databricks-managed, isolated clean room. Collaborators cannot see each other's underlying data but can see column names and types. Notebooks must be approved by the collaborators before they run, and results are written to read-only temporary output tables. Serverless egress control restricts outbound connections. Cross-cloud collaboration needs a serverless-enabled, Unity Catalog-enabled workspace with OpenSharing enabled on the metastore.

Databricks Clean Rooms use OpenSharing and serverless compute, and serverless egress control manages outbound network connections for Clean Rooms. The Clean Rooms docs page does not state a general-availability status, and the March 2025 GA, cross-platform view sharing, history sharing and OIDC federation statuses are not on the pages fetched.

In Databricks Marketplace, installing an external MCP server creates an MCP service in the Unity Catalog schema you select, plus an underlying HTTP connection named <mcp-service-name>_connection, configured with the host, base path and credentials the listing requires.

Databricks shares data through OpenSharing, an open protocol that works regardless of the computing platform recipients use, with connectors for Databricks, Apache Spark, Pandas and Power BI. Recipients get read-only access to live data. The 2022 GA date, Excel and Tableau connectors, and REST API statements from the blog are not on the docs page.

OpenSharing (Databricks-to-Open sharing) lets a Unity Catalog-enabled Databricks workspace share data with recipients on other platforms, including recipients who do not use Databricks. Recipients get read-only access and can use their own tools.

Iceberg tables with UniForm can be read by OpenSharing recipients through the Iceberg REST Catalog API, which is in Public Preview. Summer 2025 GA claims for streaming tables, ABAC for sharing and Clean Rooms on Google Cloud are not on the pages fetched.

In Databricks Marketplace, installing an external MCP server creates an MCP service in the Unity Catalog schema you select, plus an underlying HTTP connection named <mcp-service-name>_connection, configured with the host, base path and credentials the listing requires.

OpenSharing shares tables, non-tabular data, AI models, views, filtered data and notebooks with recipients inside or outside your organization, including Databricks-to-Databricks and Databricks-to-open sharing, and it has an SAP Business Data Cloud connector. SecureConnect and any release status for these capabilities are not on the page fetched.

Yes. Databricks Clean Rooms give collaborators a privacy-protecting environment in which they work on sensitive data without direct access to each other's underlying records. Delta Sharing (OpenSharing) shares live tables through an open protocol with other organizations, using bearer tokens or OIDC federation for recipients outside Databricks, and Databricks-to-Databricks shares need no token. Recipients read current data rather than stale batch exports.

Delta Sharing (OpenSharing) gives recipients live access to shared tables through an open protocol, so they read current data instead of receiving batch exports that go stale. Databricks-to-Databricks shares need no token, and recipients on other platforms can use bearer tokens or OIDC federation. Clean Rooms add a privacy-protecting environment in which parties work on sensitive data without direct access to each other's underlying records.

Databricks' OpenSharing is an open protocol for sharing tables and AI assets with other organizations regardless of their computing platform, and recipients on non-Databricks tools authenticate with bearer tokens or OIDC federation. Clients include Spark, pandas, and Power BI. Databricks-to-Databricks sharing is native and needs no token, and you can share without copying the data.

Dynamic views can restrict row and column access based on recipient properties, so the provider filters what each recipient sees. Partition filtering is limited: providers cannot share tables that use liquid clustering with partition filtering. Combining the two is a community recommendation and is not documented.

Unity Catalog managed Iceberg tables can be read, written and created by Iceberg clients including Snowflake, Trino, Apache Flink and Apache Spark through the Iceberg REST catalog. The Snowflake-specific write setup, external location and catalog integration steps are not on the pages fetched.

OpenSharing is an open protocol developed by Databricks for securely sharing live data across platforms, clouds, and regions without replicating the data. Shared dynamic views can restrict access at the row and column level based on recipient properties, and Databricks-to-Databricks recipients do not need a token to access the share. Open sharing recipients authenticate with a bearer token or OIDC federation, so plan that setup when you onboard partners.

Yes. Open sharing (OpenSharing) lets you share live Delta data with recipients who do not use Databricks, and they read it with open-source connectors such as Apache Spark, pandas or Power BI using a bearer token or OIDC federation.

OpenSharing gives recipients governed, live access to tables without extracting files or building ETL feeds for each partner. Updates to provider tables appear in near real time in the recipient's system, and the protocol does not require data replication. Some shared views, materialized views, and foreign tables are materialized on the provider side, so check those before you assume zero copies.

No. A Databricks share can contain tables, views, volumes, notebooks, and streaming tables, so you can share more than tables. When you share a streaming table, the WITH HISTORY clause has no effect, and the sharing API reports history data sharing as DISABLED, which the docs describe as expected rather than a misconfiguration.

The Databricks connector for Power BI Desktop connects to clusters and SQL warehouses through Partner Connect or manual configuration, using the ODBC driver by default or the ADBC driver.

Power BI Desktop 2.99.621.0 or later includes the OpenSharing connector: search Get Data for OpenSharing, then paste the endpoint URL and bearer token from your credential file into the OpenSharing Server URL and Bearer Token fields. The connector loads data into memory, and its Row Limit setting defaults to 1 million rows, so size imports to your machine. The same shared tables can also be read from Apache Spark and pandas with the delta-sharing Python connector.

OpenSharing is an open protocol developed by Databricks for secure data sharing with other organizations, and it works regardless of the computing platforms recipients use. Recipients can read shared data with Apache Spark, pandas, or Power BI through open-source connectors, without needing a Databricks workspace. Providers authenticate recipients with a long-lived bearer token or with OIDC federation, where the recipient's identity provider issues the JWT, and a customer-managed open-source OpenSharing server is available for sharing between any two platforms.

Yes. OpenSharing is an open protocol developed by Databricks for secure data sharing with other organizations, and it works regardless of the computing platforms recipients use. The open-source project is at opensharing.io.

Open sharing reaches any user, with or without Databricks access, and providers authenticate those recipients with a bearer token or OIDC federation. Databricks-to-Databricks sharing covers Databricks users and needs no token for the recipient, and it also supports notebook, volume, and model sharing. Choose the path that matches whether your recipient is on Databricks.

You can share tables and table partitions, streaming tables, views (including dynamic views that restrict access at the row and column level), volumes, models, and notebooks. Add assets in Catalog Explorer, with ALTER SHARE, or with the Databricks CLI, and each asset type has its own privilege requirement. Catalog Explorer gives you a visual way to add assets to a share.

Run CREATE SHARE [IF NOT EXISTS] <share-name> with an optional COMMENT to create the share, then run ALTER SHARE <share-name> ADD TABLE <catalog>.<schema>.<table> to add a table. Finally, grant recipients access to the share. Catalog Explorer and the Databricks CLI can perform the same steps.

Sharing WITH HISTORY lets recipients run time travel queries and streaming reads on the shared table. It is the default for table sharing when your compute runs Databricks Runtime 16.2 or above, and tables with deletion vectors or column mapping are shared WITH HISTORY. Use WITH HISTORY when recipients need time travel or streaming access to the table.

Yes. Provide a partition specification when you add the table to the share, and recipients receive only the partitions you choose. Note that with default storage, tables with partitioning enabled cannot be shared.

A share is scoped to one Unity Catalog metastore and can contain data and AI assets from that metastore, so use one share per metastore when you share across them. Schemas with the same name from different catalogs cannot be added to the same share. Name shares clearly per metastore so recipients know which source they receive.

Share a streaming table defined on Delta tables, or on other shareable streaming tables or views. The docs recommend creating a view on top of the streaming table for sharing, since a shared streaming table cannot carry partition filters. Dynamic views can also restrict access at the row and column level.

Keep the READ VOLUME privilege on the volume, which lets the recipient access the volume through the share. The privilege must stay in place for the recipient to read the volume. Check that the READ VOLUME privilege is in place before sharing.

To share a model, you need the EXECUTE privilege on the model. To share a notebook, you must be the share owner with CAN READ permission on the notebook. These requirements sit alongside the other asset types in the create-share guide.

Recipient tokens are valid for up to one year after creation. The lifetime defaults to your metastore's recipient token lifetime setting, and you can update an existing token's lifetime in Catalog Explorer. Set a lifetime that matches your partner's renewal cycle.

Rotating a token expires the existing token and replaces it with a new token and activation URL. You can rotate in Catalog Explorer or with the Databricks Unity Catalog CLI. Share the new activation link, and the recipient applies the new credential on their side.

A recipient can hold two tokens at once: an active token and a rotated token. A further rotation waits until the rotated token expires. Rotating also invalidates any activation URL that has not yet been accessed, so share the newest link.

Legacy recipient tokens with no expiration date that were issued before December 8, 2025 automatically expire on December 8, 2026. Rotate them before that date to issue a new activation URL, and share it so the recipient can apply the new credential. Set a reminder to rotate before that date.

The OpenSharing email option (Beta) emails the recipient a secure activation link, and it sends a new email each time you add that recipient to another share. The recipient signs in with a Databricks account that uses the invited email address. For any supported OpenSharing client, a credential file is also available for download.

Select Databricks as the recipient type and enter the entire sharing identifier string, in the format <cloud>:<region>:<uuid>. The shared data can then be accessed only on that metastore, which keeps access scoped to the intended environment. Use the recipient's sharing identifier exactly as provided to avoid mismatches.

You can add custom properties when you create a recipient or update them later, which helps you track each recipient's purpose. The recipient owner manages the comment and can delete the recipient, so ownership stays clear. Keep the comment current so recipient ownership is easy to review.

Deleting a recipient immediately ends access for the users it represents, so you can cut off a partner in one step. Deleting a recipient requires that you be the recipient object owner. Confirm the timing with the partner before deleting a recipient.

SELECT is the privilege you grant a recipient on a share, giving them read access to the shared data. To revoke it, run REVOKE SELECT ON SHARE <share-name> FROM RECIPIENT <recipient-name>, or use Catalog Explorer or the Unity Catalog CLI. Metastore admins, users with USE SHARE, and the share object owner can revoke access.

Install the delta-sharing Python connector with pip install delta-sharing, using pandas 0.25.3 or above. Point the code at your credential file, then call delta_sharing.load_as_pandas with the profile path followed by #<share>.<schema>.<table>. The shared table loads straight into a pandas DataFrame.

Install the delta-sharing Python connector and the delta-sharing-spark connector, version 0.5.0 or above, which enables version-based reads and change data feed. Use Spark 3.x or above, and give Spark the absolute path to your credential file. Read the table with spark.read.format("deltaSharing") using the profile path followed by #<share>.<schema>.<table>.

Use Power BI Desktop 2.99.621.0 or above with the OpenSharing connector. Open the shared credential file to get the endpoint URL and bearer token, then enter the URL in the OpenSharing Server URL field and the token in the Bearer Token field. Your shared tables are then available in Power BI.

A Databricks-to-Databricks share needs no recipient token or credential file: a metastore admin, or a user with CREATE CATALOG and USE PROVIDER, creates a catalog from the share with CREATE CATALOG <catalog> USING SHARE <provider>.<share>, and the recipient's workspace must be enabled for Unity Catalog.

The provider identifies the recipient by the sharing identifier of the Unity Catalog metastore attached to the recipient's workspace. Databricks-to-Databricks sharing works within the same environment type, so match the recipient's environment. Sharing with Azure Government environments is not supported.

Yes. OIDC federation lets the recipient authenticate with a JWT from its own identity provider instead of a long-lived Databricks-issued bearer token, and Databricks does not generate or manage tokens in that model. You collect the issuer URL and subject claim from the recipient, and creating the recipient requires CREATE RECIPIENT on the metastore.

No. Open sharing is designed for recipients who do not use Databricks or do not have a Unity Catalog-enabled workspace, and they can read shared data with Power BI, pandas, or open-source Apache Spark. Recipients invited by email sign in with a Databricks account that uses the invited email address.

Sharing data and AI assets within a region with OpenSharing incurs no egress cost. Sharing across clouds or regions can incur data egress fees from your cloud vendor. For R2 storage, view sharing may still incur egress costs.

The OpenSharing egress pipeline notebooks, available in the Marketplace listing, record egress bytes transferred and attribute them by share and recipient. Running the notebooks as a Lakeflow pipeline template produces a cost report automatically. To avoid egress costs altogether, providers can keep local replicas using Delta DEEP CLONE or change data feed.

SecureConnect supports sharing to recipients regardless of the cloud they run on, for both Databricks-to-Databricks and Databricks-to-open sharing. Cross-region and cross-cloud recipients, along with recipients on classic compute, read through a managed proxy. Providers can also share from cloud storage behind a private endpoint.

Providers are billed for data transfer (egress) when recipients access shared data through SecureConnect. Databricks is expanding SecureConnect networking billing to more charge types, including charges for recipients, so review the current billing details as they evolve. Factor these charges into cost planning for cross-cloud recipients.

With system tables enabled, Delta Sharing audit events are recorded in system.access.audit. The provider logs capture recipient queries (deltaSharingQueriedTable and deltaSharingQueriedTableChanges) and recipient credential requests (generateTemporaryTableCredential and generateTemporaryVolumeCredential, in the scenarios where they apply), and failed sharing operations include the error message. Use these logs to audit which tables recipients queried and when.

Each metastore supports 1,000 providers, 5,000 recipients, and 1,000 shares. Each catalog supports 20 shares, each share supports 1,000 tables and 1,000 volumes and 100 notebooks, and these values are listed on the resource limits page and may change over time. Plan your share and recipient layout with these limits in mind.

Databricks Marketplace is an open exchange where data providers, software vendors, and technology partners publish offerings. Listings can include datasets, AI models, notebooks, apps, and Model Context Protocol (MCP) servers, and providers can offer free sample data as well as commercial data products. Listings can be public or limited to a private exchange.

Log into a Databricks workspace to request data products. Products marked for instant access appear as a read-only catalog in Catalog Explorer after you click Get instant access and accept the terms, and products marked By request let you send a request that the provider reviews. Products marked By request need provider approval before access.

Yes. Databricks recommends sharing sample notebooks, and a listing can include up to 10 notebook previews that consumers can import into their workspaces to see how to use the data. Consumers import the notebook into their own workspace to run it.

A share bundles tables, views, volumes, and AI models into one securable unit, and a listing publishes that share on Marketplace. Tables can be shared with any consumer, while volumes, AI models, and notebooks are available to consumers whose workspace has Unity Catalog enabled. Tables can be shared with any consumer, which gives the widest reach.

To publish a listing, a provider needs a Databricks account enabled for OpenSharing and a workspace enabled for Unity Catalog, must complete provider setup (sign up as a public or private provider, create a provider profile, and assign the Marketplace admin role), and must follow the Marketplace provider policies.

A private exchange limits a listing to selected consumers who are members of it, so only those members can browse, view, and request the listing. When you publish to a private exchange, select at least one exchange from the drop-down list. Only members of the exchange can see the listing, which gives controlled access.

Databricks Clean Rooms lets multiple parties analyze sensitive data together without directly accessing each other's data. It uses OpenSharing and serverless compute, and each clean room runs in an isolated central environment managed by Databricks, where collaborators share their tables, views, volumes, and notebooks with the central clean room. Collaborators keep control of their data without granting each other direct access.

A clean room supports up to ten parties: the creator plus up to nine collaborators. Create it in Catalog Explorer and enter the Clean Room sharing identifier for each collaborator. The clean room name and network access policy type are fixed once the clean room is created, so set them deliberately.

Every clean room notebook is reviewed before it runs: all collaborators except the uploader approve or reject it from the notebook details, and the review gives each party a say. Only the latest version of a notebook can be run or approved, and only the collaborator designated as runner can start the run. Reviewing every notebook before it runs gives collaborators a shared control point.

Output tables are temporary, read-only tables generated by a clean room notebook run. The runner and the clean room owner have default read access, and a metastore admin can grant read access to others. Output tables are kept for 30 days in the central clean room's default storage and shared to the runner's metastore using OpenSharing.

In a packaged clean room, the provider authors the notebooks and JARs and contributes data assets. The consumer contributes their own data, triggers runs, and views the run output, without access to the provider's notebook or JAR code. Neither collaborator can see the other's data assets, which protects both sides.

The resource limits page lists 100 clean rooms per metastore, 10 clean room notebook tasks running simultaneously per clean room, 100 output tables per notebook task run, and 10 versions per clean room analysis. These values are listed on the resource limits page and may change. Plan clean room workloads around the limit of 10 simultaneous notebook tasks.

The resource limits page lists up to 250 listings per metastore and up to 20 providers per account. The Marketplace Consumer and Provider APIs are each limited to 100 requests per second per workspace, and these values may change over time. Plan Marketplace usage around the per-workspace API rate limits.

No. For instantly available listings, providers do not need to approve each consumer's access, because the provider does nothing per consumer to grant access. Approval workflows apply to listings that involve a commercial transaction or require customization, and providers handle those requests in the Consumer requests tab of the Provider console.

A share. To list a data product that is free and instantly available to consumers, you must include a share when you create the listing. Databricks Marketplace providers create listings in the Provider console, so the share is part of the listing setup from the start.

No. Collaborators do not need to enable serverless compute in their own workspace to use clean rooms. An account admin does need to accept the serverless compute terms of service, and serverless compute is required for central clean rooms, where clean room analysis runs.

The sharing identifier is a string made of your global metastore ID, your workspace ID, and your username (email address). Collaborators send their Clean Room sharing identifier to the clean room creator, who uses it to share the clean room with them. Once the clean room appears in your Unity Catalog metastore, grant users in your organization access to it.

A clean room needs a serverless-enabled workspace, Unity Catalog, and OpenSharing enabled on the metastore. Clean rooms run on serverless compute inside a central environment that Databricks manages. Collaborators approve every notebook before it runs, so analysis stays governed from the start.

Plan collaborators before you create the room, because each clean room supports up to ten parties (the creator plus nine collaborators) and you enter each collaborator's Clean Room sharing identifier at creation. Every collaborator, including the creator, has equal privileges, and all collaborators must approve a notebook before it runs.

Yes. Tables, streaming tables, views (including dynamic views that restrict rows and columns), and materialized views can be added to a share, and metric views can be shared too. Metric views are shared through the Databricks-to-Databricks sharing flow. A share is a read-only collection of these assets that recipients can query.

No. Once data is shared, consumers can access and work with it without a Databricks workspace. Requesting data products through Marketplace does require a Databricks workspace. Access varies by listing: some listings are available instantly after you request them and agree to the terms, while others need provider approval.

Yes. Partner Connect lets you create trial accounts with select Databricks technology partners. Marketplace listings include datasets, AI models, notebooks, apps, and Model Context Protocol (MCP) servers, so you can find data and AI building blocks in one place, including the partner products you want to evaluate.

Yes, within a limit. Databricks users can apply up to 10% of their Universal Commits toward eligible third-party partner products. This lets existing commitment spend support the partner data and AI offerings your team evaluates in Marketplace. Marketplace is the place to find those eligible partner products, with listings covering datasets, AI models, notebooks, and apps.

Yes. In Catalog, go to Share, then Clean Rooms, select a provider under Identity Resolution Providers, choose a region, and click Create Clean Room. The clean room opens with the provider as package provider and shared output enabled. Listed providers include Acxiom, Adstra, LiveRamp, and The Trade Desk. On Enterprise accounts this option is off by default, so an account admin must turn on the Cleanroom Identity Resolution Partners creation preview first.