Dynamics 365: Learn in doing

<for my reference only: O25 = October 2025; DA4 = with Data Tag;> In this blog, I am just trying to summarize some key topics regarding the Data residency and options available with Microsoft Dynamics 365 Finance & Operations (ERP) in one place. This is considerable a big topic and I personally don't have too much experience working with On Prem implementations, myself - so including Microsoft links as much as I can. Hope this helps :)  So, Where Does Microsoft Store Data for D365FO? Microsoft Dynamics 365 Finance & Operations (D365FO) is a cloud-based ERP solution hosted on Microsoft Azure datacenters . When you deploy an environment, you select a region (geo) , and Microsoft ensures that your customer data at rest stays within that region. For European customers, this means data is stored in EU-based Azure regions like West Europe or North Europe . Microsoft may replicate data within the same geo for durability, but not outside it - there are always exceptions for...

<for my reference only: O25 = October 2025; DE5 = with Data Entity Tag;> To be honest, I haven't been fortunate to work on an Implementation project where I could use Virtual Entities, as much as I would love to - yet! However, I did encounter requirements of making ERP and CRM systems “talk” to each other seamlessly. And over the years, Microsoft has introduced several integration approaches - each with its own strengths, limitations, and setup nuances. In this post, I want to share what I’ve learned about Virtual Entities , their history, setup, and why they sometimes make more sense than other methods. And a short comparison to other available integration options like Dual Write , Data Integrator , and custom APIs. Virtual Entities: A concept old enough A Bit of History Out of curiosity, I have attended a Microsoft session 'Introduction to Dynamics 365 Customer Engagement - Basic of Customization' in late 2017 and that is when I heard about Virtual Entities for the...

<for my reference only: O25 = October 2025; DE4 = with Data Entity Tag;> If you’ve ever worked on data integrations or migrations in Dynamics 365 Finance & Operations (F&O), you know the pain of moving large datasets repeatedly. Enter Change Tracking - a feature that feels small but makes a huge difference. What is Change Tracking? Change Tracking lets you detect and export only what changed since the last sync, instead of dumping the entire dataset every time. This is used by Microsoft already in the out-of-the-box frameworks : Inbuild Integrations with Microsoft CRM or BI scenario. Could be used for integration towards external apps. Incremental data migration  using DMF during cutovers. BYOD exports where performance matters. Why It Exists Without Change Tracking: Every export = full dataset. More time, more cost, more risk of throttling.  Most costs (per transfer / transaction). With Change Tracking: Only inserts, updates, and (sometimes) deletes are expo...

<for my reference only: O25 = October 2025; DE3 = with Data Entity Tag;>   When working with data in Dynamics 365 Finance & Operations , one of the most useful skills is knowing where your data lives - which table or data entity holds the field you’re looking at. Why? Because this knowledge unlocks so many possibilities: Extracting data for analysis. Mass updates through Data Management . Building integrations or troubleshooting issues. Think of it as peeking behind the curtain to understand the architecture that powers your forms. Why This Matters Here’s a little reality check: Different fields on the same form can belong to different tables . A single field can appear in multiple data entities . And not all users have equal access - System Admins have the most visibility (SysTableBrowser, entity lists, etc.). So, if you’ve ever wondered “Where does this field actually come from?” , the below could guide you. Part 1: How to Find the Table Name for a Form Field Ope...

 <for my reference only: O25 = October 2025; DE2 = with Data Entity Tag;> While scrolling through LinkedIn, I stumbled upon something that made me happy and I think it will make your life easier too if you work with Dynamics 365 Finance & Operations . We all know the data model in D365FO can feel like a maze sometimes. Tables, relationships, inheritance - it’s powerful, but not always easy to visualize. That’s why these two tools shared by a fellow community member may make it a bit more easy for us. 1. D365 F&O Table Relation Schema https://daxonline.org/d365/entity-relation-schema.html This tool generates a DBML schema for the area you select and lets you instantly visualize the data model. Perfect for: Getting a clear overview of how tables connect. Documenting your work for future reference. Sharing diagrams with your team (you can render DBML using https://dbdiagram.io ). When I quickly tested it with CustTable and related tables like CustParameters , CustSet...

<for my reference only: O25 = October 2025; DE1 = Data Entity Tag;> What's a Data Entity (really)? A Data Entity is a business‑friendly view over one or more normalized tables (e.g., CustTable , addresses, contacts), packaged so you can import/export, integrate, and evolve with less pain when the underlying schema changes. Think: one door, many rooms behind it . Entities can also be exposed as OData (for APIs) and used by the Data Management Framework (DMF) for bulk import/export. Heads‑up: F&O does not allow direct T‑SQL against the prod DB. Entities (and BYOD) exist to keep you safe and supported. When should I create my own entity? You need a clean shape for integration—not ten joins. You plan to expose an API (OData) for a specific business concept. You want DMF import/export (files, recurring jobs, mapping) without writing plumbing. Step‑by‑step: Create an entity for Item Serial Numbers Example scenario: Export/import item serial numbers from the InventSerial...