Why are there both ‘Record Created On’ and ‘Created On’ date fields?
In Dynamics 365 CRM (Customer Relationship Management), there are two date fields, 'Record Created On' and 'Created On,' which may seem similar, but they serve different purposes:
- **Created On:**
The 'Created On' field represents the date and time when the record itself was originally created in the system. This timestamp doesn't change throughout the record's lifecycle, and it reflects the exact moment when the record was added to the CRM system.
- **Record Created On:**
The 'Record Created On' field, on the other hand, represents the date and time when the specific record was created. This date may be different from the 'Created On' date if the record was created as a result of a process or workflow, such as a record creation rule, automation, or data import. It captures the moment when the record instance was added to the system.
The distinction between these two fields is essential in scenarios where records can be created or modified after their initial creation. For example, if you have a workflow that automatically generates related records when a primary record is created, the 'Record Created On' field for those related records will reflect when they were created as part of the workflow, while the 'Created On' field will show the original creation timestamp of the primary record.
Having both fields allows for better tracking and reporting of data changes, as well as auditing purposes. It helps CRM users and administrators understand not only when the record itself was created but also when specific instances of the record were generated or modified within the system.
An Example of Working With These Two Fields:
While working on a data migration project recently, I found that I needed to track migrated records in the target system. I could have created a flag in the source system to identify the migrated records, however, this came after the fact and the initial migration had already happened.
We wanted to keep the Created On date in target environment as the original date the record was created in the source system. To do this, the createdon from the source was mapped to the overriddencreatedon (Record Created On) field in the target. When data was migrated, the createdon in the target is set to the value in overriddencreatedon, and the overriddencreatedon attribute is updated to the date and time the record is imported.
If there is no data mapped to the overriddencreatedon attribute, then createdon is set to the date and time the record is imported, and overriddencreatedon will be NULL.
Need help sorting out difficult fields? Contact 7Ones for a free consultation to discuss a working solution in more depth.