Sync Filter

Synchronization filters are usually used to limit the amount of records pulled down to a mobile device during synchronization.

While they work perfectly during the full synchronization, there are some scenarios where they might not work as expected during incremental sync.

Imagine a sync filter on the Order entity, which defines that only the Orders which belong to current user should be downloaded.

Full Sync

During the full sync (empty database), everything works as expected.

The server query is basically equal to the sync filter definition so only the Orders that belong to current user are queried and downloaded.

Incremental Sync

The situation is very different during an incremental synchronization (every subsequent sync after full). Only the changes – modified or newly created records since last synchronization – are queried on the server. Notice that the sync filter doesn’t play any role in the query; regardless of the sync filter definition, all changes are downloaded.

Only afterwards, once all changed and newly created records are present locally, the records that DO NOT satisfy the sync filter are deleted. So it is true that after synchronization only the records which comply with sync filters are present in the local database (only the Orders that belong to the current user).

The reason for this behavior is performance optimization. Resco has implemented sync filters this way because querying all new or modified records that comply with the sync filter would need to be executed as two independent queries on the server (until Dynamics CRM 2015), which would significantly increase the synchronization time – and we’re not even taking into consideration the combination of the two results, to get the records present on both lists.

But when (in our hypothetical organization) there are only a couple of Orders created each day, it doesn’t make much of a difference. But imagine a large organization with hundreds (if not thousands) of Orders being created or modified each day – and only a handful belonging to each respective user. This would result in thousands of Orders being downloaded, when in fact only e.g. ten are needed – and the rest is deleted (locally).