Tuesday, March 1, 2011

Addresses in CRM explained....


We recently came across a request for data correction where the customer had lost some of their address data. No addresses were displayed on the Account form. One would think all that was corrupt was the address and having them type in the address on the form should do the trick. But no, with the address missing even when they tried to manually re-enter the address in these records, they were unable to, it would throw an error. That’s when we found out the following

When you open an Account, you are presented with a set of fields for storing address. If you check the CRM account entity details, you will find there are actually two sets of address fields available. By default only address_1 set of fields are placed on the form, but you can also add the second set of address_2 fields.

Besides this we are also provided with the option to add multiple other addresses under the More Addresses section on the account form.

Common perception of this design would be that 2 default set of address fields have been added on the account entity for ease of access and use. They have the Customer Address entity to store the more addresses associated with the Account.

We just happened to find out that this is not really the case. All addresses are only stored in the Customer Address entity.

When you create a new account/contact, it would by default in the background add 2 entries in the Customer Address entity for the 2 set of address fields available on the Account form. CRM distinguishes these entries from the rest of the entries to be displayed in More addresses using the Address number column. Address number 1 and 2 are reserved for the 2 set of address fields available on the account form.

The reference to these is stored in the Account entity schema using the address1_addressid and address2_addressid.


Hope this would help someone out there understand the technical concept of addresses much better from now on

Saturday, February 19, 2011

Difference between CRM 4.0 and CRM2011 script for using on form customization

When working with CRM2011 Java script we found many difference about syntax/methods between CRM2011 and CRM4.0 Please check some of the comparisions we have listed. Please click on the Image below to enlarge view.

Monday, February 14, 2011

Create and Update events for the appointment entity

You will notice that if you register a plugin on the Create or Update event of an appointment in the Parent Pipeline, the plugins do not fire. When you create an appointment in CRM it is set to the status of “Scheduled” implying an appointment has been scheduled.



To trap create and update of Appointment through CRM you need to trap the Book Request and Reschedule request respectively.



When you run the diagnostic tool you would find that the Book Request is fired. It will show up the following xml.


Tuesday, February 8, 2011

Workflows vs Dialogs

CRM 2011 introduces the new concept of Dialogs. We have discussed this in detail in our earlier blog that can be found at http://inogic.blogspot.com/2010/11/crm-2011-dialogs-explored.html"
Here we list out the differences between Processes (Workflows) and Dialogs.

Thursday, February 3, 2011

Issue with Pulishing Workflow that use Custom Workflow Assembly

While there can be many other reasons for this, recently we came across a situation where a simple workflow assembly designed by us could not be used in a Workflow. If we added the reference to this workflow assembly in the Workflow, it wouldn’t publish. We would receive the following message "An error occured when the workflow was being created. Try to save the worflow again". Refer to the image below.


There was no further information to be found in the event log for this.

Upon further review of the code, it was noticed that the Namespace and Class name was the same.

Upon changing the namespace to something other than TestWorkflow the workflow designer accepted the workflow assembly and published it too.

Just wondering if this were an issue, it should not have allowed us to register the assembly in the first place. It would have been a better indicator of something being wrong with the class declarations.

For anyone else who face the same problem… it might help to check the class name.