Synchronization Record Matching
Record synchronization between an Agiloft table and an external system will match and replace fields based on the options that were specified in the Sync Configuration Wizard.
If the Use strict match for identification check box in the Field Mapping wizard is ticked, at least one of the fields marked as Identifying must have a value unique for each record in the table or structure concerned.
These fields determine the 1-1 mapping of the Agiloft table records to the external structure records - see Record Peering. Good examples of identifying fields which are likely to create a logical match to sync records in both systems are Email and Full Name when synchronizing Contacts, and Summary when synchronizing Cases.
Note: The Identifying field is not necessarily an ID field. Moreover, if there is an auto-incrementing/GUID ID field as in Agiloft, it is generally a bad idea to have this field marked as identifying, since there is a large probability that this value will not have an ID match, or even worse, an incorrect match in the external system.
For every record in an Agiloft table or external system structure subject to a new sync, and for every such record created since the last sync, a corresponding record in the other system is determined by matching the identifying fields from the two systems. If there's no such record, one is created. The two records are held by sync in an Agiloft ID - external system ID pair, thus peering the Agiloft record with the external record. Logically, sync treats the pair as a single data record, having Agiloft and external views.
If a new record is created manually in both systems, the identification process will prevent sync from duplicating them.
There are two algorithms for matching:
- Best match: If there are three identifying fields, sync will first try matching all three. If there is no match, it will try matching by any two. If there is still no match, it will match by any one of the fields.
- Exact match: If there are three identifying fields, sync will first try matching all three. If there is no match it will create a new record.
The algorithm is selected in the Field Mapping wizard by selecting the Use strict match for identification check box. The choice of exact matching may prevent matching if any identifying field has non-unique values.
After the peering is established, it will not be cleared until either one of these conditions is met:
- The records are deleted in both systems
- The peering information is reset by using the Reset Records Peering button on the General tab of the Sync Configuration wizard.
If both records of a pair have been changed since the last sync to different values, one of them should be updated. The conflict can be resolved either:
- By choosing the value in one of the systems - Agiloft/XS - to preserve.
- Or by preserving the most recent value, according to the timestamps
This choice is made in the Running tab of the Sync Configuration wizard.
Records are never merged; all fields in a record are always updated from a particular source record, but you can choose which fields to synchronize, so it is not necessary for the whole record to be overwritten.
Dual Synchronization Problem
If two or more external systems are kept in sync with a given Agiloft table, which means using two or more different sync configurations for the same record set, and if conflicts are resolved by preserving the most recent value, the results are affected by the order in which the synchronizations are run.
Suppose an updatable field between Agiloft and two external systems A and B has the values and timestamps shown, and we synchronize A with Agiloft, and then B with Agiloft at 4 pm:
The first update changes Agiloft because 3 pm > 1 pm, and the second changes the external system B because 4 pm > 2 pm.
But if we synchronize B first, and then A, the effect is:
The first update changes Agiloft because 2 pm > 1 pm, and the second changes external system A because 4 pm > 3 pm.
This is because there is only one timestamp on each value in a pair, whether it results from sync or user updating.