Personalized Community is here!
Quickly customize your community to find the content you seek.
‘Better Together’ Integration forum available
We're launching a how-to forum where you can learn and engage about how Dynamics 365 integrates with other Power Platform products.
Read about Better Together forum
2020 Release Wave 2Discover the latest updates and new features to Dynamics 365 planned through March 2021.
Release overview guides and videos Release Plan | Preview 2020 Release Wave 2 TimelineWatch the 2020 Release Wave 2 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
Have you ever been involved in a data migration project? Did you get any business requirement to completely migrate from outside software application to Dynamics CRM? Are your business users complaining about preserving critical date time fields data? Or maybe you are running some data cleansing/data validation tools on your CRM dataset and you don’t want ModifiedOn field to get replaced with present date. Don’t worry! You are looking at the right place.
I have recently written a blog on “How to save Dynamics CRM online storage space”? As part of that, I have migrated all note attachments from CRM to azure. But doing this has updated the modifiedby to my name and modifiedon to current date. However, a lot of business users complained that dates are critical, and they don’t want to get them updated.
Recently, we migrated from Dynamics SL to AX and the prime business requirement is to preserve the CreatedOn, CreatedBy, ModifiedOn, ModifiedBy fields data. This is common scenario when you are migrating data from outside applications into dynamics CRM and want to preserve some critical fields from getting updated. Wonder if you ever can edit those fields data or prevent the fields from automatically getting updated during the data migration process?
The following are few approaches you can follow to achieve above business goals:
1. Developing a Plugin
Plugin (custom coding) is one of the approach using which we can get control over these 4 holistic fields. You can use the traditional coding approach for editing the 4 attributes. Register the plugin in Pre-operation stage (synchronous). It is not going to work if your plugin is Post-Operation sync/async. If you want to prevent ModifiedOn and ModifiedBy fields from getting updated, then register a new step on update message and remove the fields from context. Use the following command:
If you want to override/enter a default modifiedon date or default modifiedby user, then use the following commands in plugin
_entity[“modifiedon”] = new DateTime(2018,10,10);
_entity[“modifiedby”] = new EntityReference(“systemuser”, new Guid(“81DD146A-AFF4-E711-8115-E0071B669FF1”));
Since the plugin is registered on update step, you don’t see createdon and createdby attributes as input parameters under Target entity. However, if you want to overwrite the 2 fields, use below code:
DateTime old_created = new DateTime(2018, 07, 20);
if(_entity.Attributes.Contains("createdon") == false)
Another approach is to register a Pre-Image step where we can capture the pre-image values of both modifiedon/modifiedby fields and assign them again to modifiedon fields in plugin. As a result, we are overwriting the modifiedon date with pre-image value thus preventing this field from getting updated.
To get control over the createdon & createdby fields, register a plugin step on create message. Use the below command in plugin to set the 2 fields to any default value:
_entity[“createdon”] = new DateTime(2017,08,12);
_entity[“createdby”] = new EntityReference(“systemuser”, new Guid(“9ADD146A-AFF4-E711-8115-E0071B669FF1”));
Another approach through which you can update the createdon field is by updating the Record Created On attribute (schema name is overriddencreatedon). These two fields act like counterpart to each other. Use the following code:
_entity["createdon"] = new DateTime(2016, 07, 23, 05, 23, 43);
_entity["overriddencreatedon"] = new DateTime(2013,02,14,08,23,21);
The above code will overwrite the createdon field with overriddencreatedon fields value and the overriddencreatedon field is set to the date & time when the plugin code is executed.
But the plugin should be registered in pre-operation (synchronous) stage to overwrite createdon field. You cannot overwrite overriddencreatedon field if the plugin is in Post-operation (sync/async) because these fields are already committed to database and therefore they are locked from getting edited by plugin.
Note for developers: Be careful while overwriting createdon and modifiedon fields simultaneously because there might occur human errors where modifiedon is older than createdon (which is practically impossible) and CRM wont validate this or either throw any plugin error.
2. SSIS Kingswaysoft Adapter
The main disadvantage of using 3rd party kingswaysoft connector is you don’t have complete control over all the 4 fields data.
There is another out of box field overriddencreatedon which can be mapped using SSIS kingswaysoft connector. So, you can map your desired date & time to this field. And after a new record is created, createdon field will get overwritten with overriddencreatedon value and the time when SSIS package is executed gets stored into overriddencreatedon field.
The only bad thing about create operation is you don’t have control over modifiedon date. And the value in createdby field simply gets copied into modifiedby field. You don’t have freedom to set modifiedby field.
3. Console Application
The third way in which we can try to update the 4 seemingly mystical fields is by writing a C# console application. Unfortunately, you cannot or don’t have ability to edit any of the 4 fields through C# console application. You must follow either of the above two procedures to achieve your business requirements.
4. CRM Out of Box Data Import
Another way to create or update existing CRM data is via CRM provide out of box data import feature. Using this method, you can provide only createdon date as part of the import file and this will create a new record with createdon fields value mentioned as per the import file. However, we don’t have control over updating the remaining 3 fields via data import procedure.
If you don’t have system admin security privilege you will get an error when you are trying to overwrite the crteatedon CRM field from data import file because of insufficient security privilege. Please make sure you have privilege on “Override created on or created by for records during data import” under business management tab.
One important point to note is that we cannot overwrite createdby field via data import process.
Business Applications communities