Sam Jones CRM Corner

Handling Service Level Agreements (SLA)

You've probably heard of service level agreements before. They are the backbone and workhorse of the service desk industry. They are a way to measure the performance, not only of the helpdesk itself but almost every part of it and done correctly, yields a wealth of information. It's a pity then that there is no inbuilt way to handle this within Dynamics CRM, but I think I have a way that is pretty good all the same and will do the job regardless.

Now, forgive me if my javascript is a little clumsy in places, but this is my first effort at a complicated script, but it does the job nicely.

Right, lets get down to it. This method is not just a javascript routine, but a combination of various methods both native and alien to the CRM. By combining these elements together, you can come up with something that is pretty sophisticated.

Preparation

1) A new attribute called new_slabreachtime. Make this attribute a date/time value and add it to the Cases Form. This attribute will hold the actual SLA Date in a format that the CRM can access from a workflow procedure.

2) A new attribute called new_sladate. Make this attribute nvarchar. This entity will hold the friendly human-readable SLA date.

3) The following code pasted into the OnChange event of the 'prioritycode' attribute on the Cases Form.

   1: //determine Priority value

   2: var sPriority = document.crmForm.prioritycode.value;

   3:  

   4: //determine status code

   5: var sStatusCode = document.crmForm.statuscode.value;

   6:  

   7:  

   8: //Determine number of hours to add for each Priority level

   9:  

  10: if (sStatusCode == 10) //the Case cannot be closed already

  11:      {

  12:      alert("Error : You cannot set a Priority when the case is CLOSED. Please check and try again");

  13:      crmForm.prioritycode.focus(); 

  14:    return false; 

  15:      }

  16:  

  17: else if (sPriority == 1) //Critical cases have 4 hours

  18:  {

  19:      var sHour = 4

  20:  }

  21: else if (sPriority == 2) //Next Business Day have 24 hours or plus 1 day

  22:  {

  23:      var sHour = 24

  24:  }

  25: else if (sPriority == 3) //Non Urgent cases have 3 business days (24 x 3 = 72 max)

  26:  {

  27:   var sHour = 72

  28:  }

  29: else if (sPriority == 4) // To-Do cases have 5 days max (24 x 5 = 120)

  30:  {

  31:   var sHour = 120

  32:  }

  33: else if (sPriority == 5) // Scheduled tasks have 30 days max (24 x 30 = 720)

  34:  {

  35:   var sHour = 720

  36:  }

  37: else if (sPriority == 0) //SLA Breach (system set)

  38:  {

  39:  //dont do anything at all. This is to stop the workflows balking when they update

  40:  //the priority level programmatically.

  41:  return false;

  42:  }

  43:  

  44:  

  45:  //determine SLA Breach Date/Time

  46: var sBreachDate = slabreachtime(sHour)

  47:  

  48:  

  49: //Now determine the hour of the breach time in whole numbers. This is necessary to 

  50: //decide whether the case is outside of business hours or not.

  51:  

  52: var curHour = sBreachDate.getHours()

  53:  

  54: //We need the Day Name to determine if the SLA Breach Date is either a Friday, Saturday or Sunday

  55: var d=sBreachDate;

  56: var weekday=new Array(7);

  57: weekday[0]="Sunday";

  58: weekday[1]="Monday";

  59: weekday[2]="Tuesday";

  60: weekday[3]="Wednesday";

  61: weekday[4]="Thursday";

  62: weekday[5]="Friday";

  63: weekday[6]="Saturday"

  64:  

  65: var sBreachDayName = weekday[d.getDay()]; 

  66:  

  67:  

  68: //Now, we need to make sure that the NewBreachDate does not fall on a Saturday or Sunday

  69: //if it does, then move the breach date to the next available working day

  70:  

  71: if (sBreachDayName == "Saturday" || sBreachDayName == "Sunday")

  72:  {

  73:     alert("The SLA Breach Date will fall on a " + sBreachDayName + ". Advancing SLA Breach time to the next available working day");

  74:     if (sBreachDayName == "Saturday")

  75:      {

  76:      alert("advancing date...");

  77:      sBreachDate = recalcDate(48,sBreachDate);

  78:      //convert nasty UTC date to friendly one

  79:      crmForm.all.new_slabreachtime.DataValue = sBreachDate;

  80:      crmForm.new_sladate.value = FriendlyDate(sBreachDate);

  81:      return false;

  82:      }

  83:     else if (sBreachDayName == "Sunday")

  84:      {

  85:      alert("advancing date...");

  86:      sBreachDate = recalcDate(24,sBreachDate);

  87:      crmForm.all.new_slabreachtime.DataValue = sBreachDate;

  88:      crmForm.new_sladate.value = FriendlyDate(sBreachDate);

  89:      return false;

  90:      } 

  91:  

  92: }

  93:  

  94:  

  95: //Now we need to check the time of the call against the Priority Level.

  96: //Since Critical Cases (Priority 1) have a 4 hour SLA, the latest that they can

  97: //be logged for completion is 1200 hours. If the logging day is a Friday, we

  98: //need to advance the SLA Breach time to Monday but retain the Critical status.

  99:  

 100: if (sPriority == 1)

 101:      {

 102:     

 103:     if (curHour >= 12 && sBreachDayName == "Friday")

 104:     {

 105:     //it is too late to set a CRITICAL Priority for that day

 106:     alert("WARNING : it is too late to complete a Critical case today. Advancing SLA Breach time to the next available working day");

 107:     sBreachDate = recalcDate(68,sBreachDate);

 108:     //convert nasty UTC date to friendly one

 109:     crmForm.all.new_slabreachtime.DataValue = sBreachDate;

 110:     crmForm.new_sladate.value = FriendlyDate(sBreachDate);

 111:     return false;

 112:     }

 113:     else if (curHour >= 12 && sBreachDayName != "Friday")

 114:     {

 115:     alert("WARNING : it is too late to complete a Critical case today. Please reset the Priority level to the Next Working Day");

 116:     crmForm.prioritycode.focus(); 

 117:   return false; 

 118:     }

 119:   else if (curHour <= 12)

 120:     {

 121:     alert("Warning : This case must be completed by close of business today. You have until " + FriendlyDate(sBreachDate) + " to resolve this problem.");

 122:     crmForm.all.new_slabreachtime.DataValue = sBreachDate;

 123:     crmForm.new_sladate.value = FriendlyDate(sBreachDate);

 124:     return false;

 125:     }

 126: //If the sPriority is Escallate then exit proceedure....

 127: else if (sPriority == 0)

 128:  {

 129:  return false;

 130:  }  

 131: }//end if/else

 132:  

 133:  

 134: //what to do if there are no exceptions

 135:   alert("Success! You have : " + sHour + " hours to complete this case, You must finish by : " + FriendlyDate(sBreachDate));

 136:   crmForm.all.new_slabreachtime.DataValue = sBreachDate;

 137:     crmForm.new_sladate.value = FriendlyDate(sBreachDate);

 138:   return false;

 139:  

 140:  

 141: function slabreachtime(targethour){

 142: //Function to calculate the breach time of the Case SLA

 143: var oneMinute = 60 * 1000  // milliseconds in a minute

 144: var oneHour = oneMinute * 60

 145: var oneDay = oneHour * 24

 146: var oneWeek = oneDay * 7

 147:  

 148: var today = new Date()

 149: var dateInMS = today.getTime() + oneHour * targethour

 150: var targetDate = new Date(dateInMS)

 151:  

 152: return targetDate;

 153:  

 154: }

 155:  

 156:  

 157: function recalcDate(targethour,today){

 158: //Function to calculate the breach time of the Case SLA

 159: var oneMinute = 60 * 1000  // milliseconds in a minute

 160: var oneHour = oneMinute * 60

 161: var oneDay = oneHour * 24

 162: var oneWeek = oneDay * 7

 163:  

 164: var dateInMS = today.getTime() + oneHour * targethour

 165: var targetDate = new Date(dateInMS)

 166:  

 167: return targetDate;

 168:  

 169: }

 170:  

 171:  

 172: //----------------------------------------------------------------->

 173: //Functions controlling date/time conversions

 174:  

 175:  

 176: //Date Time conversion from UTC to Friendly Format

 177: function FriendlyDate(today){

 178: var Days = new Array('Sunday','Monday','Tuesday','Wednesday',

 179:     'Thursday','Friday','Saturday');

 180:  

 181: //var today = sBreachDate;

 182: var Year = takeYear(today);

 183: var Month = leadingZero(today.getMonth()+1);

 184: var DayName = Days[today.getDay()];

 185: var Day = leadingZero(today.getDate());

 186:  

 187: var Hours = leadingZero(today.getHours());

 188:  

 189:  

 190:  

 191: var Minutes = leadingZero(today.getMinutes());

 192: var Seconds = leadingZero(today.getSeconds());

 193:  

 194: //Now assign the cleaned breach date/time to a variable for use

 195: var FriendlyBreachDate = Hours + ':' + Minutes + ':' + Seconds + ' '

 196:     +  DayName + ' ' + Day + '-' + Month + '-' + Year

 197:  

 198: return FriendlyBreachDate;

 199:     

 200: }    

 201:     

 202: function takeYear(theDate)

 203: {

 204:     x = theDate.getYear();

 205:     var y = x % 100;

 206:     y += (y < 38) ? 2000 : 1900;

 207:     return y;

 208: }

 209:  

 210: function leadingZero(nr)

 211: {

 212:     if (nr < 10) nr = "0" + nr;

 213:     return nr;

 214: }

