Data Sharing workflows

In most systems, a data share is a read-only collection of tables to be shared with one or more data share recipients. Tables are typically added and removed from shares, and access granted to or revoked from data share recipients. A share recipient is an object that associates someone or something with a credential or identifier for secure data sharing and allows that someone to access one or more shares –  a consumer account in Snowflake or a delta share recipient in Unity Catalog are two good examples.

This distribution includes a simple asset model with a new data share, data share recipient asset and issue requests.

Why creating a new data share asset when we have data sets? And why having the data share under a data set asset? As a data provider and producer you may decide not to share all your data sets. Data sets, as of today, they typically hold relations to columns while most system data shares are often collection of tables instead. Finally, and this will likely change in future Collibra releases, if you want a given asset to be pushed to your shopping basket this asset must be either child of a data set or report asset. Ideally this new data share asset type would sit next to or side by side with the data set asset. that will have to wait until the shopping basket implementation is revisited.

As the data provider creates shares and recipients, adds to or removes tables from a share, grants to or revoke access from recipients,  requests are issued for processing.

Below you’ll find a short video showing how shares can be created, updated, access requested and granted with Databricks. The integration piece is not included here.