Solved: Navigation property naming issue when working with Lookup fields using the WebAPI endpoint in CDS/CRM Connection Manager

In one of my previous post, I explained about the navigation property naming issue when working with Lookup fields using the WebAPI endpoint in “CDS/CRM Connection Manager”. Recently, I got a mail from Kingsway Soft support team with a Hotfix to resolve this issue. I installed this Hotfix in my machine and ran a simple package successfully to update custom lookup (account) on Contact entity.

This Hotfix is part of the most recent official release ( You can download this from the below link.

So, I would recommend everyone to use WebAPI endpoint instead of SOAP in “CDS/CRM Connection Manager” due to the fact that SOAP endpoint is deprecated and no longer supported by Microsoft.

You can find all enhancements of the recent official release ( in the below link

Happy migration….

Performance issue while migrating activities

In this post I am going to explain how did I solved the performance issue while migrating activities using SSIS packages. My approach to migrate the data is, export the CRM data to Staging DB by using “Data Export” services and then to CRM by using SSIS packages. We all know that we have to migrate the party list (from,to,cc,bcc etc.,) data as part of activities migration and we need to write either SQL functions / script component to migrate party list data. I opted for SQL functions and I used those functions in SQL view. For ex, in email view I have to call 4 functions for each record to transform the data in party list fields (from, to, cc, bcc). So it leads to huge performance issue while fetching the data from staging table.

After a bit of research, I realised that I don’t have index for my intermediate tables. So I immediately created the following indexes.

  1. Index for “activityid” and “participationtype” fields on “activityparty” table
  2. Index for “activityid” on “email” table

and here is my SQL Function

CREATE function [dbo].[GetPartyListForEmail] (@activityid uniqueidentifier, @partyType int)
RETURNS nvarchar(max)
	DECLARE @partyList nvarchar(max);
	DECLARE @partyid as uniqueidentifier;
	DECLARE @logicalname as nvarchar(100);
	DECLARE @getPartyList nvarchar(max);
	DECLARE db_cursor CURSOR FOR SELECT ap.PartyId,ap.partyid_entitytype 
	FROM email em 
	LEFT JOIN activityparty ap ON ap.ActivityId = em.ActivityId
	WHERE ap.ParticipationTypeMask = @partyType AND em.ActivityId = @activityid;

	OPEN db_cursor
	FETCH NEXT FROM db_cursor INTO @partyid, @logicalname
				IF @logicalname = 'systemuser'
					SET @partyid = (SELECT TargetUserId FROM mapping_systemuser WHERE SourceUserId = @partyid)

				IF @partyid IS NOT NULL
					SET @partyList = Concat(@partyList, @logicalname);
					SET @partyList = Concat(@partyList, ':');
					SET @partyList = Concat(@partyList, @partyid);
					SET @partyList = Concat(@partyList, ';');
				FETCH NEXT FROM db_cursor INTO @partyid, @logicalname

	IF (LEN(@partyList)) > 0  
		SET @partyList= left (@partyList, len(@partyList)-1)

	RETURN @partyList;

After adding the indexes, I experienced huge improvement and processed 230k records in 2 hours.

Hope it helps…..