Page tree
Skip to end of metadata
Go to start of metadata

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

Field Identifying

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 PeeringGood 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.  

Record Peering

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.

Matching

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.

Conflict Resolution

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:

A p (3 pm) => p (4 pm)
B q (2 pm) => p (4 pm)
<ac:structured-macro ac:name="companyname" ac:schema-version="1" /> r (1 pm) => p (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:

XS A p (3 pm) => q (4 pm)
XS B q (2 pm) => q (4 pm)
<ac:structured-macro ac:name="companyname" ac:schema-version="1" /> r (1 pm) => q (4 pm)

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.

  • No labels