Synchronize CRM data with external systems

Article
07/22/2016

Applies To: Dynamics CRM 2015

Sometimes you’ll need to synchronize and integrate Microsoft Dynamics CRM data with data that is stored in other systems. The common data integration patterns include taking data from an external system and pushing it into CRM, taking data from CRM and synchronizing it to some external data store, or updating CRM with external data. You can now use several new capabilities introduced with Microsoft Dynamics CRM Online 2015 Update 1 to make writing code to achieve these scenarios more easily.

Note

For Microsoft Dynamics CRM Online organizations, this feature is available only if your organization has updated to Dynamics CRM Online 2015 Update 1. This feature is not available for Dynamics CRM (on-premises).

These new features can be used separately as needed in any situation, but together they address common issues related to synchronizing and integrating data with external data. The following table introduces these new features.

Feature	Description
Removing specialized messages	Microsoft Dynamics CRM has a number of specialized messages for specific operations that update records. These messages are deprecated in this release and you should now simply use Update to perform the same operations. The deprecated messages are: Assign SetParentSystemUser SetParentTeam SetParentBusinessUnit SetBusinessEquipment SetBusinessUnit SetState Simply updating the record is much simpler than using these messages and should streamline your development for data integration and synchronization scenarios. More information: Perform specialized operations using Update
Alternate Keys	In enterprise deployments of Microsoft Dynamics CRM, it’s common for data from external enterprise systems to be loaded into Microsoft Dynamics CRM so that it can be presented to users. These external systems often can’t be extended to store the CRM record identifiers, known as GUIDs, required for system synchronization. A common solution is to add a custom attribute to an entity in Microsoft Dynamics CRM that can be used to store the identifier of the related record in the external system. When you build data load processes that update records in Microsoft Dynamics CRM and assign references to related records in CRM, you first have to make an extra CRM web service call to retrieve the target CRM record based on this external identifier. This lookup can be slow if an appropriate index is not in place for the custom attribute, and in CRM Online scenarios, each of these lookups requires a costly round-trip across the Internet. These extra round trips can increase by an order of magnitude the time it takes to update each CRM record and can reduce overall throughput drastically. Now, web service operations can target a CRM record using one or more alternate keys instead of a GUID. In addition, entity references to related records can be specified using one or more alternate keys. Because alternate keys are indexed, lookup operations show increased performance as compared to adding a custom attribute as an identifier. If something goes wrong, the system will throw an error and roll back all the changes. More information: Define alternate keys for an entity
Change tracking	When organizations need to maintain CRM data in external storage there is now a way to keep that data synchronized in a performant way by detecting what data has changed since the data was initially extracted or last synchronized. The RetrieveEntityChangesRequest message is used to retrieve the changes for an entity. See Use change tracking to synchronize data with external systems for more information.
Upsert	When loading data into Microsoft Dynamics CRM from an external system, you may not know if a record already exists in CRM and should be updated, or whether you must create a new record. Use the new UpsertRequest message to update the record if it exists, or create a new record if it doesn’t exist, in one API call. More information: Use Upsert to insert or update a record

The following table compares the complexity of synchronizing with and without these new features.

Before	Description
	For each record: Query CRM to see if the account exists. If it exists, get its account ID (for example, ABC123) Query the contacts to verify that the contact exists. If it exists, get the email ID of the contact (for example, contact@company.com). Query to get or set the region ID (for example, NW). Query to get the user ID to set the owner (for example, user@mycompany.com) Update the account. Set the state of the account by calling the SetState API. Assign the owner by calling the Assign API.

For each record:

Query CRM to see if the account exists. If it exists, get its account ID (for example, ABC123)
Query the contacts to verify that the contact exists. If it exists, get the email ID of the contact (for example, contact@company.com).
Query to get or set the region ID (for example, NW).
Query to get the user ID to set the owner (for example, user@mycompany.com)
Update the account.
Set the state of the account by calling the SetState API.
Assign the owner by calling the Assign API.

Now, with the new features, it just takes one call to the server to perform the same operations as previously shown.

After	Description
	Just one call to verify that there is an account with the unique ID ABC123, set the primary contact to contact@company.com, set the region to NW, set the owner to user@mycompany.com and the status to active.