Dynamics CRM 3.0 Customization: The basics

Posted on September 28th, 2006 mitch  Print No comments

One thing that I keep getting reminded of while entering into various CRM customization projects is that there is almost always two different ways to do the same thing in CRM 3.0.  Off the top of my head, I can think of the following methods that can be used to customize a CRM 3.0 installation:

1) Adding Entities and/or Attributes ( tables and columns for normal folks ).

2) Modifying the layout and display of existing CRM Entities.

3) Workflow rules.

4) Custom applications that utilize the CRM SDK including: Web pages, .NET assemblies, etc.

5) Callouts.

6) Connecting line of business applications and CRM together through custom code ( #4 and #5 ).

7) Custom data entry form actions implemented through JavaScript.

And what does this mean to a normal human being?  Simply this:

1) Document your requirements

2) Review the possible implementation issues and alternatives

3) How much time and money will be required to implement each alternative.

4) Choose the solution that best matches your requirements.

5) When in doubt: test in a development environment.

So just what in the heck are you talking about?

Well, let's review the a couple of situations that I've run up against and see what comes out.

Scenario 1: Linking a Lender with a Home Buyer.

We created a proof of concept for a local home builder and within the system, we had to record all of the contact information for any company and/or individual associated with a particular home: Home buyer, lender, title company, etc.

Issue 1:

So were do we store the contact information for these people?

Alternative 1:

Store them as Accounts and Contacts and link those back to the Home Buyer account and contact.

Alternative 2:

Create custom entities for each of the contact types and link those back to the Home Buyer.

Solution 1:

In this particular case, we had to choose Alternative 2 because that was the only physical way we could link everyone to everyone.  CRM 3.0 does not allow you to create multiple relationships between Entities and since Account and Contact are already linked, a secondary relationship could not be created.  Separate Entities were created for each company type and company individual ( i.e., Lender and Lender Contact ).  This allowed us to link a contact from each custom Entity to the Home Buyer ( Contact ).

Scenario 2: Build a new Entity or customize an existing Entity.

This will be the biggest decision you will make when customizing CRM.  If you have reviewed any of the CRM customization capabilities, you will know that it is very easy to add new fields and new tabs to the data entry forms.

But is that the right thing to do, or would it be better to separate this new set of information into its own Entity and link that Entity to the Account, Contact, etc.?

In most cases, if you just have a few fields that need to be added, you can just add them to the existing Entity and be done with it.  Creating a new tab is optional, of course.

I think the main decision point is whether or not you need multiple records.  A multi-record solution would almost always require a secondary Entity that you link back to its parent. You can even do things like display that information within an iFrame on the data entry form so the user can see both the parent's information and the secondary information on the same screen.

Note: It should be noted that some CRM 3.0 entities do not easily lend themselves to customization.  Things like Quotes, Orders, etc.

Conclusion:

It is very seldom that I run into an design requirement that can't be overcome using one of the methods outlined at the beginning of this article.  It usually all boils down to the amount of time and money you wish to spend.  An objective review of all of the facts is, in many cases, quite eye-opening when you consider needs vs. costs.

Customization, Dynamics CRM

(No Ratings Yet)

 Loading ...

1,503 views