Dynamics 365: Learn in doing

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 first time.  Virtual Entities first appeared in Dynamics 365 CRM (v9.0, 2017) ...

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 exported. Faster, lighter, and easier to schedule. Lesser costs. Types of Change Tr...

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 Open the Form Navigate to the form where the field lives. Say, CustTableListPage. Right-C...

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 , CustSettlement , and CustTrans , the output looked like below. Just for your info, CustPara...

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 table (and related bits) via one entity. Create a project in Visual Stu...