Topic: ‘Customization’

During my time as a CRM Consultant, I’ve realized something very important. However troublesome the journey, there’s always a silver lining – experience. So even though I’ve only been in the game a short amount of time, I’ve come up with a few best practices that I prefer to follow when implementing Dynamics CRM. For those who know me, I tend to be…opinionated is a good way to put it. So, yes there may be other ways to utilize CRM and still get by.

It’s known that each process flow – sales, marketing, service, SOP – requires a different path, but these should provide you with broad and useful guidance inside of CRM. Do note that the list below is by all means incomplete (Oh yes, I have plenty more…). These statements are an example of the tips that have given my clients – regardless of industry and business practice – the ability to enjoy clean, useful, and more importantly, valuable, CRM systems.

• For DATA ENTRY…Before importing data into the CRM system, spending a little bit of time running through and shaping the spreadsheet. Cleaning up the rows and columns will save you hours of data cleansing down the road. CRM is only as good as the data that is placed into it. And who knows – you may have missed a column that you need inside of the system.
• For PROJECT MANAGEMENT…Document, document, document. There is no such thing as “documenting too much.” Clients love nothing more than to see a clean, printed, color document with their logo on the front (who doesn’t?) and all the CRM information they could need. Documenting too little, however? That (unfortunately) exists.
• For PROCESS FLOW…When converting to Customer records (in the situation where the Customer does NOT exist in the system yet), I always recommend converting to at least an Account and a Contact. This is not only a time saver, but it is proper structure. After speaking with and qualifying a Lead, you are always going to have a company and a person in the system (Who signed the Contract? What organization did you type into Hoover’s before meeting with them to do a demo?). The one exception may be the Opportunity. If there’s no potential revenue to begin working within the next 6 months (depending on your average sales pipeline time and size), you can probably hold off on the Opportunity until you see it in the pipeline and can properly document what is necessary.
• For ATTRIBUTE ADJUSTMENT…When renaming fields, rename from the Attribute level the majority of the time. The main time renaming from the Form level comes in handy is when you have more than one field that needs to be named the same. (Example, “Date”). You can rename them in a unique manner on the Attribute level, and make them uniform on the Form level. The reason for this is mainly due to Advanced Find search capabilities. If you name everything the same, you will have more than one field in the AF search on that particular entity (causes much confusion).
• When CREATING FIELDS…When creating a new field, once you save the record after creation, you CANNOT change the type. So always be sure that you have the correct field type selected, otherwise you will have to create another field. So after I create a Picklist, I cannot “change” it to a character field. Same thing with the schema name – once the field is created, the schema information set in stone. To “change” the field, you would only be able to create a new field and remove the old one. I always document exactly what I need to create BEFORE creating them in the system. If you’re working for a client, create a spreadsheet of the fields (Display Name, Field Type, Requirement Level, Number of Characters (for Nvarchar fields), Potential Values (for Picklist or Bit fields), and any additional information) – this is important for proper generation and understanding. Nothing’s worse than realizing you’ve made a dumb mistake and having to delete and recreate 100 fields. And then justifying (or more accurately, trying to justify) the additional work to the client…
• For WORKFLOW…Always map and plan your workflow first before building the structure: this will help you just in case you make a mistake in the structure. Plus, mapping it out allows you to understand exactly what needs to happen. You may need a wait condition instead of a check condition – you can’t change this after you build the workflow.
• For WORKFLOW…You can’t change conditions in the logic, so always make sure that you’re creating the workflow properly from top to bottom. This statement certainly ties in with the workflow best practice listed above. When adjusting the structure of a workflow, if you are removing/adjusting part of the basic structure, deleting one step will remove everything after it.
• For ADMINISTRATION & TROUBLESHOOTING…Never delete a used security role. I know, you have the ability to do it, but I wouldn’t. Especially if a CRM user (or more than one CRM user) currently has the role. Deleting a utilized security role will kick those respective users out of the system. If you do want to get it out of the system, do this. Copy the role and plan on using the new role. Rename the old one to say “UNUSED” or “OLD.” Spend some time making sure all of the users are not assigned that particular security role. Run reports, AF views, whatever will help you verify that no one currently has that particular role. Then remove it from the system. This will keep you from getting dozens of angry, frantic emails.
• A CRM/OUTLOOK TIME SAVER…Utilize CRM shortcuts from inside of an email. After you track an email or Contact from Outlook inside of CRM, there are two buttons inside of the individual Outlook record that will take you directly to the respective records inside of CRM: View Record and View Parent (this will take you to the actual CRM record). This is really handy if you’re converting an email to an Opportunity.

