Consider migrating the data from Microsoft dynamics CRM online to Microsoft dynamics GP. Our goal is after the data migration is completed successfully, we want the result of the data migration (successful/failure) to go back to the source system. Steps: Scenario: 1st block: We query the source account entity 2nd block: We try to update/insert the target customer entity 3rd block: We update the source account entity, based on the result of the 2nd block (success/ failure) 4th block: We also update the target customer block based on the result of the 2nd block (success/ failure) In the target block (Update/Insert Customer), uncheck the error handling checkbox [Note: Error handling checkbox, is used to check if there are any fatal errors in the executions] After the data is inserted, we can have an update block for the source entity(Update account) that will write back the result (whether the data is successfully migrated or not) to the source system. In this example, GP2015_CustomerUpdateInsert is for inserting the data in the target system. As we can see in field’s column, we can capture information about the previous block by the highlighted fields, which can then be stored in the source system for tracking if the data went through.

Change tracking is a new feature available in CRM update 1 that can help in keeping the data synchronized in source and target systems by detecting the data changes since the data was initially created or last synchronized. Change tracking is used for incremental load STEPS: Before we begin to implement change tracking, we need to enable it on the entity for which we need to track changes Customizations → Entity → Enable change tracking We need to maintain a table in Sql so that the output tokens can be saved for future purpose which will help to maintain a version for the records in the form of tokens [Note: The tokens can be maintained in a file also] Let’s start by creating the SSIS package using SSIS integration toolkit for Dynamics CRM-Kingswaysoft Flow of package will be: Drag and drop the Execute Sql task which will be used to fetch the tokens from Sql [Note: In case of initial migration, the token will be NULL] Since initially the table will be empty we need to handle the NULL scenario Create a variable for maintaining the count of rows for the table(we need to store the result set in this variable created) If the count=0 (1st time migration), it goes to a sequence container passing the input token as NULL If the count !=0 , it goes to a sequence container passing the input token as the last inserted token in the table Let’s consider we migrating the data for the 1st time The sequence container will contain a data flow task (having the source and target CRM components) and Execute Sql task (storing the new token to Sql) Data Flow task: Drag the CRM source component Set up the connection, select source type as ‘Entity changes’, mention the entity and define the input and output token variables [Note: In this scenario the Input token will be NULL as it is 1st time migration] Now we drag two CRM destination components CRM Primary Input (Tracking the Updates and Inserts) CRM Secondary Input (Tracking the Deletes) For CRM Primary Input destination component, set up the connection, action as ‘UPSERT’, mention the destination entity and upsert matching criteria For CRM Secondary Input destination component, set up the connection, action as ‘DELETE’ and mention the destination entity Execute Sql task: We need to store the output tokens in Sql, using Execute Sql task In parameter mapping, we mention the input and output tokens variables that we get from the Data flow task Let’s consider the scenario where we already have the data set up The sequence container will contain a Execute Sql task (for fetching the last output token from Sql), data flow task (having the source and target CRM components) and Execute Sql task (storing the new token to Sql) Execute Sql task: We need to fetch the output token from Sql The result set can be stored in the Input token variable which we pass to the CRM source component The steps for data flow task and the execute Sql task are the same as mentioned earlier The final package will look like this: The package can be scheduled on a daily basis thus keeping the data in sync in the source and target systems.  

Note:  This article assumes experience on SSIS Integration Toolkit for Dynamics CRM and understanding of CRM Online Images, Notes and Attachment migration in CRM Online is always a challenging task. One easy way of dealing with them is to use SSIS Integration Toolkit for Dynamics CRM Images Steps: Drag and drop Dynamics CRM Source and Dynamics CRM Destination component. Set up the Source CRM by adding the connection manager, mentioning the source type(Entity /Fetch xml/Entity changes) Set up the Target CRM by setting the connection, choosing the appropriate action (Create/Update/Upsert/Delete etc.), specifying the destination entity Map the Input column and destination CRM field For migrating images, we need to directly map entityimage field of source to entityimage filed of target   Notes/Attachments Steps: For notes and attachments, select the annotation entity as the source as target by following the steps mentioned above The fields to be mapped are subject, notetext, documentbody, filename, mimetype, objectid for mentioning to which entity is the note/attachment related to We use Text lookup function for lookups We can lookup on name/ GUID /custom field as per the need. In the example mentioned above we lookup the accountid which is the primary field for account entity  

Key Technologies: CRM Online, Scribe Insight Note: This article assumes understanding of CRM Online entities and relationships. Knowledge of Scribe insight tool for data integration. For more information on Scribe Insight refer https://www.cloudfronts.com/scribe-integrationsmigrations/ Connections can be used to define the relation between the two entities. You can have an account related to any contacts. With the help of connection you can define that one of the contact is actually the employee in the company and another an employer. 1. Before connections, you should have connection roles and association between the roles defined. 2. Connection Roles A role should have a role category. Consider, a role ‘Client’ which is part of ‘Business’ category, ‘Sibling’ which is under ‘Family’ category. 3. Connection Role Association After defining a role, we should associate different roles. This entity stores guid of the main role and the associated role. Role ‘Client’ can have other roles associated with it. See below example. 4. Select record type ‘All’ to avoid restriction on any entity. 5. Connections Map the following fields for connections between records of different entities. • Record1id • Record2id • Record1objectTypecode (ex: account) • Record2objectTypecode (ex: contact) • Record1roleid (ex: Client) • Record2roleid (ex: Employee) • Description • Status • Ownerid Below is a sample of a contact with role ‘Client’ connected to another with role ‘Attorney’.