Microsoft Fabric Cross-Tenant Data Sharing: A Governance Architecture for OneLake

Executive summary

Microsoft Fabric can expose live OneLake data to another Fabric tenant without building a copy pipeline. The receiving organization gets a read-only shortcut to the provider's data and can use it from Fabric workloads in its own tenant. That can simplify partner analytics, group-company reporting, regulated data collaboration, and post-acquisition integration.

The architectural trap is to treat "read-only" and "no copy" as equivalent to "governed." Microsoft states that provider-side governance controls do not automatically flow across the tenant boundary. The provider cannot determine every user to whom the consumer grants access, and label inheritance, export encryption, and similar information-protection behaviours are not enforced in the consumer tenant. Microsoft also warns that revoking a share irreversibly breaks dependent artifacts in the receiving tenant. As of 28 September 2026, the relevant Fabric tenant settings are documented as preview features. These conditions make external sharing an operating-model problem, not merely a permissions task.

The practical answer is a two-sided data-product contract:

1. The provider publishes only approved, minimised, stable data through a dedicated share zone.
2. The consumer lands the shortcut in a controlled lakehouse and applies its own access, classification, usage, and monitoring policies.
3. Both parties maintain a share register, schema and service-level contract, change process, incident route, geographic-use rules, and tested exit plan.

This design preserves the speed of in-place sharing while placing accountability around the places where Fabric's technical boundary ends.

The enterprise problem: cross-tenant access without cross-tenant control

Enterprises increasingly need to analyse data across legal and identity boundaries. A manufacturer may share supply-chain events with a logistics partner. A healthcare group may combine de-identified operational data from separately managed entities. A newly acquired business may need access to group metrics before identity and platform consolidation is complete. A data provider may want customers to analyse current product data without exchanging recurring files.

The old choices are awkward. File exchange creates uncontrolled copies and reconciliation work. Bespoke extract, transform, and load (ETL) pipelines introduce latency, failure points, duplicate storage, and credentials to manage. Granting external users access inside the provider's tenant can make identity administration and workspace isolation harder.

Fabric external data sharing offers another route. The provider can share selected tables or files from supported Fabric items. The consumer accepts the share into a lakehouse, where Fabric creates a read-only shortcut to the live source. Microsoft says the feature uses Fabric-to-Fabric authentication rather than requiring an Entra B2B guest account, and the data is not copied merely by creating the share. Both tenants must enable the corresponding tenant settings, and their administrators can restrict who is allowed to create or accept shares. Microsoft's external data sharing overview explains the flow, while the export and sharing settings reference describes the administrative controls.

That removes data movement infrastructure, but it does not create a single cross-tenant policy boundary. Microsoft is explicit: governance controls from the provider tenant do not automatically execute in the consumer tenant. The consumer must apply its own governance, access control, and compliance policies. The provider cannot control all downstream access inside the receiving tenant, and the consumer can potentially grant access to others, including guests. Data can also cross geographic boundaries when a consuming workload reads it. These are not edge cases; they define the trust model.

Representative scenario: a live partner operations feed

The following is a representative scenario, not a real YuniQ customer case and not a claim of achieved results.

A multinational manufacturer wants a strategic logistics partner to analyse shipment milestones, route exceptions, estimated arrival times, and service-level performance. Both organizations use Microsoft Fabric in separate Entra tenants. The manufacturer currently sends a daily extract, so the partner's operational view can be almost a day behind. Reconciliation disputes arise when a corrected source record and yesterday's file disagree.

The manufacturer proposes an external OneLake share so the partner can query current, provider-owned tables. The first design shares a broad Gold lakehouse folder with a partner analyst. It appears efficient, but a review exposes six material risks:

• The folder contains internal cost and customer-reference columns that the partner does not need.
• The person creating the share has broad Read and Reshare permission rather than a specific publishing role.
• The partner plans to place the shortcut in a general analytics workspace with many contributors.
• Neither party has recorded the allowed geography, retention expectation, or onward-sharing rule.
• A column rename could break the partner's semantic model without warning.
• The provider assumes it can revoke access cleanly, but the consumer is building operational reports on the share.

The business need is valid. The proposed control model is not. The remedy is to turn the shared dataset into an explicitly governed product with two responsible owners and a managed lifecycle.

Root causes and consequences

The source boundary is mistaken for the consumption boundary

Provider-side controls still matter, but they do not govern every downstream action. Microsoft documents that label visibility, downstream label inheritance, export encryption, and similar Microsoft Purview Information Protection and data loss prevention behaviours do not automatically carry into the consumer tenant for external data sharing. Fabric's broader information protection documentation also states that sensitivity-label access control is unsupported for cross-tenant external data-sharing access.

