You are here: All Help Topics > Engagement Management > SmartSync > Synchronization Conflicts Overview
-- More Info --

Synchronization Conflicts Overview

The goal of using SmartSync is to blend the work done by multiple staff together into a seamless package. To the staff using SmartSync, there should be little difference between working in a synchronized copy and working in a standard non-sync client file. However, there are some instances where changes made by two staff members conflict with each other and a conflict resolution is necessary. Most of these conflicts are automatically resolved by Working Papers, though the resolution can be overridden in some cases.

Typically, real-time changes such as the creation of an adjustment are resolved on a first come, first served basis. If two staff are offline and both create an adjustment #7, the first to go online and sync to the parent keeps their adjustment as it was built. When the second synchronizes later in the day, there is a conflict between the two different #7 adjustments and at this point the date and time of creation of the adjustments determine which remains as #7 (the first synchronized) and which is renumbered to #8 (the second synchronized).

Although the SmartSync engine can resolve most conflicts, certain types require user resolutions. Conflicts related to external documents can arise where two or more users update the same external document. SmartSync cannot track changes within an external document and so only one version of the document can be selected to resolve the conflict.

For more information on these types of conflicts, see File Change Conflicts in External and CaseView Documents.

Sync Logs

In order for SmartSync to transfer information, access to the parent file folder is necessary. While working in the office, this connection is typically static and synchronization happens in real-time. When changes are being transmitted between the parent file and the synchronized copy, only their respective sync logs are communicating. Sync logs reside in the hidden sync folder located within each client file folder. Sync logs only exchange changes made to the file which reduces high bandwidth network traffic and enables SmartSync to operate in real-time.

The Working Papers database generates an operation log, referred to as the sync log, and various auxiliary files for each synchronized copy. The log resides in the local client file directory and records changes made to the synchronized copy, such as deleting an account, modifying an adjustment amount or creating a new CaseView document. Each change is assigned a sequential number to record and track synchronized changes. It is important to note only the changes made to each file are stored in this log.

Operations within each copy of the client file are recorded with a timestamp that is used to synchronize the operations throughout the hierarchy. Therefore, all of the clocks on the computers in the sync hierarchy should be synchronized. Network Time Protocol can be useful in ensuring that the hierarchy is synchronized to a single time reference and some networks will also utilize their Primary Domain Controller.

When a sync copy synchronizes with its parent, its log receives any changes it has yet to receive from the other sync copies. Only new changes are appended to the copy’s log based on the last time synchronization occurred. The sync log of the top-level parent thus contains all changes as it is communicating with the sync logs of all its copies. The top-level parent still needs to be launched in order for it to receive all changes.

Note: Primarily, only changes are synchronized or transmitted across the network, however, when you first create the synchronized copy the entire Working Papers file is passed from the shared location to your local folder. For firms with many users, this can cause a strain on the network if many users are creating synchronized copies at the same time. In this case, we recommend that a scheduling policy be implemented when creating synchronized copies to avoid this scenario.