Architectural Advice: D365 load - Cross Region Fabric link Issue

Hi vijith_mar​,
Thanks for reaching out to the Microsoft Fabric Community forum.

Your proposed approach is worth evaluating, particularly if you want to retain the native Dataverse-to-Fabric integration while serving production analytics from a UAE-based Fabric workspace.

1. European staging workspace with OneLake shortcuts

Microsoft's Link to Microsoft Fabric documentation specifies that the Dataverse environment and Fabric capacity must be in the same Azure geographical region. The integration creates a lakehouse and shortcuts for the selected Dataverse tables.

OneLake shortcuts can reference data across Fabric workspaces without creating another copy. This makes the proposed staging approach worth testing. However, Microsoft's documentation does not establish the performance characteristics of this specific Europe-to-UAE architecture, so validate it with representative data volumes and workloads before adopting it for production.

2. Direct Lake performance

Direct Lake semantic models can read supported Delta tables through OneLake shortcuts. Direct Lake is designed for high-performance analytics, but actual performance depends on factors including Delta table optimization, capacity resources, and the workload.
I recommend testing report responsiveness and query performance with the proposed cross-region setup rather than assuming that performance will be unaffected.

3. Is F2 capacity sufficient?

An F2 capacity provides 2 Capacity Units (CUs). However, the appropriate SKU depends on the workload, and the documentation does not establish that F2 is sufficient for every Dataverse synchronization scenario.
Use the Fabric Capacity Metrics app to monitor utilization during representative synchronization and reporting workloads, then adjust the capacity based on the observed demand.

4. Alternative: Copy the data to the UAE

If keeping production data physically within the UAE is a priority, consider using a Fabric Data Factory pipeline to copy the required data from the European staging lakehouse to a UAE lakehouse.
Copy activity supports moving data between data stores and provides settings to configure and optimize copy operations. This approach would also require you to manage pipeline execution, refresh frequency, data freshness, and the associated compute and storage requirements.
Recommendation

I would compare the two approaches in a proof of concept:
•    OneLake shortcuts: Evaluate the simplicity of accessing the European data from the UAE workspace without creating another data copy.
•    Physical data copy: Evaluate whether maintaining a separate UAE copy better meets your data residency, freshness, and performance requirements.

Measure report performance, synchronization or pipeline duration, and capacity utilization before selecting the production architecture. This will help determine whether the shortcut approach meets your requirements or whether physically copying the data to the UAE is more appropriate.

For more details, please refer to the below Official Microsoft documentation :

•  Configure your environment and link to Microsoft Fabric - Power Apps | Microsoft Learn
•  Unify Data Sources With OneLake Shortcuts - Microsoft Fabric | Microsoft Learn
•  Direct Lake overview - Microsoft Fabric | Microsoft Learn
•  Plan your capacity size - Microsoft Fabric | Microsoft Learn
•  How to copy data using copy activity - Microsoft Fabric | Microsoft Learn

I hope this helps. Please feel free to reach out if you have any further questions.
Thank you.

What about loading D365 data to fabric using API? Can we get exact same tables using this aproach?what is your opinion on this?

Hi vijith_mar​,

Your staging-workspace idea is a sound way to keep the Fabric Link work. I'd change one thing: don't let reports read across regions through the shortcuts. Use the shortcuts as the Bronze entry point, and materialize Silver/Gold in the UAE so everything users touch is local.

Europe (small F SKU)                  UAE (main capacity)
Dataverse -> Link to Fabric            Bronze lakehouse: shortcuts -> EU Fabric Link tables
  (staging workspace)                     |  notebooks / pipelines read via shortcut (cross-region, batch)
                                          v
                                       Silver / Gold lakehouse (physical Delta tables in UAE)
                                          v
                                       Direct Lake semantic models + reports (all local)

Why this split matters for your questions:

Direct Lake on cross-region shortcuts
  -> column data is pulled across regions when the model loads/pages it in
     (after refresh/framing and on cold queries), so first-load latency is what users feel
  -> on UAE-local Gold tables that cost disappears
cross-region reads happen once per load, in your notebooks, on a schedule you control
  -> instead of on every report open
the EU staging capacity only anchors the link
  -> compute for the Silver/Gold notebooks runs on the UAE capacity reading the shortcuts,
     so a small SKU in Europe is generally enough (validate with Capacity Metrics)

A minimal incremental copy from the shortcut into UAE Silver (using SinkModifiedOn from Fabric Link):

from delta.tables import DeltaTable
from pyspark.sql import functions as F

src = spark.read.table("bronze_eu.account")                      # shortcut to EU table
last = (spark.read.table("silver.account").agg(F.max("SinkModifiedOn")).first()[0]
        if spark.catalog.tableExists("silver.account") else None)
inc = src if last is None else src.filter(F.col("SinkModifiedOn") > last)

(DeltaTable.forName(spark, "silver.account").alias("t")
   .merge(inc.alias("s"), "t.Id = s.Id")
   .whenMatchedUpdateAll().whenNotMatchedInsertAll().execute())

Two non-technical checks before committing: data residency (copying EU Dataverse data into UAE storage may need sign-off from legal/compliance), and cross-region data transfer costs, which grow with how often you read through the shortcut. That's another reason to read incrementally on a schedule rather than at query time.

So my overall approach would be:

keep EU staging workspace + Fabric Link (small SKU)
-> UAE Bronze = shortcuts, read incrementally by notebooks
-> UAE Silver/Gold as physical Delta -> Direct Lake on local tables
-> confirm residency + transfer cost before go-live

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.