The consequence is a policy gap. A dataset that is correctly labelled and tightly controlled at source can become broadly usable after it is accepted into a loosely governed consumer workspace.

Sharing authority is inherited from ordinary item permissions

Microsoft allows users with the required Read and Reshare permissions, subject to the tenant setting, to create external shares. If the tenant setting applies too broadly, a routine collaboration permission can become authority to publish enterprise data across an organizational boundary.

The consequence is decentralised risk acceptance. Data owners, privacy teams, or legal stakeholders may not know that a share exists until an incident or contract review.

"No copy" is interpreted as "no movement"

The share is in place, but data is accessed when the consumer runs a workload. Microsoft warns that this access can transfer data across geographic boundaries. The consumer may also produce derived tables, exports, semantic models, or machine-learning features within its own environment.

The consequence is that residency, contractual-use, and retention obligations can be breached even though no provider-managed ETL pipeline exists.

A live share is treated like a stable API

The shortcut reflects current source data. That removes extract lag, but it also exposes the consumer to schema changes, data-quality regressions, late corrections, maintenance windows, and upstream availability.

The consequence is hidden operational coupling. A provider change can break a consumer report or decision process without a deployment in the consumer tenant.

Revocation is treated as a reversible permission change

Microsoft's share-management guidance says revocation is irreversible for that share and that dependent artifacts in the consumer tenant cease to function. A replacement share requires the consumer to rebuild work against the new shortcut.

The consequence is a poor choice during incidents: leave risky access open or cause an unplanned business outage.

Why common approaches fall short

Enable the feature for the whole organization

This optimises initial adoption at the cost of accountability. Tenant settings should be scoped to controlled security groups for approved publishers and acceptors, with membership tied to a defined process.

Share the existing Gold layer directly

"Gold" usually means business-ready inside an organization, not safe for an external party. Internal identifiers, commercially sensitive attributes, row history, or undocumented semantics may still be inappropriate. A separate external share product should expose only the approved contract.

Rely on a sensitivity label to follow the data

Labels remain important inside each tenant, but Microsoft documents cross-tenant limitations. The consumer needs to classify and protect the received data under its own policies, and contractual controls must cover uses that the provider cannot technically enforce.

Use a generic workspace and broad Contributor access

Workspace Admin, Member, and Contributor roles are powerful collaboration roles. Treating them as ordinary consumer access can bypass the granular intent of data-level controls. The landing workspace should have a small administration group, separate build identities, and consumer access delivered through narrower item or data permissions where possible.

Make revocation the only exit plan

Revocation is an emergency stop, not a migration design. Planned termination needs notice, dependency inventory, a replacement or archive decision, consumer validation, and a coordinated cutover.

A governed Microsoft Fabric solution

1. Establish the trust contract before enabling sharing

Create a joint provider-consumer decision record that answers five questions:

• Purpose: Which decisions or processes may use the data?
• Scope: Which fields, rows, time horizon, and update frequency are necessary?
• People: Who owns the data, who administers the share, and who receives incidents?
• Place: In which tenant, region, workspace, and downstream environments may it be used?
• Period: How long is the agreement valid, how often is it reviewed, and how will it end?

Record privacy, legal, security, and data-residency approval where applicable. Where the provider cannot technically prohibit onward sharing, make the restriction explicit in the inter-organizational agreement and require the consumer to implement compensating controls.

2. Create a provider-side external share zone

Do not publish directly from a broad operational lakehouse. Build a dedicated, provider-owned share product containing only stable, approved tables or files.

Recommended design principles:

• Materialise approved data into the share zone; do not depend on shortcuts nested inside a shared folder because Microsoft states those shortcuts will not resolve in the consumer tenant.
• Minimise columns and rows before publication. Tokenise, aggregate, or exclude identifiers when the use case permits.
• Use documented business keys, units, time zones, null semantics, and classification.
• Separate partners or trust classes when their allowed scope differs.
• Give a small publishing group Read and Reshare permission; scope the External data sharing tenant setting to that group.
• Keep day-to-day engineering roles separate from authority to approve an external release.
• Publish a schema version and compatibility policy with the data.

The share zone is an external interface. Treat its tables as a versioned product, not as an incidental view of internal storage.

3. Create a consumer-side controlled landing zone

In the consumer tenant, scope the Users can accept external data shares setting to an approved acceptor group. That group should accept shares only into a dedicated lakehouse in a governed landing workspace.

The landing workspace should have:

• Named business and technical owners.
• Minimal Admin, Member, and Contributor membership.
• Consumer-side OneLake security and item permissions aligned to approved personas.
• Local sensitivity classification, endorsement, and catalogue metadata.
• Separate downstream workspaces for transformation, semantic modelling, and broad consumption.
• Controls over export, guest access, and onward distribution appropriate to the data classification.
• A dependency record linking the shortcut to every critical semantic model, report, notebook, pipeline, or derived table.

This is where the consumer recreates the missing local policy context. It is also where the consumer can isolate an incoming share before promoting it to trusted downstream products.

4. Apply a data contract and change protocol

For each shared table or file set, define:

Use additive schema changes by default. For breaking changes, publish a parallel version, allow the consumer to test, reconcile business measures, and retire the old version only after explicit acceptance.

5. Separate the data plane from the control plane

The Fabric share carries data access. A separate control plane should carry approvals, ownership, evidence, and lifecycle state.

Maintain a share register with at least:

• Provider tenant, workspace, item, path, and data-product version.
• Consumer tenant, landing workspace, lakehouse, and shortcut.
• Provider and consumer business, technical, security, and privacy contacts.
• Purpose, classification, lawful or contractual basis where relevant, and approved geography.
• Created, accepted, last reviewed, next review, and intended expiry dates.
• Data-quality and freshness objectives.
• Critical downstream dependencies and business processes.
• Incident, schema-change, suspension, and revocation procedures.

Microsoft documents that Fabric user actions can be investigated through Microsoft Purview Audit. Use the Fabric audit guidance as one evidence source, but do not assume an audit trail replaces the share register or business approval. Reconcile platform evidence to the register on a schedule and investigate unregistered or stale shares.

6. Design revocation and continuity together

Create two procedures:

Emergency suspension: define who may act, the decision threshold, the expected consumer impact, communications, evidence preservation, and the method for restoring service through a newly approved share if required.

Planned termination: freeze new dependencies, enumerate existing ones, agree the final usable date, decide whether derived data must be deleted or retained, migrate or retire consumer artifacts, validate the outcome, and only then revoke.

Run a tabletop exercise before a high-impact share becomes operational. A technically successful revoke that surprises an operational team is not a successful control.

Reference architecture

PROVIDER TENANT                                    CONSUMER TENANT

Source products                                    Restricted landing workspace
  Bronze / Silver / internal Gold                    External-share lakehouse
             |                                                |
             v                                                v
External share zone                                  Read-only OneLake shortcut
  minimised rows/columns                                      |
  stable versioned schema                                     v
  quality and freshness tests                         Consumer-side controls
             |                                         classification and catalog
             | Fabric external data share              OneLake/item permissions
             +---------------------------------------> export/guest restrictions
                                                               |
                                                               v
                                                      Governed downstream products
                                                       semantic models / reports
                                                       notebooks / derived tables

                    JOINT CONTROL PLANE
  approval + share register + data contract + change calendar
  audit review + incident route + geography rules + exit plan

The architecture deliberately has two governance domains. The provider controls what leaves and the source-side access. The consumer controls who can use the received data and what can be built from it. The joint control plane makes those responsibilities explicit.

Phased implementation roadmap

Phase 0: decide whether external sharing is the right pattern

Classify the use case, recipient, geography, latency need, operational criticality, and onward-use risk. Compare external sharing with B2B collaboration, a cross-tenant delegated OneLake shortcut, an API, or a governed extract. Microsoft distinguishes external sharing from cross-tenant shortcuts: the latter use a delegated identity in the provider tenant and have a different permission model. The OneLake shortcut security documentation describes delegated cross-tenant controls.

Exit criterion: architecture, security, privacy, legal, and business ownership agree on the pattern and its limitations.

Phase 1: prove the control model with low-risk data

Scope publisher and acceptor groups, build the provider share zone and consumer landing workspace, create the register, and share a non-sensitive dataset. Test authorised and unauthorised personas, query paths, exports, audit visibility, schema changes, and revocation impact.

Exit criterion: evidence shows that the intended users can work and unintended users cannot, with responsibilities understood in both tenants.

Phase 2: productionise one bounded data product

Implement minimisation, quality gates, freshness monitoring, versioning, consumer classification, downstream dependency tracking, and operational support. Run a parallel comparison against the current exchange method and reconcile record counts and business measures.

Exit criterion: owners accept the data, service objectives, security evidence, and cutover result.

Phase 3: scale through reusable policy

Create standard templates for approval, contracts, share-zone design, consumer landing zones, evidence collection, and exit planning. Review tenant-setting group membership and the share register regularly. Establish a cross-tenant data-sharing review forum for exceptions and high-impact changes.