4) 7 new workflows attached to the Cases entity. These will do the real work for you within the CRM. I have named my workflows in the following way according to the values in the 'prioritycode' attribute and each one is specific to that. They are :

• Check Case Priority - self explanatory
• Case Priority ESLA Breach - (Priority = SLA Breach)
• Case Priority 4HR - (Priority 1 = critical, 4 hours)
• Case Priority NBD - (Priority 2 = Next Business Day)
• Case Priority 13D - (Priority 3 = 1 to 3 business days)
• Case Priority 35D = (Priority 4 = 3 to 5 business days)
• Case Priority 30D = (Priority 5 = 30 days plus)

4) The values of the 'prioritycode' attribute should be the following :

   1: <select name="prioritycode">

   2: <option value="0">Escalate - SLA Breach</option>

   3: <option value="1">Critical - 4 hours</option>

   4: <option value="2">Next Business Day</option>

   5: <option value="3">Non Urgent - 1 to 3 B/Days</option>

   6: <option value="4" >To Do - 3 to 5 days</option>

   7: <option value="5">Scheduled Task - 30 days</option>

   8: </select>

The above code is a HTML representation of what the CRM select box looks like.

Explanations

The idea is to calculate the SLA Breach date and time programmatically using Javascript and then paste the resulting value into the 'new_sladate' and 'new_slabreachtime' attributes on the cases form. Once this value has been established within the CRM, we can get the workflows to reference it and to perform actions based on it.

