This page is meant to stand on its own for a cold reviewer. It explains the business scenario, what the demo is intended to prove, what is running live in Azure today, what remains simulated in demo mode, and which repo assets to open if you want the operator guide instead of the customer-facing narrative.
Purpose
This is a pilot-friendly integration blueprint and review guide. It is not claiming that every production implementation should use the same hosting, auth, or data-model shortcuts.
Business scenario
Dynamics 365 remains the system where service and sales motion lives. Cases, contacts, and opportunities are still the operational records that a frontline team acts on.
Microsoft Fabric is where downstream analytics, enrichment, and scoring happen. OneLake receives raw events first, then notebooks or pipelines can turn those events into churn, VIP, or service insights.
Logic Apps is the control plane between the two. It receives events, normalizes payloads, writes them into OneLake, and optionally pushes action back into Dataverse when the tenant supports it.
Live demo scope
The three Logic Apps are deployed in Azure, can be triggered live, and have already been revalidated with successful run history and successful OneLake create, append, and flush operations.
The Fabric-to-CRM and booking writeback paths can simulate Dataverse success when tenant-side application-user setup is blocked. That keeps the business story intact without fabricating a fully wired CRM writeback.
The critical proof point for this demo is the event-driven integration pattern and the live OneLake path. The simulated Dataverse branch is called out explicitly so a reviewer can separate what is proven now from what would be enabled in a fuller tenant configuration.
Workflow set
A service case event lands in Logic Apps and is written into OneLake under a case-event path so Fabric can process disruption and service data later.
A Fabric notebook or pipeline posts customer scoring back toward Dataverse. In live mode that updates the contact and can create a retention case. In demo mode it returns the simulated success path instead.
A booking event drives both CRM-style motion and analytics motion from the same payload. In demo mode it synthesizes the Dataverse identifiers but still performs the live OneLake write.
How to review this quickly
Use this page to understand the business case, what is live, and why the architecture matters. It is the customer-facing explanation layer.
Use demos/azure-integration/logic-apps-fabric-d365/README.md for the deployment shape, parameters, auth model, sample payloads, and post-deploy testing steps.
Trigger the sample payloads, then open the Logic App run history and show the succeeded actions. That is the live proof for a reviewer who wants more than an architecture story.
Open demos/azure-integration/logic-apps-fabric-d365/docs/talk-track.md if you need a short customer-call narrative rather than raw implementation detail.
Open samples/case-created.json, samples/booking-pipeline.json, and samples/fabric-score.json to see the exact request bodies used to exercise the flows.
Open docs/tenant-setup.md and docs/dataverse-callback-runbook.md if you need the full tenant-side explanation of what would be required to remove demo-mode simulation later.
Cold review path
Start with the business framing: the point is to connect an operational system, an analytics plane, and a customer action loop without a heavyweight integration stack for the first pilot.
Then separate the proof points: the Logic Apps plus OneLake path is live and tested, while Dataverse writeback is intentionally simulated in demo mode because of tenant prerequisites, not because the architecture depends on hand-waving.
Finally, use the repo assets as evidence. The README is the operator guide, the talk track is the demo narrative, the sample payloads are the test artifacts, and Azure run history is the live proof.
Live walkthrough
1. Open this article and frame the scenario: Dynamics 365 is operational, Fabric is analytical, Logic Apps is the orchestration layer.
2. Trigger case-to-fabric with the case-created sample and show the OneLake write in run history.
3. Trigger booking-pipeline with the booking sample and show the demo-mode Dataverse IDs plus the live OneLake write.
4. Trigger fabric-to-crm with the fabric-score sample and show the simulated Dataverse success branch.
5. Close with the production path: remove demo mode, complete tenant prerequisites, and harden auth and replay patterns.This sequence gives a reviewer the architecture story, the live proof, and the limits of the current tenant setup in one pass.
Artifacts
Public article:
src/content/articles/logic-apps-dynamics-365-fabric-integration-demo.ts
Operator guide:
demos/azure-integration/logic-apps-fabric-d365/README.md
Narrative asset:
demos/azure-integration/logic-apps-fabric-d365/docs/talk-track.md
Tenant background:
demos/azure-integration/logic-apps-fabric-d365/docs/tenant-setup.md
Callback wiring:
demos/azure-integration/logic-apps-fabric-d365/docs/dataverse-callback-runbook.md
Test payloads:
demos/azure-integration/logic-apps-fabric-d365/samples/case-created.json
demos/azure-integration/logic-apps-fabric-d365/samples/booking-pipeline.json
demos/azure-integration/logic-apps-fabric-d365/samples/fabric-score.jsonA reviewer should not have to guess where the supporting artifacts live. These are the files that make the architecture story reproducible.
Production conversation
Replace the remaining Dataverse app-auth dependency with a tenant-approved identity path and remove demo mode once the Dataverse prerequisites are available.
Add replay, dead-letter, and decoupling patterns through Service Bus or Event Grid if the customer needs stronger delivery guarantees than direct HTTP orchestration provides.
Add Azure Monitor alerting, workflow-level operational telemetry, and a cleaner Dataverse field model before calling the pattern production-ready.
Reference path
https://onelake.dfs.fabric.microsoft.com/<workspaceGuid>/<lakehouseGuid>/Files/bookings/yyyy/MM/dd/<bookingId>.jsonThis follows the OneLake ADLS-compatible DFS endpoint model. GUID-based addressing avoids drift if the workspace or item name changes.