Topic: ‘Customization’

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.

A colleague in our Administration department recently approached me with a dilemma.  Companies in the database were getting bought by other companies; however they were remaining clients of ours (from the start, it doesn’t sound like too much of a dilemma to me…).  However, if a sales representative were to search in the CRM database for an Account with which they were familiar (and that particular Account had recently been renamed), no results would surface.  To help “relabel” the changing companies, our Administration department has cleverly labeled the old name as an “Alias.”  So the original name will remain on the record, but as an “Alias” field.  The field was placed on the record in order to display the original title of the company (the new title of the company was populated into the “Account Name” field of the record).

Why were no results returned in the search?  The company had been renamed, and the sales representative had not become akin to the new name – so they technically were searching the database for an Account name that didn’t exist.  We needed to find a way for our employees to search the company by the old name, now the “Alias,” but still find the company under the new name, the “Account Name.”  I thought of a few ideas – Advanced Find views, new columns, email notifications through workflows, etc. – but none of them were ingenious enough.

I finally came up with the idea to utilize the Quick Find View functionality inside of CRM. Some people just glance at this section inside of CRM and move past it – at least I know I did.  When you add a Quick Find column to the View, a column doesn’t even show up.  Upon first glance, it doesn’t even really seem like it does anything.  Until you do some research, fully test out the functionality, and utilize the Quick Find View from every angle, it will seem like a mystery.

This is the short version of its functionality: if you add a Find column in the Quick Find view of, let’s say Accounts, you will be able to search based on that particular column, regardless of the generic fields upon which you usually search.  So you could add the City field to the Quick Find View, and be able to search based on “New York” or “Atlanta,” or even a custom field that you have created yourself on the Account record – in our case, the “Alias” field.

So I navigated to the Quick Find Active Accounts View in the customization area of Accounts…

…clicked Add Find Columns…

…added the “Alias” field to the Quick Find View as a Find column by clicking the Alias field…

…and clicked OK. In order to be more thorough, I added “Alias” as a View column, just to keep the confusion down to a minimum (”Why did I type in Company A and Company B popped up?”).  I saved the Account record and published all of my customizations.

Afterwards, success! I was able to successfully search inside of Accounts based on the “Alias.”  I created a test Account called Corporate Coffee, with an “Alias” called Corner Coffee House.  I searched based on the “Alias,” and successfully returned the record with the Account Name Corporate Coffee.