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 we will see how audit logs in D365 can be fetched that can be used for reporting purposes. Auditing helps to track changes made to the data in D365. The System Auditing entity cannot be accessed. Actionable Audit is a App by Microsoft Labs in which the required audit logs can be stored in the actionable audit entity which can be used later on by fetching the records of that entity. This audit log can be helpful to create Dashboards in Power BI, create reports etc to get meaningful information from the data. Implementation: Step 1: First we enable the auditing for the organization(globally) in Settings > Auditing. Step 2: We then enable auditing for the required entities and fields. Step 3: Download the Actionable audit app from the AppSource. Step 4: After accepting the terms and condition is done, it will take some time to install the solution as shown in the notification below. Step 5: In the plug-in registration tool we can see the assembly MicrosoftLabs.ActionableAudit is present. Step 6: Out of the box some steps are already registered as seen below Note: Only if the field is enabled for auditing the logs will be stored in Actionable Audit entity. Step 7: If required, the out of the box plugin steps can also be unregistered. And we can also add custom entities to the list. The pre-image and post-images also must be registered for different message which is shown in the user guide in the AppSource. Step 8: After the logs are created they are stored in Actionable audit entity as shown in the below example. Hope this helped!