In normal business scenarios, a customer can be of type Account or Contact in Dynamics CRM. We also have fields of type Customer on some entities like incident which are lookup of type Account or Contact. But the creation of this type of lookup was not possible.
With CRM 2016 Update 1, customizer now has the ability to create Customer field for any OOB or custom entity.
With Microsoft Dynamics CRM Online 2016 Update 1 and Microsoft Dynamics CRM 2016 Service Pack 1, we now have an option to track feedback and ratings from customer for records in CRM with the click of a check box.
- A new option appears on general tab on an entity customization form called “Feedback” which once checked creates an 1:N relationship of that entity with feedback entity similar to activities.
- Users can use this entity to enter their response.
- Feedback entity itself is customizable.
You can enable feedback on entities to allow customers to write feedback or provide ratings for any entity record.
Scenario: Business wants to track feedback received from customers on the customer support experience. In this case you can enable feedback for the Case entity to receive feedback.
In case of multiple ratings against one particular record, with use of simple rollup field the ratings can be consolidated.
Recently customer came up with a query that CRM performs multiple updates and all these updates are logged inside audit history.
Here is what was happening.
- CRM user updates “Middle Name” field.
- On checking audit history, we have three entries for “Full Name”, “Middle Name” and “Yomi Full Name”.
We didn’t had any plugin or customization done here. After verifying on vanilla CRM online environment we found that these extra updates are performed by CRM internal engine/plugin.
Now comes the question, if we cannot customize “Full Name” field to show middle name in it then why we need an update like this?
What is “Yomi Name”?
Yomi Name is an out-of-the-box field that has the same functionality of First and Last Name for a contact. However, it allows for the user to indicate the phonetic annunciation of the name as described in the description of the field:
“Type the phonetic spelling of the contact’s first name, if the name is specified in Japanese, to make sure the name is pronounced correctly in phone calls with the contact.”
Note: This is all about UNSUPPORTED database level updates. These kind of updates are not recommended (unless you are left with no options).
Though any kind of database level updates are not recommended in CRM, there are scenarios where we are required to do so. I had one such requirement where I was required to perform a simple update (setting two options field value to Yes) for millions of records. Doing same using a supportive way (bulk update or bulk workflow execution) used to take days due to CRM service calls but same updates using SQL script was done in few hours.
I had auditing enabled for these records in CRM, but as this was unsupported db level update I was not expecting any help from audit history. What was expected form auditing was either of below:
- Change track as new update request in audit history. (If there is any kind of trigger return at db level to maintain auditing)
- No updates at all in audit history. (Assuming auditing are maintained by some kind of workflow/plugin that trigger at UI level)
Unfortunately, none of this happened and what happened was not at all audit friendly or expected. This is what happened:
The change made by SQL script was tracked at create event itself in audit history. But only the field value change was tracked and not the change date/time. The change date/time was still showing when the record was created.
Though these kind of changes are not recommended, but I still feel that in some cases these are required and this behavior of auditing will affect the consistency. I feel that things should be either completely baked or not baked at all than having them half baked. But again this is only what I feel. J
I created a Contact record on 7/6/2015 at 11:52 AM with ‘First R~~~~~ Created’ set to ‘No’. Audit history shows something like below.
Now on 7/6/2015 at 12:00 Noon, I update the value for ‘First R~~~~~ created’ to ‘Yes’ using a database level update script. Ideally there should have been a new entry made in audit log to track this change and there should be no change made to existing audit history records. But CRM updates the changed value in create event itself without even tracking the change time.
Hope this helps and thanks if you have come all the way down here reading the article.
I have an OOB workflow process developed some time back and activated. Now when I try to open the process, I get generic CRM error (below image). Also the process status is changed to “Draft” automatically. There were no updates made to the process.
I have seen these issues frequently especially when working with Child Workflow Processes where I have a child workflow called from a Master workflow. If you have a Master workflow calling a child workflow and for some reason the child workflow is activated as “Process Template”, then user gets this error when they try to open the master workflow.
CRM throws generic exception and its status is changed to Draft if it linked/related to a “Process Template” instead of “Process”.
Other common issue faced while working with workflow process is “Invalid Expression” error in “Condition Expression” step. This occurs if the field used in condition expression is either deleted from system or if Value is changed. Once you fix the field/value issue, all conditions in the process are automatically fixed.
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.
New system setting is introduced Sales territory change in CRM 2015 to set default price list in opportunity. If this setting is set to No following territory configuration won’t work. This setting comes in picture while setting Territory based default price list.
For this, create a territory (e.g. USA) -> add Manager. Multiple members can be added by clicking Members in Common section in left navigation -> Add members.
Once territory is created, create price list –> add price list items -> in territory relationship grid add territories (e.g. USA) for which current price list should be default.
Save changes and now as per our configuration, for territory manager and members inside territory, Shirts Price list becomes default i.e. pre-populated while creating new opportunity. Price list can be changed if required.
Another approach to set default pricelist for opportunity is to create a simple business rule on opportunity form which sets value of field Pricelist. Once business rule is activated, for every new opportunity default price list is set.
Note: Business rule overrides Sales Territory settings. System setting shown above does not affect business rule.
Please refer below link for more information