CRM e sistemi esterni: come associare i dati ai contatti?

Question

CRM e sistemi esterni: come associare i dati ai contatti?

Naviga le tue risposte

#1 da (1 voti)

0

Questa domanda riguarda Dynamics CRM, ma è valida per tutti i sistemi che consentono l'unione di entità.

Avere dati relativi a un contatto in più sistemi esterni, in che modo sapresti a che contatto sono associati i dati?

L'utilizzo di ContactId funziona finché il contatto non viene unito, quindi i dati associati potrebbero puntare a un contatto non esistente (abbiamo 100.000 duplicati)
L'uso di EMailAddress1 funziona finché non viene modificato

Nessuna delle soluzioni di cui sopra sembra buona. Ai contatti non sono assegnati nomi utente univoci.

Attualmente sto pianificando di utilizzare EMailAddress1 come dati chiave per l'incollaggio di un contatto tra i sistemi insieme, aggiornandolo in tutti i sistemi quando è cambiato, ma sono curioso di sapere se qualcuno ha avuto lo stesso problema e risolto in un modo migliore.

integration surrogate-keys unique-data

posta Jan Sommer 07.08.2017 - 19:58

fonte

1 risposta

Leggi altre domande sui tag integration surrogate-keys unique-data

Gestione della scadenza della sessione utente nell'applicazione Web basata su MVC Come affrontare la progettazione della strategia in OOP.

score 1 · Accepted Answer

Quando hai entità nel sistema A e alcuni dati correlati in un secondo sistema B disaccoppiato, e devi aggiornare i dati nel sistema B a seconda delle modifiche alle entità nel sistema A, il sistema A deve fornire determinati meccanismi per questo , altrimenti sei bloccato. Il sistema A ha bisogno di

una meccanica degli eventi in cui il sistema B viene informato attivamente su alcune modifiche in A o
un meccanismo di cronologia in cui B può interrogare le modifiche avvenute successivamente in A

(o entrambi, ovviamente). 1 consentirà di implementare un aggiornamento sincrono, 2 consentirà l'implementazione di un aggiornamento asincrono (ad esempio, in determinati intervalli di tempo come una volta al giorno). Entrambi i tipi di approccio dovrebbero utilizzare chiavi non commerciali per identificare e distinguere tra entità (e poiché un indirizzo email è chiaramente un'informazione aziendale che può cambiare durante la vita di un contatto, raramente è adatto a questo scopo). Quindi un altro requisito sul sistema A è quello di fornire chiavi non commerciali che non siano mai più cambiate dopo che un'entità è stata creata.

Non ne so molto di "Dynamics CRM", ma sarei stupito se non fornisse le informazioni storiche sulla durata di ogni contatto, quindi quando il contatto "Foo" con ContactId 123 è stato creato unendo i contatti "Bar1 "e" Bar2 "con ContactIds 42 e 43, un sistema esterno contenente dati associati a" Bar1 "e" Bar2 "può eseguire la scansione su tutti i contatti appena creati nelle ultime 24 ore, rilevare che" Foo "è stato creato da un'unione di" Bar1 "e" Bar2 "e aggiorna i dati associati di conseguenza.