For enterprise integration teams, the interesting part is not simply another collection of entities. It is the opportunity to match an integration more closely to the customer information a business process actually needs—rather than reaching for the biggest available toolbox every time someone needs a screwdriver.
What the planned entities cover
The roadmap describes five areas of customer data:
- Core customer information
- Extended customer attributes
- Postal addresses
- Electronic contact information
- Customer associations
Its listed scope includes Dynamics 365 Finance and Finance and Operations cross-app functionality, on the web platform, for Worldwide Standard Multi-Tenant cloud environments. However, the October preview target should not be read as confirmation that the feature is enabled in any particular tenant.
These groupings describe the intended coverage, not verified final entity names or schemas. The available evidence does not establish a minimum application version, activation procedure, migration requirement, or replacement policy for existing customer entities.
Why narrower entities matter
Microsoft’s data-entity documentation explains that an entity presents a business concept while abstracting its underlying database tables. Customer information, for example, can span customer, party, postal-address, and electronic-address tables; an entity brings related information together into an integration-friendly view. The same framework supports synchronous OData services and asynchronous integration through the Data management pipeline.
That convenience has a tradeoff. Microsoft’s Customers V3 documentation says the entity’s broad support for customer creation and updates reduces performance. It explicitly advises against using Customers V3 for high-volume or high-frequency scenarios where performance is a priority, and documents its performance pattern as single thread only.
The planned split therefore addresses a recognizable integration-design problem: broad coverage is useful, but a workflow may need only one portion of it.
As an architectural inference—not a measured result for the upcoming feature—focused entities could help teams separate address maintenance from core customer updates and map each process to a narrower interface. That does not establish that the new entities will be faster, support parallel processing, or reduce end-to-end execution time. Those conclusions require implementation documentation and testing.
There is already a practical choice for customer imports
Organizations do not need to wait until July 2027 to review their existing entity selection.
Microsoft Learn currently recommends Customer definitions for most customer-import scenarios. Combined with Customer details V2, it covers most of the functionality provided by Customers V3. Microsoft says either focused entity—or both used sequentially—will usually outperform Customers V3. The important exception is field coverage: Customers V3 supports approximately 80 additional fields that the other two do not.
That provides a useful decision point today:
- Start by identifying the fields the import actually requires.
- Evaluate Customer definitions and Customer details V2 against those requirements.
- Retain Customers V3 where its additional field coverage is necessary, while accounting for its documented performance limitations.
This existing guidance supports the rationale for more focused entities. It does not prove that the roadmap feature is simply a renaming of those existing options.
What integration teams should prepare
Treat this roadmap item as a planning signal, not a production migration instruction. A sensible preparation exercise is to inventory customer integrations by purpose: customer creation, attribute updates, address maintenance, electronic contacts, and associations. Then identify which workflows use Data management and which use OData.
When implementation details become available, evaluate both integration paths separately. Microsoft cautions that some standard entities are optimized for OData integration rather than data migration; support for both mechanisms does not make their performance characteristics interchangeable.
For import testing, Microsoft recommends increasing dataset sizes progressively—for example, 1,000, 10,000, and 100,000 records when preparing for a million-record migration. It also warns against extrapolating Tier-1 results to Tier-2 or higher sandbox environments and recommends a mock cutover before go-live.
One particularly useful caution: narrower does not automatically mean set-based. Microsoft documents that Customer definitions does not support set-based processing. The upcoming entities’ processing and concurrency capabilities therefore need verification rather than assumption.
The takeaway
The proposed optimized customer entities offer a more granular integration model for Dynamics 365 Finance, but the operational details remain the deciding factor. Teams should look for confirmed schemas, supported operations, version requirements, compatibility guidance, and workload-specific results before changing established integrations.
For now, the strongest actionable finding is already in Microsoft’s documentation: choose customer entities according to required fields and measured performance—not simply because the broadest entity looks like the safest default.