IQ Sharing in Fabric: share a whole lakehouse with another tenant, and the context with it

Sharing data with another company has usually meant a file, an API or a copy of the data in someone else's storage. Microsoft Fabric now has a new option in preview called IQ Sharing: you share an entire lakehouse, warehouse or mirrored item with a Fabric tenant you do not control, and you can ship business definitions alongside it.

It is a preview, so this is not a "migrate everything" post. It is a look at what the feature does, where the limits are, and how I would pilot it.

What IQ Sharing actually does

The producer creates a new item called a Share (preview) from the New item menu. This is different from selecting Share on an existing item, which only works inside your own tenant. In the Share you pick the source item, add recipients by email address or service principal, and set an expiration date.

The recipient accepts the invitation and chooses a workspace in their own tenant. Fabric then creates a Share Subscription item and a read-only OneLake Mirrored Item for each shared source. Those items contain shortcuts to the producer's data. Nothing is copied, and the consumer does not need an identity in the producer's tenant.

Some details I like:

• Added and deleted tables inside a shared item show up for the consumer automatically.
• Adding or removing a whole item from the Share is picked up when the consumer refreshes the Share Subscription.
• The supported item list is wide: lakehouses, warehouses, eventhouses, KQL databases and many mirrored sources such as SQL Server, Azure SQL Database, Snowflake and Oracle.

The context part

For a shared lakehouse, you can store Markdown files with business definitions, descriptions and usage guidance. They travel with the data.

Microsoft is careful here: these files help people interpret the data, but they do not automatically configure downstream analytics or data agents. So this is documentation that arrives in the right place, not automatic semantics. I still think that is worth having. Most partner data problems I have seen came from meaning, not transport.

What you need to know before you try it

The documentation is clear about the limits, and several of them matter:

1. It is preview. No service-level agreement, and Microsoft says it is not recommended for production workloads.
2. OneLake security rules are not honored. You can share an item that has OneLake security enabled, but those rules do not apply to consumers. Creating a Share on such an item needs Write and Reshare permission, and Write grants access to all data in the item. Decide what goes into the source item before you share it.
3. Consumers cannot use the shared items directly everywhere. OneLake Mirrored Items cannot be used directly in ontologies, data agents, semantic models or notebooks. The workaround is to create a lakehouse and add OneLake shortcuts to the shared data.
4. There are no email notifications. You copy the Share URL and send it yourself. The URL alone does not grant access, because recipients must sign in with the invited identity.
5. Every Share expires, and an expired Share cannot be extended. That is a good governance default, but it means someone has to own the renewal.
6. Revoking has consequences. A revoked recipient loses access immediately, and after a refresh the shared items are removed from their workspace. Downstream items such as data agents and semantic models can become unusable.
7. Region availability. The Learn page lists regions where IQ Sharing is not available, and the list includes Denmark East, North Europe and West Europe. If your capacity is in one of those, check this before planning a pilot.

On cost, there is no extra charge to create or manage Shares. The consumer's capacity pays for querying the shared data. Producers do not pay networking charges today, but Microsoft says they might in future and promises at least 90 days' notice.

How I would pilot it

If you have a partner who regularly receives data from you, this is a good candidate. I would keep the first round small:

1. Ask your Fabric admin to enable the Share Item (preview) and External data sharing tenant settings, and scope External data sharing to a named security group.
2. Pick one lakehouse that contains only data you are happy to expose in full, since the sharing unit is the whole item and OneLake security rules do not apply.
3. Write the Markdown definitions first: what each table means, grain, refresh pattern and known caveats.
4. Set a short expiration date on purpose, so the review happens.
5. Agree on a contact for each side before you send the URL. Revoking or expiring a Share breaks things downstream, so the consumer needs notice.
6. Ask the consumer to build their shortcut lakehouse and report what works and what does not.

Compare it with what you do today. Microsoft's own comparison table lists external data sharing, cross-tenant delegated shortcuts and the normal Share permission as alternatives. The guidance is to keep using external data sharing if it works for you, and to consider IQ Sharing for new implementations that share a whole item.

What this means for you

If you send data to partners, customers or other group companies, this is worth a pilot, not a rollout. The no-copy model and the expiration date solve real problems. The limits around security rules, downstream items and regions mean you should test with a non-critical dataset first.

After two decades in data, I would say the definitions are the part to get right. A shared lakehouse with weak documentation is still a support burden for both sides. A shared lakehouse with clear definitions and a named owner is a much better partnership.

Where would a cross-tenant share replace a file transfer or a custom API in your organisation?

Sources

• IQ Sharing overview (preview) (Microsoft Learn)
• Create a Share with IQ Sharing (preview) (Microsoft Learn)
• Manage a Share with IQ Sharing (preview) (Microsoft Learn)