Introduction: While migrating Cases, the migration of activities of type ‘Case Resolution’ is necessary. However, the complexity in migrating this increases due to the fact that when the status of a case is updated, a blank case resolution activity is created automatically by the system. This system-generated case resolution needs to be deleted as this would result in each case having two case resolution activities after migration – one system-generated and one with the correct migrated data from the source. Solution: To tackle this issue, one must follow the following steps during migration: 1. Send all Cases (no matter what the status in the source environment) to the target with their status as ‘Open’. 2. Send all related activities to the target environment. 3. Update the case status in the target environment to its status as in the source environment. 4. For cases with status ‘Resolved’, a system-generated case resolution activity will be created. 5. In your case resolution migration map, first add a step to delete the existing case resolution in the target and then insert the case resolution from the source environment. 6. Now your case with status ‘Resolved’ will have only one case resolution and that will be the one migrated from the source environment with the correct data. Conclusion: Above steps shed some light on how to preserve the integrity of case resolution activity data in your target environment during data migration.

Introduction: While migrating Email Activities from D365 v8.2 to v9, I came across the following error: “Operation failed. Label: Create email, Name: emailCreate2, Message: -2147220969: ActivityPointer With Id = XXXXXXXXXXXX Does Not Exist” This can cause some confusion as activitypointers do not need to be migrated before you begin migrating emails. What are ActivityPointers? The activity pointer (activity) entity represents any activity or task that is performed, or to be performed by a user. An activity is any action for which an entry can be made on a calendar. Whenever you create an activity record in Microsoft Dynamics 365, a corresponding activity pointer record is created. This indicates that the activity record and the corresponding activity pointer record have the same value for the ActivityId attribute. For example, if you create an Email record, the attribute values of Email.ActivityId and the corresponding ActivityPointer.ActivityId will be the same. This should not be confused with ActivityParties which represent a person or group associated with an activity. An activity can have multiple activity parties. Cause: Upon inspection, I discovered that those emails are linked to themselves, having the ‘parentactivityid’ field populated with its own activity GUID. The error was being caused because Scribe could not find the parent activity in the Target environment (since it had not yet been created). Solution: Remove the ‘parentactivityid’ mapping from the ‘Create Email’ block. Add an If-Else Block below the Create block to check if the Email has been created, and if true, use an Update block to update the Email with the ‘parentactivityid’. Now, the Email activity will be created with the correct GUID and once created, will be updated with the required GUID as ‘parentactivityid’. This solution resolved the above issue and email activities  can now be created without this error occurring.

Introduction: In this blog, we try migrating Email Template records under Email Marketing module in ClickDimensions. ClickDimensions has many modules like Email Marketing, Analytics, Event Management etc. Under Email Marketing Module, we have entities like Email Template, Email Sends, Sent Emails, Unsubscribes and so on. While trying to migrate all the Email Templates from D365 v8.2 to v9 using TIBCO Cloud Integration, we encountered an issue. We could not find any field or entity that stored the HTML code which formed the body of the Email Template. The reason behind this issue is the HTML code is stored on the ClickDimensions side and not on ours. Therefore, in order to migrate Email Templates successfully, we need to use the Import/Export options in ClickDimensions Settings. Steps: 1. In your Source environment, go to Settings and click on ‘ClickDimensions Settings’. 2. Click on ‘Export’. 3. Select the entities you want to export and click on ‘Next’. 4. Click on ‘Export’. A .zip file will be downloaded. 5. Now, go to your Target Environment and click on Settings -> ‘ClickDimensions Settings’-> ‘Import’. 6. Click on the ‘Upload ZIP File’ button and select the file you just downloaded from the Source Environment. Click ‘Import’. Conclusion: The Email Templates will now be present in the Target System. This process did not change the GUID of the record, which is important to note as it may be required further on in the migration process. I hope this blog contributed to clearing things up when it comes to migrating Email Templates in ClickDimensions. I will be adding more blogs about migrating records in other entities of Click Dimensions soon. Stay tuned!