Do you have any tips or tricks that you use when implementing CRM? If you do, I’d love to hear them!

Nothing good, that’s for sure. You probably won’t know until you encounter a similar problem, but there is actually hidden javascript code on the form that invokes actions when this field is selected. When you remove the field from the form, so goes the code. If you decide to put it back on the form, the code doesn’t come back with it. The main result of this is that when you try to select a Default Price List using this lookup, nothing is returned in the lookup list, even if you have values. Therefore, you cannot add Products to Opportunities.

To get the code back on the form, perform the following:

1)      Export the customization xml of the entity in question after you have added the Default Price List back to the form.

2)      Open the xml in a text editor.

3)      Search for the text “Price List”.

4)      Between the </labels> and <control tags for this field, paste the following text:

<events>
<event application=”true” active=”true”>
<script>
<![CDATA[
var oLookup = event.srcElement;
AddTransactionCurrencyParam(oLookup);]]>
</script>
<dependencies>
<dependency />
</dependencies>
</event>
</events>

5)      Save the xml and import back into CRM.

Everyone loves customization – especially CRM clients. Having the ability to view and use a record customized to your day-to-day business process flows is extremely valuable. Donna Edwards has posted a great blog example on the Microsoft Dynamics CRM Team Blog regarding the creation of a custom Quote, Order, or Invoice record by utilizing Visual Studios 2005 (she has mentioned in the blog post that the same principles apply when using 2008). Click here to view the post.

MSCRM formats all integers according to the Number Format shown in the Format Tab of the System Settings screen.  Sometimes you do not want an integer formatted that way, example of this would be a field that captures a year such as 2010 or an ID from a legacy system or ERP system involved in an integration.

To solve this issue, put the following JavaScript on the onLoad event of the Form.  This example uses the field called new_legacyid.  Just replace new_legacyid with whatever your field name is.

if(crmForm.all.new_legacyid.DataValue != null)

{

crmForm.all.new_legacyid.value = crmForm.all.new_legacyid.DataValue;

}

It is the value attribute, not the DataValue attribute, that is displayed in the browser.  The value attribute is what is formatted – it is formatted before the onLoad event fires.  Since the DataValue attribute has the raw integer value, you can now set the value to the DataValue, thus bypassing the formatting.

For the most part, I try to steer people away from renaming fields directly from the form POV. This usually creates a more disorganized environment (and believe me, disorganized environments are my “nails on a chalkboard.”). If javascript is desired on the form sometime down the road, the code is usually difficult to understand and read if schema names do not accurately reflect the purpose of the code. Additionally, and most importantly, the information will be nearly impossible to understand from an Advanced Find POV (searching for SSN information by selecting Anniversary seems strange to me…). However, sometimes this comes in handy, and is almost beneficial from a form cleanliness standpoint. So I like to go by a certain “A or B” rule when renaming fields. This helps the environment I’m working on stay user-friendly and organized.

Situation A: I have a new field I want to put on the form, but I have fields on the form that I don’t use. Should I recycle a field or create a new one?

Solution A: Remove the unused field from the form, and CREATE A NEW FIELD. This will reduce the amount of confusion down the road, and it also leaves open the possibility of using that particular field sometime in the future. Business processes change, and the existing fields in the system may become useful sometime down the road. Always leave this possibility open by creating new fields for new needs.

Situation B: I have 4 different fields with the exact same name, let’s say Monthly Fee. I want them all to say “Monthly Fee” on the form, but I want to be able to run AF queries off of each of these data points.

Solution B: From an Advanced Find standpoint, it will be difficult to know which Monthly Fee field you’re selecting. If you’re looking for a specific one, they would need to be renamed to something else. When encountering this situation, I RENAME the field from the FORM LEVEL. I make sure each field name is unique from the attribute level (e.g. when I’m creating the fields, before saving them), and input an attribute name like Monthly Fee (Q1). Inside of the field properties on the form, there is a Display Name area. Rename the field here. Doing this keeps the form  clean (no parentheses), and keeps Advanced Find searchable.

Here’s a rough example:

FIELD 1: Monthly Fee would be the display name on the form, but the attribute’s true display name would be Monthly Fee (Q1)

