Data Entities in Dynamics 365 Finance & Operations
Question 9 — The abstraction for data migration and integration: entity types, OData vs. DMF, and best practices.
Interview Question
Model Answer (Short)
A Data Entity is a de-normalised abstraction that presents data from one or more underlying tables as a single flat structure. It provides a consistent way to import, export and integrate data — replacing the older AX concepts of AIF documents and custom services. Entities are consumed two main ways: through OData for real-time, record-by-record integration, and through the Data Management Framework (DMF) for high-volume, asynchronous import/export. A key rule is that an entity must behave identically regardless of whether it is called via OData (single record) or DMF (many records).
Detailed Explanation
Entity categories
| Category | Purpose | Example |
|---|---|---|
| Parameter | Configuration / parameter data functional in a given company | Module parameter setup |
| Reference | Small supporting data that qualifies transactions | Units, dimensions |
| Master | Core business master data | Customers, Vendors, Items |
| Document | Transactional worksheet-style data | Sales orders, journals |
| Transaction | Posted / operational transaction data | Posted invoices |
OData vs. DMF
- OData — a RESTful protocol for real-time, synchronous, record-by-record CRUD; best for integrations and small volumes. The entity must have its public / OData properties enabled.
- DMF (Data Management Framework) — used for high-volume asynchronous import/export via data projects; uses a staging table then moves data to the target.
Best Practices
- All non-temporary tables should be mappable to a data entity; create an entity when you create a new table (only where data migration / relationships require it).
- When you add a field to a table, add the corresponding field to the existing (standard or custom) entity.
- Provide entities for all master, setup and parameter tables.
- Avoid using a data entity as the data source of another data entity — use a table as the source instead.
- The entity must behave identically via OData (single insert) and DMF (multiple insert) — method behaviour must match across all usage scenarios.
- Only methods specific to data integration belong on the entity; all other logic should live at table level so it always applies.
Prerequisites (Rule 5)
- Visual Studio with the Dynamics 365 developer tools.
- A custom model / package for your objects.
- The underlying table(s) and their relations / keys defined.
- Entity properties set: Public Entity Name, Public Collection Name, Is Public = Yes for OData.
Code Example — Overriding entity behaviour
Adding validation that runs identically for OData and DMF by overriding the entity's validateWrite:
public boolean validateWrite()
{
boolean ret = super();
// This validation applies to BOTH OData and DMF callers
if (this.CreditLimit < 0)
{
ret = checkFailed("Credit limit cannot be negative.");
}
return ret;
}Defaulting a value during import
public void initValue()
{
super();
// Provide a sensible default when the source file omits the field
if (!this.CustomerGroupId)
{
this.CustomerGroupId = 'DEFAULT';
}
}Consuming an entity via OData (external client, C#)
// Conceptual OData endpoint for a public entity named "Customers":
// GET https:///data/Customers
// POST https:///data/Customers (single record insert)
//
// The same entity is used by DMF for bulk import/export via a data project,
// and both paths must yield identical results. Points the interviewer wants to hear
- A data entity de-normalises one or more tables into a single consumable structure.
- Five categories: Parameter, Reference, Master, Document, Transaction.
- OData = real-time record-by-record; DMF = high-volume async via staging.
- An entity must behave identically whether called by OData or DMF.
- Don't use an entity as a data source for another entity — use a table.
Likely Follow-up Questions
- What is a staging table in DMF, and why is it used?
- Why must an entity behave the same for OData and DMF?
- When would you choose OData over DMF for an integration?
- What are computed and virtual fields on a data entity?
Key Takeaway
Data entities are the single, consistent gateway for importing, exporting and integrating data in D365 F&O. Know the five categories, the difference between OData and DMF, and the cardinal rule that an entity must behave identically no matter how it is called.