Sync Overview

While you are working in the app it will poll the server every few minutes to attempt a sync. The default polling interval is five minutes, but this can be adjusted in the app’s settings (see Sync Interval in Settings). Depending on the number of changes made since your previous sync this process may take awhile. It is advised that you sync often to reduce the likelihood of errors or conflicts.

NOTE When syncing records for offline activity, the timestamp will reflect the time of the sync and not the time of the actions taken while offline.

If a sync fails for an expected reason (i.e. device is offline), the app will quit the sync attempt and attempt the sync again on the next interval. If the sync fails due to an error, it will log the failure and attempt on the next interval. If the app fails to sync three times in a row, the user is notified and it is requested that they contact support.

WARNING If you are unable to sync, contact support via the app before proceeding. Any unsynced changes you have made are stored locally on your device and can be recovered by other methods if necessary. DO NOT attempt to delete the project or reset local data without explicit instructions to do so from support first.
The sync system operates on a “last sync wins” model for resolving conflicts. For example, if User A and User B are working in the same checklist and User A syncs their data before User B, the data uploaded by User B will be the data that ultimately shows up on the web and in the app.
Practically, this approach isn’t often necessary because of the granularity of how the data is stored. For example, if User A answers checklist lines 1-10 and User B answers lines 11-20, then no conflict occurs since lines are stored individually. Even certain aspects of records are stored separately. For example, if User A changes the status of the checklist and User B reassigns the checklist, no conflict occurs. Generally, only when two users change the same aspect of the record will the “last sync wins” model be relevant.
Unintentional overwrites can still happen, however. If User B’s checklist data overwrites User A’s checklist data in a way that is undesired, User A’s data can usually be recovered since CxAlloy keeps an ongoing record of all changes made. If you encounter this situation, contact and it's likely your data can be reverted to a previous version.

Still need help? Contact Us Contact Us