Exit criterion: new shares follow a repeatable route without bypassing risk ownership.

Phase 4: exercise failure and exit

Simulate a provider schema defect, consumer overexposure, partner incident, geographic-policy breach, and contract termination. Measure detection, decision, communication, technical action, and recovery times.

Exit criterion: both organizations can suspend or retire the share without improvising under pressure.

Governance, security, adoption, and cost considerations

Governance

Assign a provider data owner and a consumer use owner. The provider is accountable for scope, correctness, and source continuity. The consumer is accountable for local access, derived use, redistribution, and downstream retention. Require periodic recertification rather than indefinite approval.

Security and privacy

Start with minimisation, because a column never shared cannot be exposed downstream. Use separate external products for materially different audiences. Test access from the consumer's real personas and engines, not only from an administrator account. Treat contractual and organizational controls as necessary where provider policies do not cross the tenant boundary.

Adoption and operating model

Give consumer teams a clear catalogue entry, sample queries, semantic definitions, incident route, and change calendar. Train administrators on the difference between OneLake external sharing, Entra B2B content sharing, and delegated cross-tenant shortcuts; Microsoft's tenant settings documentation treats them as distinct mechanisms.

Cost and capacity

In-place sharing can avoid provider-managed duplicate pipelines and storage copies, but it does not remove consumption cost. Microsoft states that collaborators use their own organization's licences and capacities. Baseline consumer query, Spark, SQL, Power BI, and downstream transformation demand during the pilot. Attribute capacity consumption to the shared product, set workload expectations, and decide whether frequently reused transformations should be materialised locally. Do not size production capacity from a single administrator test.

Feature maturity

As of 28 September 2026, Microsoft's tenant-settings reference labels the External data sharing and Users can accept external data shares settings as preview. Confirm current regional availability, support status, limitations, and organizational preview policy before production adoption. Revalidate this status during every architecture review because cloud service behaviour and documentation can change.

Success metrics

Measure control and business value together:

Avoid declaring success simply because the share is live. A successful implementation is one that remains understandable, supportable, and terminable after the original project team has moved on.

How YuniQ can help

YuniQ's Microsoft Fabric consulting and implementation services align with the work required to make cross-tenant sharing operationally credible.

• Fabric Strategy & Readiness: YuniQ describes current-state diagnostics, use-case prioritisation, capacity planning, workspace topology, and security, governance, and operating-model design. For external sharing, this can frame pattern selection, trust boundaries, accountabilities, and the first controlled use case.
• OneLake & Data Architecture: YuniQ lists enterprise information architecture, medallion layers, domain boundaries, shortcut design, and semantic modelling. These capabilities map to the provider share zone, consumer landing pattern, and stable external data contract.
• Governance, Security & DevOps: YuniQ states that its services cover Entra ID least-privilege roles, Microsoft Purview integration, sensitivity labels, lineage, auditable logging, CI/CD, and monitoring. These are relevant to scoped sharing authority, local consumer controls, evidence, and managed change.
• Proof of Value and implementation: YuniQ describes focused proofs of value using production-grade data, followed by reusable pipelines, data products, semantic models, validation, and controlled launch. That staged model suits a low-risk external-sharing pilot before broader adoption.
• Fabric Managed Services: YuniQ lists pipeline and refresh monitoring, capacity optimisation, DevOps release management, and continuous domain expansion. Those services can support the ongoing reviews, performance management, and change discipline that a live cross-tenant product requires.

The appropriate engagement is not simply "turn on external sharing." It is to prove that one valuable cross-tenant use case can meet its business objective while producing evidence for security, performance, governance, and exit readiness.

Practical next steps

1. Inventory current cross-organization files, APIs, pipelines, B2B workspaces, and unofficial extracts.
2. Choose one high-value use case where freshness matters and the data can be tightly minimised.
3. Name provider and consumer business, technical, security, privacy, and support owners.
4. Decide whether Fabric external sharing is preferable to B2B access, a delegated cross-tenant shortcut, an API, or an extract.
5. Build the share register and operating contract before enabling the tenant settings.
6. Run a low-risk pilot with a dedicated provider share zone and consumer landing lakehouse.
7. Test positive access, negative access, export paths, geographic behaviour, schema change, capacity impact, incident response, and revocation.
8. Scale only after both tenants accept the evidence and the ongoing ownership model.

Cross-tenant analytics becomes safer when the technical shortcut is surrounded by deliberate boundaries. Fabric can remove the mechanics of copying data. It cannot remove the need for two organizations to agree who is accountable for what happens next.