WEBVTT

00:00:01.000 --> 00:00:04.690
This accompanies our article on CRM integration.

00:00:05.080 --> 00:00:09.530
Establish which records represent the same person or organisation and

00:00:09.560 --> 00:00:12.170
which information each system owns.

00:00:12.520 --> 00:00:15.770
Two fictional contacts share a general email address.

00:00:16.200 --> 00:00:19.210
Matching only that address could merge their records.

00:00:19.800 --> 00:00:22.610
Later, one contact changes address.

00:00:22.840 --> 00:00:26.250
Each source system keeps its own stable identifier.

00:00:26.520 --> 00:00:30.250
An explicit mapping table connects those references to the correct

00:00:30.280 --> 00:00:31.810
destination record.

00:00:32.120 --> 00:00:36.490
Identity does not change merely because a name or address changes.

00:00:36.840 --> 00:00:41.290
Define when a relationship exists, which combinations need review and

00:00:41.320 --> 00:00:43.690
who may confirm a new mapping.

00:00:43.720 --> 00:00:49.450
No match or several candidates must not automatically create another customer record.

00:00:49.480 --> 00:00:53.450
The CRM may own the account manager, while accounting owns billing

00:00:53.720 --> 00:00:54.730
information.

00:00:54.880 --> 00:00:57.735
Transfers update only agreed fields.

00:00:57.760 --> 00:01:01.450
A returned record must not start an endless loop of changes.

00:01:02.120 --> 00:01:06.090
For our shared email address, a person compares source references and

00:01:06.120 --> 00:01:07.650
relationship details.

00:01:07.880 --> 00:01:09.850
Only then is a mapping recorded.

00:01:10.360 --> 00:01:13.970
Similarity alone must not merge the contact histories.

00:01:14.280 --> 00:01:18.730
Test changed addresses, merged contacts, concurrent messages and

00:01:18.840 --> 00:01:19.450
archiving.

00:01:20.120 --> 00:01:25.130
Reconcile created, updated and rejected records against the source, so

00:01:25.160 --> 00:01:29.730
incomplete synchronisation does not remain unnoticed in daily use.

00:01:30.120 --> 00:01:32.650
Show which record was rejected and why.

00:01:33.080 --> 00:01:36.730
An administrator should be able to correct and reprocess that record

00:01:36.920 --> 00:01:42.970
without restarting the entire synchronisation or creating another customer relationship.

00:01:43.000 --> 00:01:47.690
CRM integration starts with identity and responsibility, rather than a

00:01:47.720 --> 00:01:48.970
name lookup.

00:01:49.000 --> 00:01:53.130
Our source article explains recognition, field agreements, error

00:01:53.160 --> 00:01:56.570
handling and controlled synchronisation in more detail.