Data entities, OData, business events, dual-write and the analytics estate — what each pattern is for, how to choose between batch and real time, and why direct database access is not on the list.
No ERP stands alone. There is a warehouse system, a bank, a payroll provider, an e-commerce front end, a customer relationship system, a reporting stack, and a handful of things nobody documented that quietly keep the business running.
A data entity is a published, business-shaped view over the underlying tables. "Customer" is an entity; behind it sit party records, address book entries, customer accounts and payment defaults, and the entity presents them as one coherent thing.
Most integration mistakes are pattern mistakes rather than technical ones. Match the pattern to the need.
Reporting deserves its own section because putting it in the wrong place is a decision that only hurts later.
Integration design fails on governance far more often than on technology. Answer these before anyone writes an interface:
Integrations authenticate as identities with security roles, and those roles should be scoped to exactly what the interface needs.
Integration in D365 is a set of published contracts, and choosing the right one is a design decision rather than a technical preference.