Dates are easy enough to call from within the code using the Date() function, but if you really want it to do something for you, you need to take into account the resulting problems....

Scenario A : The helpdesk agent raises a case with a priority of 4 hours at 16:30.

Result : Since the helpdesk does not work past 17:00, raising a case with a priority of critical with only 30 minutes left in the day is pretty useless. We need to stop this happening. The program could refuse to log the case since it is outside of working hours, but this defeats the object of the exercise. What we need is for the script to recognise this scenario and 'advance' the SLA to the next available working day but retain the 'Critical' status so that the helpdesk agents are immediately aware of the situation when they next come into work. In reality, a critical case would probably be handled that same day no matter what the time, but lets assume that the helpdesk are clock watching or working to rule.

Scenario B : The helpdesk agent raises a case with a priority of 1-3 days on a Wednesday afternoon. The SLA Breach time would therefore fall on a Saturday when the helpdesk is unavailable.

Result : The SLA is breached on a Saturday when no-one is available. Again, the date needs to be advanced to compensate.

None of these results are exactly what we need, so the code listed above will take care of these possibilities. Once the code has determined the breach date, it will be easy to make our workflows respond to these cues in the proper way.

Special Note on pasting dates into fields

We can paste our resulting date into 'new_slabreachtime' if the attribute were set to nvarchar. This is fine. But the CRM wont recognise it as a date and you wont be able to leverage the workflows using it. We need the new_slabreach time to be a 'date/time' field. This being the case, the date that you paste must be the raw UTC date as opposed to the friendly human converted date we paste into 'new_sladate'. Thus, the syntax to use when pasting into a date/time field would be :

   1:  crmForm.all.new_slabreachtime.DataValue = sBreachDate;

