You’re offline. This is a read only version of the page.
In a new D365 CRM implementation, what would be the preferred approach regarding transactional business data stored in the source (say, ERP) and on-premises system?
1. Create a (somewhat large) structure of custom entities in the CRM (which must be designed from scratch, since the one in the source system is chaotic and mostly irrelevant to the CRM) and actually transfer the data? And of course keep updating it continuously, on a scheduled basis,
2. Leave the data in the source system and retrieve it piece by piece and on-demand (i.e. when a user opens a customer dashboard) through, say, a set of web services created around the source system?
3. Put the data in an intermediate database (updated again on a scheduled basis) so that both the source system does not suffer from a new and heavy load from CRM query activity and the data is available to the CRM without taking up space in its own, expensive storage? And where should that DB better reside? On-premise or cloud?
4. Someting else?
The idea is that this data is considered "Reference data" from the CRM perspective (read-only data about customer transactions that is neither created nor updated in the CRM) with main use to allow the CRM users (say Customer service) answer customer questions directly from the CRM, without having to resort to the source system, and also data that could participate in campaigns or reporting and analysis.
*This post is locked for comments
I have the same question (0)
Share
Report
All responses (
Answers (
2