Introduction: In this blog, I will outline how to migrate Email Attachments and update the status if an email. In my previous blogs, I have shown how to migrate the body of an Email and its Activity Parties from one CRM to another using Scribe. Email Attachments: Below, is the map used to migrate Email Attachments. As you can see, it is pretty straightforward, barring a few things to keep in mind while mapping. 1) Email Attachments are stored in the ‘activitymimeattachment’ entity. 2) I did not map the ‘attachmentid’ field as it produced an error as well as there is probably no reason one would need the GUID of the attachment. Not mapping attachmentid will create a new GUID for the attachments being migrated. 3) Most data regarding the Attachments migrated along with the first map migrating ‘Email’ activity. 4) That is why, in this map, we just migrate the subject, filename and body fields along with ‘objectid’ and ‘objecttypecode’. 5) The ‘objecttypecode’ tells which entity the attachment belongs to and its GUID. Once you run the map successfully, you will see the attachments displayed in the email. This includes image attachments as well. Target: Email Status Update: As for most Activity entities, while migrating, we migrate with an ‘Open’ status. This is done to ensure the record does not become read-only which would not allow us to migrate the corresponding Activity Parties and Attachments. This could lead to an inconsistency in data in Source and Target. Once the Activity Parties and Attachments have been migrated to the record, we can now update the Status of the Email to what it is in the Source environment. This is a basic but fundamental step to ensure no data inconsistency. Sample State Code & Status Code Values: In this map, all we have to map are the ‘Status Code’ and ‘State Code’ as it is in the Source Environment. This will update the status of the email. In the screenshot below, you can see that the Status has been updated to ‘Sent’. Conclusion: This completes the process of creating TIBCO Cloud Integration Maps for Email Migration from CRM to another. I hope this and my two preceding blogs provide a sufficient outline for the process of Email Migration.

Introduction: In this blog, I will detail how to migrate Activity Parties of Emails from one CRM to another. In my previous blog, I outlined the first step of the Email migration process which is migrating the body of the email. Migrating the corresponding Activity Parties of an Email is the second step of this process, as the Email body now exists in the Target CRM. What are Activity Parties? Other than the Body, an Email Activity consists of: Sender: The person(s) sending the email. Recipient: The person(s) receiving the email. CC & BCC: The person(s) that are copied in the email. Owner: The person who is the owner of the email. Regarding: This generally links to an entity in CRM which pertains to the email. For example, a Case or a Project in CRM. ‘Sender’, ‘Recipient’, CC’, ‘BCC’, ‘Owner’ and ‘Regarding’ are each stored in CRM as a separate Activity Party of that email with a ‘Participation Type’ code (field name: ‘participationtypemask’) to establish the field that specific party belongs to i.e. 1 = Sender, 2= To Recipent and so on (as shown below). Generally, in an Activity Party, the person(s) are either System Users or Contacts. This is specified in the field ‘partyobjecttypecode’ as shown above. Keeping this in mind, one can lookup to these entities to obtain the corresponding GUIDs in the Target System and map it as the ‘partyid ‘. After the Activity Party is created, the owner of the Activity Party should be updated as per its owner in the Source environment. The ‘Owner’ Activity Party is automatically created by CRM as the same User as the Owner of the Email (configured when you migrate the Email Body in Step 1). The ‘Regarding’ Activity Party links to a Case/ Project and not a ‘person’, however, the same logic applies i.e. map the required GUID and its type. Migrating Activity Parties is not as complicated once understood. Unfortunately, not much is easily available online about this. I hope this blog demystified a few concepts about Activity Parties of an Email and how they can be migrated from one CRM to another. My next blog will detail how to migrate Email Attachments and update the status of an Email.

Introduction: Data migration can be a little challenging, especially when it comes to Emails. In this blog, I will outline the steps that need to be followed to successfully migrate Emails as well as important things to keep in mind during the process. Steps: There are four main steps to follow to successfully migrate an Email from Source to Target: Send the body of the Email. Send all the related Activity Parties. Send the details of the related Email Attachment(s). Update the Status of the Email. In this blog, we will be dealing with the first step i.e. creating the map in TIBCO Cloud Integration to send the Body of an Email. Migrating the body of the Email is straightforward compared to the next step but there are a few aspects to keep in mind: 1) Send the email as Open so that Activity Parties and Attachments can be migrated in the following steps. Not sending the email with an “Open” status could lead to Activity Parties and Attachments not being migrated to the corresponding email. 2) When an email is migrated, the owner of the email will be the User configured in the CRM Connection in Scribe. In order to maintain the same owner as in the Source, you can update the email with the correct owner after it is created. In the screenshot below, I am using a Lookup Table in Scribe to map the User GUID of the Target System. 3) If you want the GUID of the email to remain the same in Source and Target, do not forget to map the ‘activityid’ of the Email entity. Conclusion: I hope this blog provided some insight into the migration process for Email Activities. In the next blog ‘Email Migration from CRM v8.2 to CRM v9 using TIBCO Cloud Integration: Activity Parties‘, I will talk about migrating ‘Activity Parties’ which can be the most challenging part of Email Migration.