NOT

   1:  crmForm.new_slabreachtime.value = FriendlyDate(sBreachDate);

 

 

That being the case, the workflow will now recognise the field as a date and you can now set a checkcondition to find out if the value in 'new_slabreachtime' has been passed or not.

Workflows : Explanations

The workflows are an integral part of the SLA breach/check procedure. The first, CheckCasePriority checks the value in the 'prioritycode' attribute and determines which workflow to run. This is keyed to the 'new case' event. You could also make it run depending on whether prioritycode changes, but this would re-set the SLA breach date. Possible, but not what I want at the moment.

The CasePriority(x) workflows consist of instructions for the CRM on what to do for that case once the priority has been set. The first instruction on the workflow should be a 'wait' condition keyed to the 'new_slabreachtime' date/time field we have already discussed. My workflow will alert the service desk when there is one hour to run before breach. You can add various other conditions in here if you like such as 'raise an activity' or synchronous workflow to do something else whilst you are waiting.

The CasePriorityESLABreach workflow is a set of conditions to fulfil should the SLA be breached. In this case, a combination of check and wait conditions will result in the CRM sending warning emails to the service desk at 1,2 and 3 hours post breach.

Final Improvements

I want the service desk to view cases according to priority. This is very simple, just sort the apropriate view according to the 'priority' level.

I want the service desk to be able to view the SLA breach time in the 'view'. This is also very simple. Just add the new_sladate' attribute to the view matrix.

Hope this has been useful....

Can CRM Modules be renamed

Yes!

Thanks to Umar Khan

Another cool feature of Dynamics is the ability to rename the modules shown on the left navigation bar of the main CRM application window. All you need is the the sitemap XML file.

We could change the 'Service' module name to 'Helpdesk'. Here are the steps :

• Settings -> Customizations -> Export Customizations
• Select Sitemap from the list of exportable entities
• Click on "More Actions" and then "Export Selected customisation"
• Click OK on Jscript alert
• Save the customisation file.
• Back up the existing customisation file.
• Open the file for edit in XML Notepad 2007 

Step Two : Find the following line :

   1: <Area Id=”CS” ResourceId=”Area_Service” Icon=”/_imgs/services_24×24.gif” 

   2: DescriptionResourceId=”Customer_Service_Description”>

• Add Title = "Helpdesk". After the addition, the new line will look like the following :

   1: <Area Id=”CS” Title=”Helpdesk” ResourceId=”Area_Service” Icon=”/_imgs/services_24×24.gif” 

   2: DescriptionResourceId=”Customer_Service_Description”>

 

• Save the customization file
• Go to Settings -> Customization -> Import Customization
• Browse to the saved sitemap file and upload it
• After the upload is completed, click on "Import all Customizations"
• Refresh the browser

Fini.

Displaying Related Records in an IFRAME

One of the biggest things that customers like seeing is related records. You can display related records within an IFRAME with very little programming experience.

In the following example, I will display the Activity Records for a Lead directly within an IFRAME on the main account form.

Step One : Open the Lead Form in the 'Customizations' editor and add a section called 'Activity History' and display the label. Add an IFRAME named 'ActivityHistory' (e.g IFRAME_ActivityHistory). Make the URL about:blank and make sure that the 'pass record object-type code and unique identifier as parameters' box is checked. Clear the 'restrict cross frame scripting' check box option and save.

