Databricks Delta Sharing Guide: Publish, Consume, and Audit Governed Data Products

Overview

Delta Sharing is best understood as a controlled publishing model. A provider owns or manages the data and defines what can be shared. A recipient consumes the published data through an approved access method. The provider decides which share objects are available, while the recipient uses the resulting data in an authorized environment or workflow.

In a Unity Catalog environment, the share should be designed as a data product rather than as an informal export. That means documenting its purpose, selecting only the necessary tables or views, assigning an owner, and establishing a review date before onboarding a consumer. The exact screens, authentication choices, and supported sharing modes can change, so confirm the current Databricks documentation and workspace behavior before production rollout.

A typical publishing workflow looks like this:

1. Define the business purpose, recipient, data classification, and expected usage.
2. Confirm that the provider has authority to share the source data and administer the relevant Unity Catalog objects.
3. Select the tables or views that form the data product, preferably exposing only the columns and rows required for the use case.
4. Create or configure the share and grant the recipient access through the chosen authentication and delivery model.
5. Test the recipient experience with non-production validation or a limited initial release.
6. Record ownership, approval, access details, audit locations, and the next review date.

For AI and analytics teams, this approach can support shared feature data, evaluation sets, reporting datasets, and governed inputs for downstream applications. It should complement—not replace—broader data governance, model evaluation, and workload security practices. For related controls, see the Databricks AI Governance Checklist.

What to track

Provider and recipient responsibilities

Track the data product, not just the permission

A permission review is incomplete if it checks only whether a recipient can connect. Maintain a lightweight register with the share name, provider owner, recipient organization or team, approved purpose, data classification, included tables or views, expected refresh pattern, authentication method, approval date, last review date, and planned expiration or renewal date.

Track these recurring signals:

• Access activity: whether the recipient is using the share and whether activity matches the stated purpose.
• Scope: whether new tables, views, columns, or derived objects were added after approval.
• Schema and quality: whether column changes, null patterns, freshness, or record volumes affect the recipient’s workflow.
• Authentication health: whether credentials, tokens, or identity mappings need rotation or revalidation.
• Operational impact: whether recurring queries or downstream jobs create unexpected cost, load, or support requirements.
• Business need: whether the recipient still has a documented reason to receive the data.

Audit details depend on the configured sharing method and the Databricks capabilities available in the relevant environment. Record where the team checks access and operational events, then verify those records during each review instead of assuming that an unobserved share is unused.

Cadence and checkpoints

Use a short monthly operational check and a more formal quarterly access review. High-sensitivity data, externally consumed products, or rapidly changing datasets may justify a shorter interval. The schedule should be based on risk and change frequency rather than applied uniformly.

Monthly operational check

• Confirm that the share is available and that expected recipient workflows are succeeding.
• Review recent schema, ownership, and documentation changes.
• Check for failed jobs, unusual activity, expired credentials, or support requests.
• Compare the current share contents with the approved data-product definition.
• Record exceptions and assign an owner with a target resolution date.

Quarterly access-review template

Copy the following fields into the team’s governance register or ticketing system:

• Share and provider: name, owner, business sponsor, environment.
• Recipient: organization or team, technical contact, approved use case.
• Current scope: tables, views, important columns, row filters or other documented restrictions.
• Classification: sensitivity level and handling requirements.
• Activity summary: recent access observed, expected usage, anomalies, and unresolved incidents.
• Quality summary: freshness, schema changes, known limitations, and recipient feedback.
• Decision: renew unchanged, reduce scope, update documentation, suspend, or revoke.
• Approvers: provider owner, data owner, security or governance reviewer where required.
• Next review: date, trigger conditions, and assigned reviewer.

When onboarding a new partner, complete this register before sending connection instructions. A partner onboarding checklist should also confirm identity verification, contractual or organizational approval where applicable, recipient-side credential storage, test access, support contacts, and a documented shutdown path.

How to interpret changes

Changes in activity are signals for investigation, not automatic evidence of misuse. A decline may indicate that the recipient’s project ended, a pipeline failed, or the dataset no longer meets its needs. A sudden increase may reflect a legitimate launch, a new reporting cycle, repeated retries, or an inefficient query pattern.

Use a simple sequence when something changes:

1. Compare the observation with the approved business purpose and expected schedule.
2. Check for recent releases, schema changes, credential events, or recipient-side deployment changes.
3. Ask the named technical contact to explain unexplained activity or failures.
4. Reduce scope or pause access when the purpose cannot be confirmed, following the organization’s incident and governance process.
5. Document the decision, evidence reviewed, and conditions for restoration.

Prefer narrower, purpose-built views when a recipient needs only a subset of a broad table. If the shared data feeds an AI application, separately monitor model and retrieval behavior; data access approval does not establish that an AI workload is accurate or safe. The Databricks LLM Evaluation Guide and Databricks RAG Tutorial cover adjacent evaluation concerns.

When to revisit

Revisit this guide and each individual sharing arrangement at least quarterly, and sooner when a recurring data point changes. Trigger an additional review when a recipient changes ownership, a business purpose expands, a new table or sensitive column is requested, authentication requirements change, the source schema is modified, an audit event is unexplained, or the data product is replaced.

At the end of each review, make one of four explicit decisions: continue unchanged, continue with reduced or revised scope, pause pending investigation, or revoke and document closure. Remove obsolete onboarding instructions and confirm that downstream jobs no longer depend on a retired share.

For the next review, schedule a calendar reminder now. Bring the current share definition, activity records, data-quality notes, recipient confirmation, and approval history. This small recurring habit turns Delta Sharing from a one-time connection into a maintainable, auditable data-product process.