0

This question is about Dynamics CRM but is valid for every system that allows merging entities.

Having data related to a contact in multiple external systems, how would you know which contact the data is related to?

  • Using ContactId works until that contact is merged - then the associated data could point to a non-existing contact (we have 100.000 duplicates)
  • Using EMailAddress1 works until it's changed

None of the solutions above seem good. Contacts are not assigned unique usernames.

I'm currently planning on using EMailAddress1 as the key gluing data for a contact between systems together, updating it in all systems when it's changed, but am curious if someone have had the same problem and solved it in a better way.

Jan Sommer
  • 170
  • 8

1 Answers1

1

When you have entities in system A and some related data in a second, decoupled system B, and you need to update the data in system B depending on changes to entities in system A, system A needs to provide certain mechanics for this, otherwise you are stuck. System A needs either

  1. an event mechanic where system B is actively informed about certain changes in A, or

  2. a history mechanism where B can query changes happened in A afterwards

(or both, of course). 1 will allow to implement a synchronous update, 2 will allow the implementation of an asynchronous update (for example, in certain time intervals like once a day). Both kind of approaches should utilize non-business keys for identifying and distingushing between entities (and since an email address is clearly a business information which can change during the lifetime of a contact, it is seldom suitable for this purpose). So another requirement on system A is to provide non-business keys which are never ever changed any more after an entity is created.

I do not know much about "Dynamics CRM", but I would be astonished if it does not provide the historic information about the lifetime of each contact, so when contact "Foo" with ContactId 123 was created by merging contacts "Bar1" and "Bar2" with ContactIds 42 and 43, an external system holding data associated with "Bar1" and "Bar2" can scan over all newly created contacts withing the last 24 hours, detect that "Foo" was created by a merge of "Bar1" and "Bar2" and update the associated data accordingly.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
  • I believe you have solid arguments. I'm integrating with 3 proprietary systems and 1 self designed db containing data related to the website. All three other systems require at least an e-mail, which has to be maintained. I've rewritten things to use contactid instead, because it somehow seems like a safer bet, but am really having a hard time seeing why I shouldn't just use the e-mail as key, as it's something I have to maintain anyway. Should probably have written that in the question, but nonetheless, your answer is greatly appreciated. – Jan Sommer Aug 08 '17 at 20:32
  • @JanSommer: I recommend to use the key used by the leading system A in either its event mechanics (1) or in its history mechanics (2). If system A (ab)uses email addresses for this, then you need to follow this design. However, in the real world, a contact person can change its email address over time, it can have different mailing addresses at the same time, or you might want to manage contact persons where you only know their phone number or postal address. – Doc Brown Aug 08 '17 at 21:18
  • You are absolutely right. Also, one might not always want to reveal the email, and when using it for lookups, I rely on the sort order of diplicates when querying by email, causing writes to possibly get spread across different contactids in the CRM. No doubt I'm going with the id. – Jan Sommer Aug 08 '17 at 21:35