Step Two : Click the Form properties and click the 'onLoad' event. Add the following script :

   1: //script to display activity history

   2: var CRM_FORM_TYPE_CREATE = 1;

   3: if (crmForm.FormType == CRM_FORM_TYPE_CREATE)

   4: {

   5:  document.all.IFRAME_ActivityHistory.src="about:blank";

   6: }

   7: else

   8:     {

   9:     var navActivityHistory;

  10:     navActivityHistory = document.all.navActivityHistory;

  11:     if (navActivityHistory != null)

  12:     {

  13:      document.all.IFRAME_ActivityHistory.src="/sfa/leads/areas.aspx?oId=" + crmForm.ObjectId + "&oType=4&security=852023&tabSet=areaActivityHistory";

  14:     }

  15:     else

  16:     {

  17:      alert("navHistory Not Found");

  18:     }

  19:     

  20: }

Step Three : Click 'Event is enabled' and then click ok twice.

Step Four :  Save the form and publish the Lead entity.

This code will work for any related records. Every time the Lead opens, it fires the OnLoad event which checks for the related records for the Lead.

Obligatory Warning : This type of customisation is not officially supported by Microsoft but it is a pretty small change and will probably not have much impact on future updates, hotfixes or upgrades. You should make a careful note of every structural change you make to the CRM for future reference.

Just in case you missed it, here is what the original Lead Form looks like before the customizations :

Notice that the 'Description' input box has been removed and the IFRAME put in it's place. Personally, I dont think the description box is entirely necessary in this place because there is ample information on the rest of the form, so, delete at will.

Fini.

Show EntityID (GUID) as temporary field on Form

It is possible that a customer would like to have the GUID of the account record actually display on a form. Obviously, you really dont want them to have write access to the information, but I really dont see the harm in having read access.

Step One : Get the EntityID information on a Form

This is embarrassingly simple. Just use the crmFormSubmitId containing the Primary Key information.

Step Two : Display the information in the Form

We need a place to actually put the GUID information once we have it and in CRM 4.0, we cant just have a blank text field into which to paste the information at runtime. What we need is a new blank attribute under Accounts called 'new-custguid'.

Step Three : Add this new attribute to the Form so it will display

Place the new attribute on the form

Step Four : Make a new onload event for the Form and paste the following code into it :

document.all.new_custguid.value = document.all.crmFormSubmitId.value;

Step Five : Save and publish the form. Now, when you open it under customer accounts, you will see the following :

Done.

Updating Subject Trees

Create or edit a subject

Required security role: This task requires the CSR Manager, System Customizer or System Administrator security role or equivalent privileges.

1. In the Navigation Pane, click Settings.

2. Under Settings, click Settings. Then, in the Settings area click Subjects.

3. Under Common Tasks, click Add a Subject.

–   OR –

In the Subject Tree, select a subject, then under Common Tasks, click Edit Selected Subject.

4. In the Subject dialog box, enter information or observe any noted restrictions or requirements as needed:

· Title
Enter a name for the subject. This is a required field.

· Parent Subject
You can click Lookup to search for and select a parent subject for the new subject.
Leave the Parent Subject box empty if you want the new subject to be a parent subject.

· Description
Enter a descriptive statement about the subject.

5. Click OK.

Unknown Error (0x80005000)

During a quiet installation run from a setup.xml file and the command line, you might received this error message.

"Unknown Error (0x80005000)"

Solution

Install and configure Internet Information Services (IIS) and then run Setup again...

Done.

Install Microsoft Dynamics CRM Server

One of the things I like about Dynamics is that you can install various modules of it across several different servers in order to provide load balancing capabilities. Essentially, there are 2 platforms associated with CRM server :

1) Application Server Role Group

2) Platform Server Role Group

Each of these two server role groups comprise various Server Roles such as the following:

a) Applications Server (AppServer)

b) Dynamics CRM Asynchronous Processing Service (Async)

c) Dynamics SDK Server (SDKServer)

d) Deployment Service (DeploymentService)

