Someone asked me to explain exactly how the Synchronisation process worked from outlook to CRM.
I wasn’t positive which records would be the last to update, I had a feeling it was the update with the latest time stamp but I wasn’t 100 percent sure.
The person didn’t like this answer at all saying you can’t just overwrite someone else’s change but this is similar to what would happen if you overwrote the change with CRM connected to the live database.
When ever I used to get calls about an Outlook Synchronisation error my heart would sink. Usually the problem is someone is trying to update a record which has been deleted.
It was interesting because I remember studying the outlook sync process for the CRM 4 installation exam (or I think I remember because nothing like that was in the CRM 2011 exam) or I remember reading it because I was quite impressed by the process of playback and how the Outlook offline database stores all the changes in order and then plays through them, basically replicating the offline
This blog explains some good points and it’s written by the CRM in the Field guys who know their stuff
the blog above will point you to this document
I’m not sure why there isn’t a CRM 2011 version but I couldn’t find hardly any information on the synchronisation process and which record wins.
The key sentence is this
Out of the box, Microsoft Dynamics CRM 4.0 does not include built in conflict resolution mechanisms for offline queue playback, and as a result, the last one to playback always wins.
it comes from this paragraph.
Playback of the Offline Queue Table
When the offline client reconnects to the network and goes online, SOAP packets in the Offline Queue table are played back to the server. The application uses start and stop markers to transact certain operations in the application that perform multiple operations in the platform (for example, reopening a case, which requires copying the case line items to the new case). In case of a failure in playing back any operation between a start-stop marker, all the remaining operations are aborted and the sync queue moves to the next stop marker.
Attachments are also captured as part of the SOAP packet that is stored in the offline queue. As a result, each attachment occupies twice the space in the database when created offline. As part of the process of SOAP packet playback, prior to playback the SyncQueue component modifies the SOAP XML to inject:
- The Authentication token, which is required of all SDK requests. For CRM Online and SPLA/IFD, the Authentication ticket is time sensitive, expiring after a fixed period, so the Authentication ticket is generated and injected into the SOAP packet during playback.
- A duplicate detection optional parameter, which allows the server’s Duplicate detection infrastructure to take appropriate action based on user settings and upon the user’s selection on the client side (if the user chooses to create the duplicate anyways).
- A CallerOrigin SOAP header, which alerts the server that a particular SDK request is coming from an offline queue playback. The header also contains a timestamp of when the SOAP packet was added to the offline queue, which allows plug-ins on the server side to use this information to implement custom conflict resolution mechanisms. Out of the box, Microsoft Dynamics CRM 4.0 does not include built in conflict resolution mechanisms for offline queue playback, and as a result, the last one to playback always wins.