We’re designing an API integration for asset management in D365 F&O 10.0.38 and debating whether to use custom fields or map our data to standard D365 fields. Our asset tracking system has fields like “MaintenanceResponsible”, “CostCenter”, and “DepreciationPool” that don’t have exact equivalents in the standard AssetManagement entity.
The custom field approach would give us exact field name matches and preserve our existing business logic. However, I’m concerned about upgrade complexity and API stability. Using standard fields would require some data transformation in our integration layer but might be more maintainable long-term. What experiences have others had with custom versus standard fields in asset management APIs? How do upgrades affect custom field integrations, and is the flexibility worth the potential technical debt?
I’ve seen both approaches succeed and fail depending on implementation quality. The key question is: how much of your business logic belongs in D365 versus your external systems? If D365 is your system of record for assets and other modules depend on that data, use standard fields and adapt your processes. If D365 is just one component in a larger asset management ecosystem, custom fields might make sense to maintain data fidelity across systems.
From a functional perspective, standard fields are always preferable because they’re supported by Microsoft’s upgrade path and have built-in validation logic. Custom fields might match your terminology exactly, but you’ll spend more time maintaining them during version upgrades. We mapped our legacy asset fields to standard D365 fields using a translation table in our middleware, and it’s been much smoother than our previous implementation with heavy customization.
Consider the total cost of ownership. Custom fields require ongoing maintenance - documentation, training, testing with each upgrade, and potential rework if Microsoft introduces similar functionality in future releases. Standard fields benefit from Microsoft’s testing, documentation, and community knowledge. For asset management specifically, the standard AssetManagement entity covers most common scenarios. If you need additional fields, evaluate whether they’re truly business-critical or if they can be handled in your external system.