e) Discovery Service (DiscoveryService)

f) Help Service (HelpServer)

Because the Deployment Service (in production multi-tenanted environments) should be installed on a completely different server box and physically isolated from the rest of the server roles, the only way to complete this is to alter the installation XML file (setup.xml) and then run the install from the command line. This will allow you to install the server roles that you want to on the box of your choice rather than settling for a standard installation.

The XML file should look something like this :

   1: <?xml version="1.0" encoding="utf-8" ?>

   2: <CRMSetup>

   3:   <Server>

   4:     <Patch update="true">\\server\share\patchfile.mconsolidatedmessenger</Patch>

   5:     <LicenseKey>XXXXX-XXXXX-XXXXX-XXXXX-XXXXX</LicenseKey>

   6:     <SqlServer>SQLServer</SqlServer>

   7:     <database create="false" />

   8:     <WebsiteUrl create="true" />

   9:     <InstallDir>c:\Program Files\Microsoft CRM</InstallDir>

  10:     <Roles>

  11:       <Role name="AppServer"/>

  12:       <Role name="Async" />

  13:     </Roles>

  14:     <SQM optin="true" />

  15:     <CrmServiceAccount type="DomainUser">

  16:       <ServiceAccountLogin>login</ServiceAccountLogin>

  17:       <ServiceAccountPassword>password</ServiceAccountPassword>

  18:     </CrmServiceAccount>

  19:   </Server>

  20: </CRMSetup>

Note the Role Name attributes. You should in fact have two XML documents ready, one that installs the Deployment Service on one computer and the other that installs all the other roles on your other Server box. Note also the use of 'AppServer' for Application Server etc.

Special Note : XML files should be in American English, they wont work in UK English so pay attention to any 'Americanizations'

Once you have completed all of the configurations that are possible with an 'un-attended' installation, you should have an XML file that looks like this :

   1: <?xml version="1.0" encoding="utf-8" ?>

   2: <CRMSetup>

   3:   <Server>

   4:     <Patch update="true">\\server\share\patchfile.mconsolidatedmessenger</Patch>

   5:     <LicenseKey>XXXXX-XXXXX-XXXXX-XXXXX-XXXXX</LicenseKey>

   6:     <OU>OU=CRM, DC=mySubDomain, DC=MyDomain, DC=com</OU>

   7:     <SqlServer>SQLServer</SqlServer>

   8:     <database create="true" />

   9:     <WebsiteUrl create="true" />

  10:     <InstallDir>c:\Program Files\Microsoft CRM</InstallDir>

  11:     <Organization>Syscomm Ltd</Organization>

  12:     <OrganizationUniqueName>Syscomm</OrganizationUniqueName>

  13:     <basecurrency isocurrencycode="GPB" currencyname="UK Pound" currencysymbol="£" />

  14:     <Email>

  15:       <IncommingExchangeServer name="SERVERNAME" />

  16:     </Email>

  17:     <SQM optin="false" />

  18:     <Roles>

  19:       <Role name="AppServer"/>

  20:       <Role name="Async" />

  21:       <Role name="SDKServer" />

  22:       <Role name="DiscoveryService" />

  23:       <Role name="HelpServer" />

  24:     </Roles>

  25:     <SQM optin="true" />

  26:     <CrmServiceAccount type="DomainUser">

  27:       <ServiceAccountLogin>Administrator</ServiceAccountLogin>

  28:       <ServiceAccountPassword>Password</ServiceAccountPassword>

  29:     </CrmServiceAccount>

  30:     <ifdsettings enabled="true" />

  31:     <internalnetworkaddress>IPAddress - SubnetMask</internalnetworkaddress>

  32:     <rootdomainscheme>https</rootdomainscheme>

  33:     <sdkrootdomain>servername.domain.com</sdkrootdomain>

  34:     <webapplicationrootdomain>servername.domain.com</webapplicationrootdomain>

  35:   </Server>

  36: </CRMSetup>

Running Setup From the Command Line

Now that you have the XML files that you will use to install the server roles on the different boxes, you will need to actually install Dynamics.

