The Data Management Framework (DMF) in F&O

The Data Management Framework (DMF) is the structural foundation of every bulk data move in Dynamics 365 Finance and Operations — initial migration, ongoing integrations, exports for reporting, and recurring file-based exchanges. Understanding its core entities (data entities, data projects, staging) is essential for anyone touching F&O integration work.

Data entities

A data entity is a denormalised view over one or more F&O tables, exposing a canonical structure suitable for external interchange. F&O ships with ~1,800 standard data entities — CustomerV3, VendorsV2, ReleasedProductCreationV2, SalesOrderHeaderV4 — covering most master data and most documents.

Each entity has:

• A public name (used in URLs and APIs).
• A target structure (how it maps to underlying tables).
• A staging table (intermediate landing area for imports/exports).
• A set of mapping rules (per source format).

Data projects

A data project is a configured import or export job. It contains:

• Source format — Excel, CSV, XML, ODBC, AX 2012, JSON.
• Entities — which data entities are in scope.
• Mapping — how source columns map to entity fields.
• Filters — what subset of records.
• Sequence — order of entity processing (matters for FK dependencies).

Projects are reusable: build once, run repeatedly. Each execution becomes a job.

Source → Staging → Target

The import flow is three-stage:

1. Source — the input file or feed.
2. Staging — the data entity's staging table; intermediate landing with field-level validation.
3. Target — the actual F&O tables; the entity's insert/update business logic runs.

Errors at each stage are isolated: source parse errors don't corrupt staging; staging validation errors don't corrupt target. Failed records can be reprocessed without re-running the full job.

Export is the reverse

Target tables → staging → source format file or feed.

Data templates

Pre-configured data project sets shipped by Microsoft for common scenarios:

• All customer data — customers, addresses, contacts, etc.
• All financial data — chart of accounts, dimensions, opening balances.
• All inventory data — items, BOMs, routes, prices.

Templates are a good starting point; production projects usually need customisation.

Recurring integrations

Beyond manual project execution, F&O supports recurring integrations:

• Recurring data jobs — pre-configured DMF projects scheduled or triggered.
• OData-based — REST endpoints for entity-based data access.
• Batch APIs — bulk data movement via REST.

For high-volume recurring integrations, batch APIs are preferred over OData per-record approach — OData throttles aggressively under load.

Entities vs OData

The same data entities serve:

• Batch DMF jobs — bulk imports/exports via files.
• OData APIs — record-by-record CRUD operations.
• Custom services — programmatic invocation.
• Power Platform connectors — Power Automate / Power Apps use OData behind the scenes.

A consistent entity layer means the same logical record type is accessible through multiple channels — Power Apps reads the customer entity; an integration writes via batch DMF; both see the same data structure.

Composite entities

Some data entities aggregate multiple related entities into a single payload (e.g. a sales order with header, lines, charges in one record). Useful when downstream systems prefer one structure per business document.

Entity import performance.

• Standard entities — moderate performance; suitable for ~1,000–10,000 records per minute.
• Set-based processing — high performance; entities marked as set-based skip per-record business logic.
• Bulk import — entire data sets in dedicated jobs; performance varies by entity complexity.

For large migrations (millions of records), entities are tuned individually — some standard entities don't scale and need partner extensions or direct SQL preparation.

Common pitfalls.

• Mapping errors. Source column names don't match staging fields; silent data drops or import errors. Test mappings with small samples.
• Dependency ordering. Loading sales orders before customers exist; FK violations. Always sequence entities respecting dependencies.
• Staging accumulation. Old staging records not cleaned; performance degrades. Schedule staging cleanup.
• No error handling. Failed records silently dropped; downstream confusion. Always extract error logs and reconcile.
• Tier 1 testing not representative. A migration that works in a Tier 1 dev environment may fail in Tier 2 SAT or production due to data volumes and parallel batch contention. Test with production-scale data on Tier 2.

Source format gotchas.

• CSV — character encoding (UTF-8 vs ANSI), delimiter handling, embedded commas.
• Excel — date formats, leading zeros stripped, formula evaluation.
• XML — schema mismatches.

Standardise on UTF-8 CSV or composite entity XML for predictability.

Operational rule

Production data integration on F&O is built on DMF entities. Custom direct-SQL approaches are not supported and break with platform updates. Stay on the standard pattern — use entities, build data projects, schedule recurring jobs, handle errors explicitly.

Where to go next

The entities DMF moves are described in data entities and DMF; the near-real-time alternative for Dataverse is dual-write; the orchestration layer many projects put around it is Azure Data Factory. For the project view, data migration strategy, and for exposing logic rather than data, custom services and OData in F&O.