We all know that whenever we create an entity in CRM, CRM creates few fields by default. Some of these like Owner, Owning Business Unit, Created On, Modified On, etc. are used extensively while working with Dynamics CRM. But there are some fields that we use very rarely or even never; thus we tend to forget about them. But some of these fields are really important and can save a lot custom work, it’s just that we should be aware of them.
Recently there was a question on Dynamics Community regarding use of same fields which inspired me to search for them and have it documented. Few fields can be understood from their name but some fields don’t even have proper description in CRM. For such fields, below table can help. Links against the fields has more explanation and scenarios where these can be used.
||User who created the record.
||Date and time when the record was created.
||To create records on behalf of another user.
Used for impersonation in CRM 2011
||When I create a record, such as an opportunity,
and use a non-base currency, such as GBP in this
hypothetical scenario, this is what happens:
- I set the Currency field to GBP
- I put a value in the money field, called Estimated
- I save the record. During the save operation,
the following occurs:
- The Exchange Rate field is populated with the
- The Estimated Revenue_base field is populated
with the value from the Estimated Revenue field
converted to its inflated USD value
- Both of these updates occur whether the Exchange
Rate and Estimated Revenue_base fields are exposed
on the form or not
Afterwards, when the dollar makes that incredible comeback,
I need to update my exchange rate on the GBP currency.
I do so – it’s now 1, reflecting a 1:1 conversion rate.
What happens to my opportunity? Nothing, at least not immediately.
The Exchange Rate field on my opportunity is not automatically populated
with the new value of 1. However, as soon as I change the value of ANY money
field on the opportunity and save the form, the Exchange Rate field is updated
with the new value from the GBP currency record, and the Estimated Revenue_base
field is updated with the new converted value (and any other _base fields for other
money fields on the form – remember, there is only 1 Currency and 1 Exchange Rate field,
so these values apply to all money fields on the form). This also happens if I change the state
of the record, such as closing the Opportunity as won or lost, activating or closing a quote, etc.
||The import sequence number is a whole number field. The range can be customized if needed.
The basic idea behind this field is to store the sequence number (ID) of the source record during
data import to CRM. If this field is mapped during migration package/script design,
it provides a one-to-one link between source row and destination CRM record.
||User who modified the record.
||Date and time when the record was modified.
||To create records on behalf of another user. Used for impersonation in CRM 2011
||Date and time that the record was migrated.
||The definition of a recurrence pattern of how local time is converted to/from Universal Coordinated Time (UTC). This includes information about Daylight Savings Time (DST) versus Standard Time. Time zone rules can change over time, thus a time zone can have multiple rules from a historic point of view, but can have only one rule that is current and in effect.
||Currency associated with the entity.
||Time zone code that was in use when the record was created.
||This column is used mainly for concurrency support. The VERSIONNUMBER field is a unique value that gets incremented as records are updated – it can be very useful.
One of my college recently had a requirement to import few records into CRM with back dated values. Isn’t it a simple task? Just map/set the back dated value for ‘overriddencreatedon’ field while create/import of records. But has anyone checked what happens to the value for ‘createdon’ field?
All views and fields in CRM displays ‘createdon’ field and not ‘overriddencreatedon’. Thus, wherever we set value for ‘overriddencreatedon’, the value is set to ‘createdon’ field and the actual date/time when the record is created into CRM is set to ‘overriddencreatedon’.
E.g.: I’m creating a record on 2015-06-16 11:45:23.000 UTC into CRM with value for overriddencreatedon set to 2015-06-16 11:44:39.000 UTC. Upon completion, if you query the database you will see that the value what I set to overriddencreatedon is set to ‘createdon’ and the value for ‘overriddencreatedon’ is replaced with actual date/time when the record was created.
Update request at 2015-06-16 11:45:23.000 UTC:
Createdon = null
overriddencreatedon = 2015-06-16 11:44:39.000 UTC
Createdon = 2015-06-16 11:44:39.000 UTC
Overriddencreatedon = 2015-06-16 11:45:23.000 UTC
Note: Setting ‘overriddencreatedon’ on update of record is not supported.