You will need to use the following command :

   1: SetupServer.exe [/Q] [/InstallAlways] [/L [drive:][[path] logfilename.log]] [/config [drive:] [[path] configfilename.xml]]

SetupServer.exe used without the parameters will install using the standard setup wizard.

Parameters :-

/Q

Quiet mode installation. This parameter requires a configuration file in XML format. The /config parameter contains the name of the XML configuration file. No dialog boxes or error messages will appear on the display screen. To capture error message information, include the log file parameter (/L).

/InstallAlways

This parameter forces Setup to ignore the installation state and operate in install mode. When you use this parameter, Setup will try to install on a server where Microsoft Dynamics CRM is already installed.

/QR

Requires a configuration file in XML format specified by the /config parameter. Displays installation progress bars and all error messages.

/L [drive:][[path] logfilename.log]]

Creates a log file of installation activity. You can specify the file name of the log file and where to put it. If you do not specify a name or location, a log file will be created in the Drive:\Documents and Settings\\UserName\Application Data\Microsoft\MSCRM\Logs folder, where UserName is the account name of the user running Setup. The following options are available:

/LV  Log verbose.

/L*   Log all information except verbose.

/L*V Log all information including verbose.

/config [drive:] [[path] configfilename.xml]]

The /config parameter uses the specified XML configuration file to provide Setup with the additional information to complete installation successfully.

Update to Custom Entities

OK. I admit it. I'm impressed.

After so many years of being promised so much from Microsoft, they've finally delivered. In my previous post, I told you have to add custom options to a pick list (or option box as they are called in HTML) by editing the XML document directly. Well, yes, you can do it that way but there is a rather easier way of doing exactly the same thing.

1) Go to 'Settings' and then Customizations

2) Click on Customize Entities to get the list

3) Choose the Entity that you want to change (in this instance, Cases)

4) Choose 'Attributes' from the left hand pane.

5) Double click on the 'Priority of Case' Link and you will see the pick list attributes screen

6) Customise away!

As I said, I'm impressed. No more faffing around in the code trying to do something which is essentially very simple. I'm not saying that you dont need to know what you are doing, because you do, but still, that is allot easier than messing around with formatted XML.

Good job Microsoft (now if you dont mind, I'm going to go shoot myself )

Customising Entity Forms

So, how exactly do you customise the option boxes? Well, I have a requirement to make the CRM behave as a full fledged support ticketing system and one of the problems is that the default options for the ‘Priority’ level are just not good enough. The default settings are ‘High’, ‘Medium’ and ‘Low’ but I wanted to add a few more (in this case, just for fun and to see if I could). So, how did I do it? Well, it’s pretty simple really but like most things, the potential for disaster is phenomenal.

So, the watchwords for today are ‘backup’ and ‘proof read before you save’.

The forms in Dynamics are generated using xml and this xml file can be altered.

1)       Go to the Customizations tab under Settings and choose ‘Export Customizations’.

2)       Choose the entity you want to export (in this instance, cases)

3)       Export the file.

4)       You will have a zip file saved. DON’T DO ANYTHING.

5)       Take a copy of the zip file and put it somewhere very safe.

6)       No, unzip the original file and inside, you will find ‘Customizations.xml

