DP-600: OneLake Shortcuts and Integration Patterns for Fabric Analytics

OneLake shortcuts should expose existing data when the data can remain under its present owner, the consuming Fabric engine can read its format, and the identity path can be governed end to end. Use an internal shortcut to reference another OneLake location, an external shortcut to reference supported storage through a connection, OneLake availability to make eligible Kusto Query Language (KQL) database data discoverable outside the Eventhouse engine, and OneLake integration for an eligible Power BI semantic model when its imported table data must be available to other Fabric workloads. These patterns reduce redundant copies, but they do not make every source interchangeable.

The architecture therefore has four separate decisions: where the authoritative data stays, which mechanism exposes it, which identity reads it, and which engine interprets it. A shortcut is primarily a path reference rather than an ingestion pipeline; mirroring always adds source catalog metadata but can either replicate proprietary-format data or use shortcuts to reach supported open-format data in place; and a semantic model is a business layer rather than a general-purpose file store. If permissions, file format, or engine behavior do not align, a copied or replicated representation may be the correct design even though it creates another physical copy.

Architecture Overview

OneLake provides the tenant-wide logical data lake for Microsoft Fabric. A shortcut adds a reference inside OneLake so that an item can address data stored elsewhere without first copying that data into the item's own storage. The destination path looks local to consumers, but ownership, refresh behavior, and some security decisions remain associated with the source.

That separation is the foundation of a sound integration design:

The source remains authoritative. Its owner controls schema, retention, and availability.
The exposure mechanism creates reachability. A shortcut, OneLake availability, or semantic-model integration presents data through OneLake.
Identity establishes authorization. Fabric permissions and source-side access must both support the intended consumer.
The consuming engine establishes usability. Spark, a SQL analytics endpoint, a KQL database, and a Power BI semantic model do not interpret every path or format in the same way.

The current OneLake shortcuts documentation describes supported shortcut sources and their access considerations. Treat that support matrix as a deployment prerequisite because Microsoft Fabric is a continuously updated cloud service.

Internal and External Shortcut Patterns

Internal shortcuts keep Fabric data under one owner

An internal shortcut points from one OneLake location to another. This pattern fits a governed producer-consumer design: a source team owns a stable Delta table or file area, while one or more lakehouses reference it for their own analytical work. The consumers avoid independent copies and see changes at the referenced location without operating a separate copy schedule.

Internal shortcuts are useful for domain sharing, medallion designs, and reuse across workspaces, but a shortcut does not transfer ownership. The producer still controls schema evolution and retention. Consumers should therefore agree on a data contract, monitor breaking changes, and avoid modifying shared data merely because it appears beneath their item path.

Placement also matters. Put tabular data under a lakehouse Tables area only when the referenced data has a table format that the relevant Fabric engines recognize there. Put general files under Files. A visible path does not guarantee that a SQL or semantic-model engine can infer table metadata from arbitrary files.

External shortcuts virtualize supported cloud storage

An external shortcut points to a supported location outside OneLake through a Fabric connection. It is appropriate when the external system should remain the system of record and copying would add avoidable latency, storage, or operational work. The connection carries the credential context used to reach the external location; access to the Fabric item alone is not evidence that the external source will authorize the request.

External shortcuts require a deliberate trust boundary. Limit the connection to the required path, separate development and production credentials, plan credential rotation, and verify that downstream users cannot discover data beyond their intended scope. Also test the source's availability and request characteristics under the expected analytical workload. Removing a copy removes a synchronization job, but it makes the consumer more dependent on the remote source's latency, throttling, and availability.

Identity and Permission Boundaries

A shortcut joins namespaces; it does not collapse authorization layers. The effective design normally includes access to the workspace and item containing the shortcut, permission to use the referenced data, and—where an external connection is involved—authorization at the external storage system. The OneLake security overview separates workspace, item, and OneLake data access, which is why a successful shortcut creation test is not a complete consumer-access test.

Use least privilege and validate access with the real runtime identities. Test the author who creates the shortcut, an interactive analyst, a scheduled or service identity, and each relevant consuming engine. Record which identity is expected at every hop. Otherwise, a design may work for its owner while failing for readers, scheduled jobs, or semantic-model refresh operations.

Do not assume that permissions on a shortcut automatically reproduce row-, column-, or object-level rules from every source. Security enforcement depends on the source, connection, target item, and consuming engine. Where fine-grained security is required, verify the complete path and keep sensitive data out of broader file-level exposure until those tests pass.

Eventhouse and KQL Database Integration

An Eventhouse is optimized for high-volume event data held in KQL databases and queried with Kusto Query Language. Its native KQL experience remains the right interface for event-oriented exploration, filtering, time-series analysis, and operational investigation. OneLake integration is useful when the same eligible data must also participate in lake-centric analytics.

When OneLake availability is enabled for an eligible KQL database, Fabric exposes supported data through OneLake so other compatible workloads can reach it without building a separate ingestion path. A lakehouse can then reference that exposed data through an appropriate OneLake path or shortcut pattern. This is an access bridge, not a reason to replace the Eventhouse: the KQL database still owns event ingestion and KQL-native serving, while the lakehouse or another consumer owns its downstream analytical use.

The direction can also run into the real-time engine. Create a OneLake shortcut inside a KQL database when the KQL workload must query supported lakehouse, warehouse, another KQL database, or supported external-storage data without first ingesting it. The shortcut appears in the KQL database and is queried as an external table with external_table(). Confirm the source format and data-type mapping, and remember that this query path does not turn external files into natively ingested Eventhouse data.

Validate three constraints before adopting the pattern:

Confirm that the KQL database data and table features required by the solution are supported for OneLake exposure.
Confirm that the consuming engine can interpret the exposed representation and its schema.
Confirm that freshness and permission behavior meet the downstream service-level objective.

If the consumer requires KQL semantics, query the KQL database rather than treating its OneLake representation as an equivalent engine. If it requires durable reshaping or a different physical organization, that requirement belongs to a managed transformation and ingestion design rather than to the shortcut itself. The Real-Time Intelligence overview provides the current Eventhouse and KQL database context.

Power BI Semantic Models and Analysis Services Access

A Power BI semantic model contains relationships, measures, hierarchies, and business metadata. Its XML for Analysis (XMLA) endpoint provides Analysis Services-compatible connectivity for semantic-model query and management scenarios; it is not the same thing as exposing the model's stored table data as reusable OneLake files. Keep those two integration directions distinct.

One direction is data into a semantic model. A model can use supported OneLake-backed tables, including data reached through compatible shortcuts. Direct Lake may then be an appropriate table storage mode, but shortcut architecture alone does not determine Direct Lake eligibility or behavior. Transcoding, framing, refresh, fallback, and security interactions are covered separately in DP-600: Direct Lake Architecture, Refresh, Fallback, and Security.

The other direction is eligible imported semantic-model data out to OneLake. OneLake integration for semantic models can make supported import-model table data available as Delta tables in OneLake so Fabric workloads can reuse it. The exported table representation does not reproduce the semantic model's measures, relationships, calculation logic, or Analysis Services query behavior. Consumers that need governed business semantics should connect to the semantic model; consumers that need supported table data can use the OneLake representation. Check the current eligibility, refresh cadence, permissions, and limitations before designing around this capability.

This distinction prevents a common architectural error: treating OneLake exposure as if it were a lossless export of the semantic layer. It exposes data for compatible engines, while the semantic model remains the owner of business calculations and semantic metadata.

Shortcuts Versus Mirroring

Choose a shortcut when the consumer can read the source in place through a supported path, the source remains the data owner, and remote availability and performance are acceptable. Choose mirroring when Fabric should add an external database or catalog as a unit: database and open mirroring use replication patterns, while metadata mirroring synchronizes catalog metadata and uses shortcuts to access open-format data in place. Choose a deliberate ingestion or transformation process when the destination requires complex multi-source cleansing, restructuring, history management, or an independent operational boundary.

The distinction is physical and operational:

Pattern	Data location	Primary reason to use it	Main constraint
Shortcut	Remains at the referenced source	Reuse compatible data without another managed copy	Depends on source, identity, format, and consuming-engine support
Mirroring	Replicated into OneLake for database/open mirroring, or accessed in place through shortcuts for metadata mirroring	Add a supported external database or catalog as a managed Fabric item	Behavior and latency depend on the source-specific mirroring type
Ingestion or transformation	Written to a chosen destination	Reshape, cleanse, historize, or isolate data	Adds movement, orchestration, and ownership responsibilities

Mirroring is therefore not a more powerful shortcut, and a shortcut is not failed mirroring. They solve different ownership and data-movement requirements. The Fabric data storage guidance provides the current architectural context for stores, shortcuts, mirroring, and semantic models.

Format and Engine Constraints

Zero-copy access succeeds only when the consuming engine understands the referenced representation. Use these checks before committing to a shortcut-based architecture:

Path support: The source type and target location are supported for the shortcut being created.
File and table format: The referenced files form a representation the consumer recognizes, such as a supported Delta table where table semantics are required.
Metadata compatibility: Names, data types, partitions, and schema changes remain usable by the target engine.
Engine capability: Spark, SQL, KQL, and semantic-model engines use different metadata and query paths; success in one does not prove success in another.
Operational behavior: Source latency, throttling, regional or network constraints, and source outages remain visible to a zero-copy consumer.
Security behavior: The intended runtime identity receives only the required access at every layer.

If any check fails, do not hide the mismatch behind additional shortcuts. Select a supported copy, mirroring, or transformation boundary and make the new data owner explicit. The broader acquisition choice is developed in DP-600: Discovering, Connecting, and Ingesting Data in Microsoft Fabric, while analytical-store responsibility is covered in DP-600: Choosing Microsoft Fabric Analytics Stores: Lakehouse, Warehouse, Eventhouse, and Semantic Models.

Common Design Mistakes

Treating reachability as compatibility: A path can be visible even when the consuming engine cannot interpret its format or metadata.
Testing only as the shortcut owner: Interactive success does not prove access for readers, service identities, or scheduled operations.
Moving semantic responsibility into files: OneLake table data does not carry the measures and relationships owned by a Power BI semantic model.
Assuming shortcuts can perform any transformation: A basic shortcut references data, and current shortcut transformations can convert supported files or apply defined AI-powered operations. Complex joins, business rules, schema reshaping, and independent history still require a managed transformation or movement tool.
Equating mirroring with replication: Mirroring always adds catalog metadata, but database/open mirroring can replicate data while metadata mirroring uses shortcuts to access supported open-format data in place.
Ignoring producer change: Schema, retention, credential, or availability changes at the source can break every zero-copy consumer.

Conclusion

OneLake integration works best as an explicit contract among a data owner, an exposure mechanism, an identity path, and a consuming engine. Internal and external shortcuts minimize copies when the source and consumer are compatible; KQL databases can both expose eligible data through OneLake availability and query supported inbound shortcuts; and semantic-model integration exposes supported table data without replacing Analysis Services semantics. Mirroring adds an external database or catalog through either source-appropriate replication or metadata-backed shortcuts, while managed ingestion remains the better choice when complex transformation, isolation, or engine compatibility requires a new representation.