FIELD 2: Monthly Fee would be the display name on the form, but the attribute’s true display name would be Monthly Fee (Q2)

FIELD 3: Monthly Fee would be the display name on the form, but the attribute’s true display name would be Monthly Fee (Q3)

FIELD 4: Monthly Fee would be the display name on the form, but the attribute’s true display name would be Monthly Fee (Q4)

The best way to accomplish the above example would be to plan for it – map it out before you create it. This will be much easier than fixing something that’s already built (mostly from a confusion standpoint rather than a time standpoint). However, if you already have an environment in place where this is an issue, the best way to do it would be to follow this process flow:

1. Rename the fields from the ATTRIBUTE level to a unique name (do this on all of the fields in question before moving onto step 2).

2. Rename the fields from the FORM level to a uniform name.

I absolutely love using calculation javascript – it ends up being worth the time and effort it takes to place it inside of the system. It’s amazing to think about the total amount of time you save by utilizing this custom functionality. However, the most difficult part of generating a collection of calculation code is coming up with the actual formula and making sure it calculates out correctly.

I recently read a blog by Mitch Milam on the Microsoft CRM team blog that was completely inspiring. He has generated a simple collection of calculations that will generate a final ROI amount for you. While there’s no code on the actual blog, the calculation javascript is simple and well known. As long as you place Mitch’s concept behind the javascript, it should be relatively simple to piece together.

Click here to view Mitch’s calculation concept on the MS CRM team blog.

This concept is extremely powerful from a decision-making standpoint. Your return on investment can illustrate many things – are you spending the money you’re spending NOW in the right places? Are you going to be putting your money where the best return actually lies? These decisions cannot be made without viewing your ROI. And being able to plug in a few numbers and see the final piece to the puzzle is just fantastic.

A field level security whitepaper from the Microsoft team has recently been released – contains some interesting functionality.

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=471f8670-47b3-4525-b25d-c11a6774615c

I know we all have done this before, but it seems like someone struggles with it every time. Here is a function that you can use in the OnLoad event that makes this a little easier. The only thing you need to change is the name of your iFrame and the area name that goes into the function call, i.e. GetFrameSource(“areaExistingProducts”) where “areaExistingProducts” is the associated view that you want to show in the iFrame. The area can be found by viewing the source code of the page where the associated entity exists. You can do this by opening the page and then CTRL+N to enable you to see the IE Toolbar. Click View/Source and do a search for the entity in question and then look for the part of the source where the entity is preceded by “area.”

 /*********************************************************************/

function GetFrameSource(tabSet)

{
  if (crmForm.ObjectId != null)
    {
        var oId = crmForm.ObjectId;
        var oType = crmForm.ObjectTypeCode;
        var security = crmFormSubmit.crmFormSubmitSecurity.value;
        return “areas.aspx?oId=” + oId + “&oType=” + oType + “&security=” + security + “&tabSet=” + tabSet;
    }
    else
    {
        return “about:blank”;
    }
}

crmForm.all.IFRAME_Products.src = GetFrameSource(“areaExistingProducts”);

/*********************************************************************/

Below is a simple SQL Statement to change the format of Contacts’ names in Microsoft CRM.  We didn’t reinvent the wheel with this, and we’re sure this is posted somewhere, but we have it and thought we would share.

Run this SQL statement against the MSCRM Organization DB.

(As always, before you make a modification to the DB, it is recommended that you make a backup of the DB or the tables that are being modified.)

 
“Last Name, First Name” format for Contacts:

UPDATE contactbase SET fullname = ISNULL(lastname, ”) + ‘, ‘ +

ISNULL(firstname, ”)

“First Name Last Name” format for Contacts:

UPDATE contactbase SET fullname = ISNULL(firstname, ”) + ‘  ‘ + 

ISNULL(lastname, ”)

 *This solution involves making changes to 1 or more databases.  It is not suggested that changes made to a database without first making a backup of the database.  If possible, alternatives such as a MS Hotfix or MS rollup should be used to try to solve the issue, before modifying a database.  If you do decide to modify the database, it is suggested that the modifications are made by an IT Director, Technical Specialist or MIS department.  Serious problems might occur if you modify the database incorrectly.  Be sure to backup the database before making changes.  Any problems might require that you rollback your databases and even result in the loss of data records.  I.B.I.S., Inc. cannot guarantee that these problems can be solved. Modify the database at your own risk.