Open the file with your favourite editor and find the attribute that you want. In this case, ‘Priority’.

   1:  <attribute PhysicalName="PriorityCode">

   2:   

   3:                <Type>picklist</Type>

   4:   

   5:                <ValidForCreateApi>1</ValidForCreateApi>

   6:   

   7:                <ValidForUpdateApi>1</ValidForUpdateApi>

   8:   

   9:                <ValidForReadApi>1</ValidForReadApi>

  10:   

  11:                <AttributeTypeId>00000000-0000-0000-00aa-110000000030</AttributeTypeId>

  12:   

  13:                <DisplayMask>QueueItemPriority|ValidForAdvancedFind|ValidForForm|ValidForGrid</DisplayMask>

  14:   

  15:                <Descriptions>

  16:   

  17:                  <Description description="Priority of the case." languagecode="1033" />

  18:   

  19:                </Descriptions>

  20:   

  21:                <ImeMode>auto</ImeMode>

  22:   

  23:                <RequiredLevel>none</RequiredLevel>

  24:   

  25:                <Format />

  26:   

  27:                <AppDefaultValue>2</AppDefaultValue>

  28:   

  29:                <options>

  30:   

  31:               <option value="1">

  32:   

  33:                    <labels>

  34:   

  35:                      <label description="Super High" languagecode="1033" />

  36:   

  37:                    </labels>

  38:   

  39:                  </option>

  40:   

  41:                  <option value="2">

  42:   

  43:                    <labels>

  44:   

  45:                      <label description="Medium" languagecode="1033" />

  46:   

  47:                    </labels>

  48:   

  49:                  </option>

  50:   

  51:                  <option value="3">

  52:   

  53:                    <labels>

  54:   

  55:                      <label description="Normal" languagecode="1033" />

  56:   

  57:                    </labels>

  58:   

  59:                  </option>

  60:   

  61:                  <option value="4">

  62:   

  63:                    <labels>

  64:   

  65:                      <label description="Low" languagecode="1033" />

  66:   

  67:                    </labels>

  68:   

  69:                  </option>

  70:   

  71:              <option value="5">

  72:   

  73:                    <labels>

  74:   

  75:                      <label description="Sub Basement" languagecode="1033" />

  76:   

  77:                    </labels>

  78:   

  79:                  </option>

  80:   

  81:                </options>

  82:   

 

As you can see, all you have to do is copy and paste a new block with the appropriate values. Save the file and then using the same route through the Settings/Customizations tab, import it back into the CRM.

Finally, go to ‘Customize Entity’, find the entity you have just changed (cases) and then choose ‘Publish’ from the ‘Actions’ drop down. Voila!

Notes on the Installation of the Email Router

There are several very good blog posts out there giving a general overview of the Email Router. Having just installed it myself on our Exchange server, I can say that the instructions seem straight forward but still it took myself and a sysadmin over 4 hours to get it to work. It’s a bit like the naughty girl in fairytales…”when she was good she was very very good, but when she was bad, she was horrid…”

Still, it IS working and now it’s time to add a few thoughts of my own to the blogsphere regarding this blackmagic.

First of all, when you first install the email router component you are presented with two options which are :

a)       Update installation files (strongly recommended)

b)       Do not update installation files

We discovered that if you checked the ‘highly recommended’ option, the install would invariably fail. We never did get to the bottom of it but I suggest that you use option B instead. It seems to work.

Secondly, the ubiquitous ‘No Visual C++ Runtime Environment installed’ warning comes up again and again. Microsoft, please fix this! It’s not a big thing but when you are in a hurry and you know you have just downloaded and installed this component not five minutes before, it’s extremely irritating.

Just a warning note to the unwary though. Before installing the Email Router, you should ensure that MAPI (exchangemapicdo.exe) is installed or the Router installation will fall flat on it’s face – again….

It should also be noted that neither myself nor my Sysadmin were at all sure that this email router would work cross-domain. For instance, MyCompanyLtd host a CRM system for TheClientLtd, but TheClientLtd would like to use their own Exchange server for emails. Happily, the answer is that it will. In the Microsoft CRM Dynamics Deployment screen, you should set the following criteria….

a)       Deployment = My Company (option 1)

b)       Dynamics CRM Server = http://<CRMserverName>/<BusinessName>

c)       Access Credentials = Other

d)       User Name = <domain>\<Superusername eg Administrator>

e)       Password = password for Administrator account

f)         Profiles = In / Out

For option point ‘B’, you should be careful to enter the BusinessName exactly as it appears in your CRM installation. Apparently, it is case sensitive. If you are unsure, you can (carefully) check the SQL installation and run the following query :

   1: SELECT Name FROM dbo.OrganizationBase

Now, all you need to do is set the appropriate forwarding boxes and rules in the Outlook Client and hey presto, you’ve got mail.