Le CRM et le portail doivent savoir de quelle fiche ils parlent
Eskelias porte sur les données de référence, les correspondances d'identifiants et les interfaces métier connectées au CRM. Les repères de design conservés concernent l'interface du portail ; ils complètent ce sujet sans définir le fonctionnement de la synchronisation.
Un conflit illustratif
Un contact change de numéro dans le portail pendant qu'une personne corrige sa fiche dans le CRM. Cet exemple de synchronisation met au jour une question fonctionnelle : quelle valeur retenir, pour quel champ et dans quel contexte ? La date la plus récente ne suffit pas toujours à décider. Le domaine de responsabilité de chaque application doit être compréhensible par les utilisateurs.
Le tableau de correspondances métier
Le dossier distingue l'identifiant stable, les champs échangés, leur origine et les conflits possibles. Une adresse électronique peut évoluer ou être partagée ; elle ne décrit pas à elle seule l'identité d'un dossier. Les événements rejetés et les corrections manuelles restent visibles pour que l'équipe puisse comprendre l'état des données. Le carnet traite cette cohérence fonctionnelle, indépendamment de l'outil d'orchestration utilisé.
Les questions utiles au lecteur
Que se passe-t-il si le même événement est reçu à nouveau ? Comment reconnaît-on un doublon présumé ? Quel écran montre un conflit à résoudre ? Les réponses attendues exposent le comportement et ses limites, sans promettre une absence totale d'erreurs. Les éléments de typographie, de composants et de styles du portail se lisent ensuite comme des questions de présentation de ces états métier.
- Identité métier
- Référence stable du contact, distincte de son adresse de courriel modifiable.
- Champ en conflit
- Numéro du portail et numéro du CRM, avec leur origine.
- État visible
- Conflit à examiner, correction retenue et trace de la décision métier.
Pour approfondir : Identifiants, unicité et contraintes de données, PostgreSQL.