This is a common scenario which can be easily covered with some simple JScript in the opportunity form. However I found out that in some circumstances, an opportunity could still be created for a contact, thus violating the requirement and even worse, breaking some of the implemented processes and business logic. Here is how I fixed this issue.

Background

In a default Dynamics CRM implementation, customers can either be accounts or contacts. When creating a record that can be bound to either an account or contact such as an opportunity, the customer field is bound to a virtual composite entity where either an account or a contact is valid. Thinking from a database perspective, there is no customerid column in the opportunities table, because there is no customer entity on the system. There is, however, an accountid column and a contactid column. When the record is saved, either accountid or customerid will be filled with a link to the respective record, depending whether if the user specified an account, or a contact.

A simple JScript?

A simple way to avoid users from selecting a contact as a potential customer for opportunities is through the use of a JScript bound the form’s onLoad event. Here is an example:

function FilteredCustomerLookupAccount(customerField) {
var CRM_FORM_TYPE = Xrm.Page.ui.getFormType();
if (CRM_FORM_TYPE == 4 || CRM_FORM_TYPE == 3) { return; }

//Limit the entity lookup choice to Account
document.getElementById(customerField).setAttribute("lookuptypes", "1");
}

Make sure to pass the name of the customer field between quotes as a parameter when calling the function. In the case of the Opportunity’s form, you should specify 'customerid'.

This should do the trick, right? Well, yes; if opportunity records are being created and edited through the form that contains such JScript. But this script takes no effect if an opportunity record is created through another context, thus bypassing this JScript. For example, if the user creates a record using the Mobile Express forms, or a third party client or solution that creates the record through the web service of Dynamics CRM.

Even if you have disabled Mobile Express forms and no one uses a third party client to create records in Dynamics CRM, there are still cases where the Jscript above could be bypassed.

Update: Don’t forget the Opportunities link in the Contact’s form
As Adam V mentioned in the comments section below, make sure that you remove the link to Opportunities from the left navigation pane of the Contact forms. Since any CRM platform is all about relationships between different entities, it is important to consider both ends of the relationship tether when performing such type of customisations.

Activities: The agent provocateur

When a user converts an activity to an opportunity, the record specified in the Recipient field of the activity will become the Potential Customer of the opportunity that is created. Therefore if the user specified a contact as the recipient of the activity, the opportunity will be bound to the contact. This is because the opportunity record is created and then saved when the user converts the activity to an opportunity, thus bypassing the JScript to disallow contacts.

Solution – part I: Workflow

The first part of my solution involves a workflow. In this Dynamics CRM implementation, a contact must be bound to a parent account, and it must be an account. That is, the above JScript used to block the selection of contacts is also bound to the onLoad of my Contact form.

So what I did is to create a workflow for the Opportunity entity that checks for the condition Opportunity:Potential Customer equals [Potential Customer (Contact):Contact] (that is, if the opportunity is bound to a contact). If it is bound to a contact, then it will change the customer from the current contact to {Parent Customer(Potential Customer (Contact))}, which is effectively the contact’s parent account.

Because an opportunity record created outside the scope of its form will bypass all JScripts, it not only bypasses the blocking of contact selection, but also any other business logic I might have in any other JScript. Therefore my workflow also checks for empty fields that shouldn’t be empty, and set some default values.

Solution – part II: JScript

The problem with workflows is that although they are useful, they are an asynchronous, background process. Therefore the user wouldn’t get any sort of feedback of what is going on. In order to resolve this, I added a second JScript to the onLoad event of my Opportunity form, as follows:

function setOpAccountPerContact() {

	var CRM_FORM_TYPE = Xrm.Page.ui.getFormType();
	if (CRM_FORM_TYPE != 2) { return; }

	if(Xrm.Page.getAttribute("customerid").getValue()!=null) {
		if(Xrm.Page.getAttribute("customerid").getValue()[0].typename=="contact") {
		alert ("This opportunity is bound to a contact. The relationship will automatically change for the contact's parent account.");

		var idCustomer = Xrm.Page.getAttribute("customerid").getValue()[0].id;
		var retrieveRecordsReq = new XMLHttpRequest();
		var ODataPath = Xrm.Page.context.getServerUrl() + "/XRMServices/2011/OrganizationData.svc";

		retrieveRecordsReq.open('GET', ODataPath+"/ContactSet(guid'" + idCustomer + "')",false);
		retrieveRecordsReq.setRequestHeader("Accept", "application/json");
		retrieveRecordsReq.setRequestHeader("Content-Type", "application/json; charset=utf-8");
		retrieveRecordsReq.send();

		var records = this.parent.JSON.parse(retrieveRecordsReq.responseText).d;

		var lookupValue = new Array();
		lookupValue[0] = new Object();
		lookupValue[0].id = records.ParentCustomerId.Id;
		lookupValue[0].name = records.ParentCustomerId.Name;
		lookupValue[0].entityType = "account";
		Xrm.Page.getAttribute("customerid").setValue(lookupValue); 

		}
	}
}

The above script will check if the opportunity is bound to a contact as the potential customer. If that is the case, it will inform the user through an alert, and it will proceed to change the Potential Customer field from the current contact to the contact’s parent account.

Wrapping up

When users convert an account to an opportunity for a contact and the option to open the new opportunity is selected, the users will receive an alert, and they will see the Potential Customer field change its value to the related account record. Even if the user doesn’t save the change performed by the JScript, the workflow will replace the Potential Customer value with the related account.

The JScript provides users with the visual, client-side aid, while the workflow is our catch-all in the lookout for any discrepancy in the system.

There is no way I could have done this solution without the help of Mahender Pal, a Dynamics MVP from India who helped me out with the JScript part of the solution. Thank you Mahender!

Today I would like to expand further on that discussion and talk about an often neglected entity in Dynamics CRM: The Address entity and its importance in every single Dynamics CRM deployment out there (yes, including yours).

Address fields in customer entities: Isn’t that enough?

Let’s have a look at Accounts and Contacts (i.e.: the customer entities) in Dynamics CRM. These entities already contain address fields which are used to capture address information for a customer record. Consider the following screenshot of a default, “vanilla” form for the Account entity:

The above example illustrates most of the default address related fields available for an Account entity (note that the same fields are available for contacts). If you look at the fields available for the entity however, you will notice that there are many more address related fields available. There are two instances for each address-related field, each starting with the prefix address1 or address2, with forty six fields in total. A customer record could potentially store information about two different addresses.

Therefore, most people then consider unnecessary the use of the Address entity, and tend to neglect it completely when customising Dynamics CRM. The problem is that the Address entity is alive and kicking.

Hidden address records

I invite you to perform an Advanced Find in a deployment of Dynamics CRM containing data to look for Address records. Just click on Advanced Find to open the Advanced Find dialog, then where it says Look For, select Addresses. Make sure that where it says Used Saved View, the option [new] is selected. Then click on the Results button at the ribbon to execute the search query.

Well, I never created address records in this implementation of Dynamics CRM. So where did all these addresses came from?

Here is the kicker. Every time you create a new account or contact, the system creates two address records which are related in a parental relationship with the customer record: One address record containing the information populated in the address1 fields of the customer record, and a second address record containing the information populated in the address2 fields of the customer record. Every time you modify the address within the customer record, it updates the related address record and vice-versa.

Now if you try to find these address records by navigating through More Addresses when viewing a customer record, you wouldn’t find them; but you would find the address records you have manually created for the customer record. The reason being is that there is a filtered view in the Address entity, as to only show address records were the field Address Number is greater than 2 (which are the ones created by the users).

Therefore for the purpose of mail merge, Dynamics CRM relies on the address records, not on the address fields contained in the customer record. Furthermore, this entity is quite useful when integrating Dynamics CRM with ERP systems, such as Dynamics NAV. Therefore it is extremely important that when customising the addresses in Dynamics CRM that the Address entity is not neglected.

Considerations when customising address information

Although these two hidden address records are automatically created whenever a customer record is created, this isn’t a process that can be easily customised. There isn’t a workflow in the system that can be configured to consider custom address fields and to make things worse, field mappings between address and accounts and contacts can’t be configured either.

The truth about Address1 and Address2 fields: As Adam Vero explained in the comments section below, and I quote: “The addresses are NOT stored on Account and Contact records at all, they just look like they are, which is why you can’t map anything with the Address records – the fields are really on the Address entity anyway and simply shown on the Account or Contact for ease of use and simplicity of building queries, workflows etc.”

These limitation reinforce not only the points I raised in my previous article concerning address fields, but also some points I raised when creating a custom Country/Region field.

Always make sure that the default address fields are populated, even when using custom fields. For example, if you replace the default Country/Region text field for Accounts and Contacts (also Competitors and Addresses), make sure that you still populate the default Country/Region text field, either through JScript or through a workflow. This will ensure that all address information captured in the customer record is passed on to its related address records.

In other words: Consider your custom address fields simply as controls that must pass their values to the default address fields.

Also, since there are limitations on the field mappings between the Address entity the Account and Contact entity, it is not wise to allow users to edit those hidden address records if have replaced or added new address fields. One way to avoid this is to set a JScript on the onLoad of the Address form so it disable (or even hide) its fields if the value of the Address Number field is equal to either 1 or 2, which are the values of the two hidden address records for a given customer. You could even add an alert (a message box popup) when the user tries to edit one of these records, explaining that the user should do it through editing the address fields within the customer record. This will avoid mismatches between the Address record and the address fields for a customer record.

If you want to disable all fields of the Address form, Andrew Zimmer from Avtex wrote an article on how to achieve this here. Here is a modified version of Adrew’s script that you could use:

// Add this script as a webresource and to the Address form
function doesControlHaveAttribute(control) {
    var controlType = control.getControlType();
    return controlType != "iframe" && controlType != "webresource" && controlType != "subgrid";
}

function disableFormFields(onOff) {

    Xrm.Page.ui.controls.forEach(function (control, index) {
        if (doesControlHaveAttribute(control)) {
            control.setDisabled(onOff);
        }
    });
}

//Call the following function on the Address form onLoad event
function disableAddressForm(){

    if (Xrm.Page.getAttribute("addressnumber").getValue() == 1 || Xrm.Page.getAttribute("addressnumber").getValue() == 2) {

           disableFormFields(true);
		   // We can also show an alert to help users out
		   alert("In order to edit this address record, please edit the address information of its related customer record.");

    }
}

However, since I have customised the Address form with custom fields just like I did with the Address fields for Accounts, Contacts and Competitors, I much rather hide the fields altogether because since there is no field mapping between the Address and Accounts and Contacts, the default addresses just look messy. We can achieve this by hiding the form sections with the following JScript, which I modified from Gareth Tucker’s JScript examples for Dynamics CRM 2011:

// Add this script as a webresource and to the Address form
function HideShowSection(tabName, sectionName, visible) {
    try {
        Xrm.Page.ui.tabs.get(tabName).sections.get(sectionName).setVisible(visible);
    }
    catch (err) { }
}

//Call the following function on the Address form onLoad event
function disableAddressForm(){

    if (Xrm.Page.getAttribute("addressnumber").getValue() == 1 || Xrm.Page.getAttribute("addressnumber").getValue() == 2) {

           HideShowSection("general", "customer address information", false);
		   HideShowSection("general", "phone numbers", false);
		   HideShowSection("general", "additional information", false);
		   // We can also show an alert to help users out
		   alert("In order to view or edit this address record, please refer to the address information stored in its related customer record.");

    }
}

Just remember that for these scripts to work, you would need to add the field Address Number hidden to the form since it is not there by default.

Also, instead of displaying an alert, we could add an HTML web resource to the Address hidden by default with some instructions or information on disabled forms, and show this web resource based on the value of the Address Number field.

Bonus: Avoiding empty address records with workflows

When populating address information for accounts and contacts, many users (and I include myself in this generalisation) often disregard the Address Name and Address Type fields. In fact it is common for clients to request these fields to be removed altogether from the forms. However since two address records are going to be created no matter what, we end up with nameless address records in the Address entity, as per the third screenshot from the top bottom.

Normally this might not be an issue for many clients. However I got a client who often perform a lot of queries against the Address entity, and having to look through lots of address records without an Address Name and Address Type can make it difficult to find a record.

The solution is to create one workflow for the Account entity and another for the Contact entity for when a record is created, that automatically populates the Address Name and Address Type fields with some default information. In my case I populate address1_name with {Account Name (Account)} - Primary Address and address2_name with {Account Name (Account)} - Secondary Address. You could also set the value for address1_addresstypecode and address2_addresstypecode.

The workflow for the Contact entity would be similar, but using the contact’s full name instead for naming the address, such as {Full Name (Contact)} - Primary Address and address2_name with {Full Name (Contact)} - Secondary Address.

Make sure these workflows also run when their respective fields change (i.e.: Account Name for Accounts and Full Name for Contacts) in case the records are renamed. Finally, you could make these workflows run on demand in order to update all of your existing account and contact records.

To make things more interesting, here is the second part of the requirement: After a case correction has been performed in a field, it shouldn’t be performed again. So if the user now proceeds to type “JOHN” in the First Name field after the first case correction, the system should leave the case as it is.

Now, I am not saying that I agree with this requirement, but it is a requirement nonetheless. I make no secret that I am far from having the JScript knowledge I aspire for, so this was a good exercise for me and I hope the community can benefit from it.

This is an interesting solution because it covers the usage of global variables in JScript, function parameters and an array for individually controlling whether a field should have its case fixed or not.

1. The first step is to create a new JScript web resource for our Dynamics CRM solution. I called it new_SetTitleCase. Then paste the following code for the script:

// Let's start by declaring the Global variable outside the function. Feel free to name it _WhatEverYouFancy
var _i = null;

// This is the function we will call in the onChange event of a field. Make sure to pass the field Schema Name as a parameter (fieldName) when using the function
SetTitleCase = function(fieldName) {
  if ((_i != null) && (_i.indexOf(fieldName) >= 0))
    return;
  var CRM_FORM_TYPE = Xrm.Page.ui.getFormType();

  // If the form isn't of type 1 (Create Form) then stop the script
  if (CRM_FORM_TYPE != 1) { return; }

	var str = Xrm.Page.data.entity.attributes.get(fieldName).getValue();

	str = str.toLowerCase().replace(/\b[a-z]/g, function(letter) {
	return letter.toUpperCase();
	});

	Xrm.Page.getAttribute(fieldName).setValue(str);
		if (_i == null)
			_i = fieldName;
		else
			_i += "|" + fieldName;

}

2. Now while customizing the Contact form, click on Form Properties, then under Form Libraries within the Events tab we must add the new JScript we just created. Confirm all the changes and go back to the main Contact customization form.
3. Now double-click on a field we would like the Title Case to be enforced to. Within the Events tab, click on Add under Event Handlers to bind our JScript to the onChange event of the field.
4. In the Handler Properties dialog, make sure that the correct script is specified in Library selection. Type SetTitleCase as the value for the Function field, and then type the field schema name between quotes for the parameters field. For example 'firstname' for the First Name field.
5. Make sure to confirm all changes and publish the customizations.

There is no way I could have code this script by myself with my limited knowledge of JScript. Thanks to JBlaeske at the Microsoft forums for the help on this one!

Sure that downloading content from the comfort of your home is a convenient concept. But corporations are luring consumers to become cattle in a battery farm, where they milk consumers for their money to pay for services, but consumers hold no right to any goods. As consumers we don’t own anything but the limited right to consume content provided by these companies. So when we buy a song or a book, we don’t own a copy of the song or the book, but the limited right to play the song and read the book. If the corporation wishes to do so, they can pull out our right to such content.

The ultimate goal of the entertainment industry goes way beyond their claims to stop piracy. What they want is to remove from consumers any ownership claims over a copy of a record, movie or video game. Remember when we could go to a shop of used records to buy a hard-to-find album or movie? Well if it is up to the entertainment industry this will be a thing of the past. The first step is to remove the material objects out of the equation. How do they do that? By offering access to music, video and games as a service. However, “digital content as a service” is just one front of the entertainment’s industry war against consumers.

Even if we don’t subscribe to a service and instead buy records, movies and games individually, if we buy such content digitally, the content provider can ultimately revoke our rights to such content if we (allegedly) violate their terms and conditions (as ludicrous as they might be). But wait, there is more! Now the game industry is evaluating ways of taking this travesty one step further in the next generation of video game consoles by establishing an activation process between retail game copies (i.e.: physical “material objects” like a game disk or cartridge) and consoles. In practical terms this means that when you buy a game in a store, it will come with a code that must be activated against your video game console as to grant you the right to play that copy of the game with that console. So if you try to play that game in another console, the game will not load. Unless the video game industry finds its way to grasp their claws over the rental and second-hand games market, you can say goodbye to the renting and selling of used games. Even lending a copy of a game to a friend will be impossible. If this really happens with the next generation of video game consoles, I will proudly and openly condone all mods, hacking and tampering aimed to circumvent such system.

And now the software industry wants to join in as well. With Windows 8, Microsoft will also debut their new digital marketplace. Imagine being able to download and shop for apps and applications from one centralized location and having updates automatically pushed to your desktop. It sure sounds convenient (unless of course, this idea is against your political views). However, imagine a software you bought being pulled out of your computer automatically because you (allegedly) violated some obscure T&C agreement, or because “Microsoft doesn’t like it anymore”, or because “computer says no“.

Don’t get me wrong. I believe that musicians, artists and video game developers should be rewarded for their hard work and should hold their right to their material. My problem is with cartels like the RIAA and the MPAA. Our intellectual property laws are a failure, which allow big corporations to bully and push consumers around. If I buy a CD, a movie or a book, why shouldn’t I be able to sell it a a latter stage to someone else? Why should I buy two copies of a game if I want to play online against two different “regions” in the world? The answer is GREED.

However, if you’re planning to get a Windows Phone, prepare to have your rights as an EU citizen challenged by Microsoft.

Let me just say beforehand that Windows Phone is by far the best piece of smartphone hardware I had. In my view it is far — far superior than an iPhone or an Android phone. The problem isn’t with the phone’s hardware or the software, but with Microsoft’s draconian control of the phone’s ecosystem.

In order to purchase goods in the Windows Phone Marketplace, you require a Windows Live ID account. However, when you create a Windows Live ID account, the are certain details of the account that will be permanently bound to your current country of residence. I am talking about the account billing details.

Consider this scenario. John was living in France working as a contractor when he got his Windows Phone. He had to create a Windows Live ID to join the Windows Phone Marketplace, and so he did. He registered a payment card and even bought several apps for his phone. Well, now John moved back to the UK. And now he wants to change his payment details for a UK-based credit card.

Well, guess what. John can’t do that. Even if users update their Windows Live ID details at accounts.live.com and change their Country/Region to the country they are currently residents of, the Country/Region for billing information is disabled. Users will not be able to register a payment card (be it debit, credit or cash) from their new country of residence.

This means users will not be able to buy any new content with their existing Windows Live ID account using payment details from their new country of residence. Even though Microsoft operates around all EU member states. The only option suggest by Microsoft if for users that moved country to create a new Windows Live ID account. The inconvenience with this approach are enormous. Microsoft is seriously suggesting that EU citizens must have one Windows Live ID per country they lived in? For instance, in 10 years I lived in 4 different countries. And what digital rights management and all the content that users have acquired with their previous Windows Live IDs?

If you have a Xbox Live account prepare to add insult to the injury, because the same applies to Xbox Live content you might have bought, such as arcade games and add-ons. What gets me so disgruntled about this is that when I created my Windows Live ID ten years ago, I did so in order to join Xbox Live. Nowhere in their Terms and Conditions at the time I read that I would be forever bound to the country I was living in at the time. Since I created that Windows Live ID account I bought Xbox Live contents with it and used it for several other purposes, such as Microsoft Certifications. I use my current Windows Live ID for a lot of tasks and services. When I got my Windows Phone, I had NO IDEA that I would be bound to the Windows Phone Marketplace for the country which I was a former resident from when I signed in for Xbox Live.

What I found out is that by using certain prepaid Visa or MasterCard payment cards based in the country my Windows Live ID is bound to, I can in some cases by-pass Microsoft’s enforcement. The idea is that I can top-up my foreign prepaid card (from the same country where my Windows Live ID account is tethered to) with my local debit or credit card. However, Microsoft doesn’t like that and try to block the use of prepaid cards saying that they aren’t supported; which is puzzling, since they are getting paid for their content through legitimate means anyway, so what is the fuzz all about? Also, prepaid cards tend to charge customers for topping up their cards and/or an annual fee, and/or a transaction fee…

Bottom line: If you are an EU citizen that enjoy your freedom of movement in the continent and want to get a smart phone with a choice of services and apps, think twice before getting a Windows Phone. Same applies to Xbox Live content.

And it is about to get worse with Windows 8: Geoff Coupe wrote an article about this issue at his blog, and how it is likely that all this grievance will extend to Windows desktops with the upcoming Windows marketplace in Windows 8. You can read all about it here.

And here are my subsequent thoughts about it.

Get involved: For more information about this issue and how you can get involved to demand a change, visit www.itisourdata.com.

This often raises the question of JScript versus workflows when customising Dynamics CRM, particularly when designing a sales pipeline workflow. In this posts I explain how to combine the usage of both JScript and workflows in order to get the best of both worlds, and the most out of Dynamics CRM.

Overview

Dynamics CRM 2011 is a web-based application that uses a multi-tier architecture. This means that the Dynamics CRM platform serves as an intermediary between the client access users and the data. The application business logic sits in this intermediary bit, and this is where Dynamics CRM workflows are located. When a workflow is executed, it is executed at the server level, not at the client level (e.g.: Internet Explorer or Microsoft Outlook). JScripts on the other hand are interpreted at the client level.

Considerations

Consider my previous Sales Pipeline tutorial (see second post of the series). For the Opportunity record we added an option set (i.e.: a drop-down menu) where the user can select the stage of the sales pipeline for the opportunity is. The current sales pipeline stage, along with the user rating (e.g.: Hot, Warm, Cold) calculates the Probability for the opportunity record. We achieved this with the use of JScripts, which are quite handy since JScript provide users with an on-the-fly update. As the Pipeline Phase and Rating fields change, the Probability field is immediately recalculated.

However, since JScripts only work on main forms, this whole logic would be simply disregarded if the record is being edited through another method, such as through a mobile form , a web service call or a 3rd party client for tablet devices. How can we solve this issue?

About Mobile Express: Mobile Express is how Microsoft calls the mobile-friendly forms that can be used to access Dynamics CRM with mobile devices. Microsoft cleverly calls them “express” so they can argue that they are far from being a full-featured solution. So we must work around the limitations of these forms. Even though Microsoft calls them “express”, at the moment these mobile forms lack some fundamental functionality (such as disallowing users to edit records) so I am very reluctant to use them. I suggest you also avoid using them if you can.

Hacking Mobile Express: It is possible to modify the Mobile Express Cascading Style Sheet (CSS) files to hide the New, Edit and Delete buttons that would allow users to create or modify records bypassing any JScript you have. You can find the instructions on how to do it by at this forum post. Please bear in mind that this hack is NOT supported by Microsoft. Thanks to Nuno R Costa for the tip.

Consider now the workflows introduced in my Sales Pipeline tutorial (see third post of the series). If you look into the Sales Process workflow, you will notice that at every stage (1 - Prospect, 2 - Proposal, 3 - Negotiation) we wait for the Process Code (salesstagecode) field to change (which moves the workflow to its next stage). However the workflow doesn’t perform any actions.

Solution

The solution is to add an action at every stage to replicate the functionality of the JScript. Since workflows work at the server level, no matter what client or method was used to modify a record the workflow will be triggered as per its rules and its actions will take place. One might wonder if that is the case, then why bother with JScript at all. But remember when I said in the introduction of this post. JScript is all about enhancing the user experience, while a workflow works in the background, away from the user’s eyes. The issue, particularly for Dynamics CRM on-demand users, is to design a workflow using the built-in workflow designer and avoiding Visual Studio.

So let’s get back to the Sales Pipeline example. Consider the following screenshot of the Sales Pipeline workflow:

Notice that under each stage, between the lines Wait Until Opportunity:Process Code equals [...] and Otherwise, wait until Opportunity:Status equals [...] there is a line that says Select this row and click add step. This is because there are no actions being executed there. What we want to do is select this line at each stage, and add the appropriate actions to replicate the functionality of the JScript.

For example under the first stage (1 - Prospect) we would add an action to change the value of the Sales Pipeline field to 2 - Proposal. Moreover, we would need to add an additional wait condition to update the Probability field according to the option selected in the Rating option set. For more information on workflow conditional waiting, please refer to the third post of my sales pipeline tutorial.

Final Words

At first sight, if we could design a Dynamics CRM deployment that relies completely on workflows and no JScripts at all, it might seem as we could have a fail-proof business process. However the server-side nature of workflows at the platform layer makes them more linear and less receptive for situations in which users require a more dynamic response, such as on-the-fly calculations and conditional formatting of fields. When dealing with JScripts and workflows don’t start from the premise that you must choose either one of them, but how you can combine both of them. Finally, bear that JScripts only apply to browser-based forms (i.e.: Main Forms). In other words, all of your JScripts will be disregarded if a user manipulates data through Mobile Express forms, or through some sort of integration with another product.

The issue tends to surround the myth that countries and regions with different subdivisions would require complex requirements for address handling. I came across a couple of clients who believe that they require such a complex solution that their Dynamics CRM deployments almost came onto a halt because of it such hurdle. I the end, the solution relies not on complex customisation, but on standards compliance, a little bit of compromising, but most importantly: common sense.

What is the issue?

Well if you ask me, there is no issue. But here is the source of discord. Most countries and regions in the world (with the exception of some microstates) have constituent entities (i.e.: top-level subdivisions), which in different countries tend to carry different names. Here are four examples of countries and the name of their respective constituent entities:

• Germany – Federated States
• Uruguay – Departments
• Sweden – Counties
• Switzerland – Cantons

By default Dynamics CRM has the following fields to store address information:

• Address Line 1
• Address Line 2
• Address Line 3
• City
• State/Province
• Country/Region

Now let’s consider the chart below, which is a rough representation of how addresses are hierarchically defined:

Many customers tend to see as an issue that in Dynamics CRM the top-level constituency entity of a country or region is named as State/Province, gripping on arguments such as “but what if here in country X we use counties rather than states or provinces?” As a result, customers tend to add custom fields for specific subdivisions in hope to use them with the relevant countries/regions. However, consider the following cut-out (i.e.: resumed) diagram of client records in a database:

If we add fields for every possible subdivision we want to use, we will end up with a a plethora of unused fields for every account record we have. From the example above, although ACME is a company based in Germany (a country with federal states), even though we only need to use the state field for this account, the account record still has the fields for all other possible subdivisions we created (cantons, departments etc).

From an technical perspective this is a mess which would make database designers and technical architects twitch their face with disgust. But from the end-user perspective this could also be a nightmare for reports, mail merge and other tasks that rely around data manipulation of account records.

If you still doubt this is a bad idea, then consider countries that have more than just one type of subdivision. In the United Kingdom for instance, England has 27 two-tier counties, 32 London boroughs, 36 metropolitan districts, 55 unitary authorities and 1 city corporation. Northern Ireland has 26 districts. Scotland has 32 council areas and Wales has 22 unitary authorities. Following the logic of creating a field for each subdivision (and being finicky about it), shouldn’t we create a field for each of these possible subdivisions? And for the record, the UK is far from being an exception. There are several other countries (Russia being another example) that has more than one type of constituent entity.

If this was really an issue, every single logistics company out there would be in shambles. Your FedEx post for London England would end-up in the Faroe Islands, or the Amazon order you placed to be delivered in Moscow would end up in Guam. How come these companies are still standing?

Recommendations

My solution is plain simple. When adding addresses, consider the State/Province field the top-level constituent entity, regardless if for the address in question is for a state, province, department, canton, oblast or emirate. The City field should then be used by city, town or village.

It is just a label

With a little bit of common sense a user will understand that when filling an address, Bern being a Swiss Canton and therefore the top-level constituent entity of A Swiss address, should be filled in the State/Province field. However if the “State/Province” label really bothers you, you could use a JScript bound to the Country/Region field to change the “State/Province” label according to the selected country/region (this will work best if you use an option set for the country/region field).

City field vs State/Province field

In some cases it might be unnecessary to have both City and State/Province fields filled in. The first question you address is what sort of address information should be included in correspondences to this address.

This is often the case in the UK since only the address along with the city (or town, or village) is required along with the post code. For example when filling an address for London, typing London as the city should suffice for postal records. However, the second question you also need to consider is if State/Province is required for any of your business processes such as workflows, or reports. If that is the case then again the solution relies on common sense, and also some user training. Some solutions could be:

• Type London for both City and State/Region
• Type the London Borough (or City of London) in City, and London in State/Province

Keep in mind the following: When filling addresses, having extra information is better than missing information. One might think it is irrelevant to capture both Gloucester in the City field and Goucestershire in the State/Province field and that such address label would look unsightly. However when dealing with databases I rather have consistency over aesthetics. An address label is a means to an end and it is likely that it will end up in the bin as soon as the letter received by its recipient.

Beware of the County field

Dynamics CRM does provide a county field (not used by default) for the several entities with address-related fields (e.g.: Accounts, Contacts, Competitors, etc). However, unless your are planning to use Dynamics CRM only with countries or regions that has counties as their constituent entities, I strongly suggest you NOT to use for the previously mentioned reasons.

Another option would be that when filling an address of a country/region with county constituencies, we sync the value of the County and the State/Province fields through the use of a workflow or JScript (in such case, one of these fields would be hidden in the entity form).

In some exceptional cases a country/region can have counties not as their top level constituent entity. The Republic of Ireland is a good example, where its top level constituency of “Province” is subdivided into counties (see ISO 3166-2:IE). However in Ireland’s case nobody uses provinces for address purposes. But in some cases provinces might be required for reporting, business processes (such as workflows) or integration with other systems. so a combination of both County and State/Province fields might be required. Again, it is all about common sense and data integrity.

Final thoughts

The idea of this post is to give some guidance when customising Dynamics CRM around business requirements that might arise for capturing address information. It is important that such requirements are realistic considering the advantages and limitations of computer science, which is: computers think through binary operations; not as humans do! Therefore there must be a compromise between usability and system architecture in order to avoid bad data. Bottom line; it is all about common sense.

In this final post we will go through the creation of some workflows that will be part of our sales pipeline process.

Overview of the processes

We are going to create three workflows for the Opportunity entity. One of these workflows, the main one entitled Sales Process, will be triggered with the creation of an opportunity. This workflow is the one which the Sales Pipeline report will use for the sales pipeline phases. The second workflow entitled Sales Process – Post Mortem is a child process, which will be called by the main Sales Process workflow when the opportunity is marked as lost or won. Finally, the third workflow entitled Sales Process – Reopen of Opportunity will be triggered only when an opportunity is reopened (that is, it status changes from closed to open).

So let’s start by adding the first workflow. I assume you’re already logged into Dynamics CRM through an account that has administrative or customisation privileges.

Sales Process workflow

As mentioned in a previous post of this series, the default Sales Pipeline report that comes with Dynamics CRM relies on a workflow of the Opportunity entity to show the different stages of the Sales Pipeline. Therefore we are going to create a workflow for this purpose with the same stages of our sales pipeline as we did to customise the Opportunity form in my previous post.

All that this workflow is going to do is to move through its stages as the sales process progresses so the Sales Pipeline report can make use of it. However, you might as well add your own actions to the stages of this workflow if you wish to do so.

1. Add a new blank process of the category workflow for the entity Opportunity entitled Sales Process:
   
   Process name: Sales Process
   Entity: Opportunity
   Category: Workflow
   Type: New blank process
   
   Click on OK to confirm your settings and load the workflow design window.

Editing workflows: It doesn’t matter what name you give to your workfow and you can also rename and modify workflows at a latter stage if you want. However, in order for a workflow to work it must be activated, and activated workflows can’t be modified. If you wish to modify a workflow at a latter stage, whether to change its name or to modify its actions, you will have to deactivate the workflow.

2. In the workflow design window under the General tab, make sure you set the process properties as follows:
   
   

   Process Name: Sales Process Activate As: Process Available to Run: As a child process Scope: Organization Start when: Record is created

3. Next we will start adding the stages of the workflow. Click on Add Step and select Stage and name the first stage 1 - Prospect. Repeat these steps to add two more stages: 2 - Proposal and 3 - Negotiation.

Workflow steps: Naming stages and describing actions
Dynamics CRM allow you to provide a name/description for every step in your workflow, which are mandatory for the stages of a workflow, but are optional for the sub-steps (i.e.: “actions”) within a stage.

Remember that the name of the stages will be used by the Sales Pipeline report, so for the sake of consistency they must reflect the same names we defined for the Sales Pipeline in the previous posts of this series.

However I will not be telling you what descriptions to use for the steps in each stage since this is irrelevant for the workflow to work, but you can refer to the screenshots below as they show the descriptions I have provided for the actions.

Now under each stage we must add a wait condition with a parallel wait branch. The idea is that the workflow is waiting either for the opportunity to move to the next stage, or for the opportunity to close. If the Process Code field (which is “disguised” as the Pipeline Phase field in the form) changes to the next option, then the workflow will move to the next phase. Otherwise, if the opportunity record is closed as lost or won, then call the Sales Process – Post Mortem workflow to deal with the closed opportunity, and stop the workflow.

4. Under the first stage (1 – Prospect), select the line that says Select this row and click Add Step. Click on Add Step and select Wait Condition.
5. Click where it says (click to configure) and set the condition as: Opportunity:Proccess Code equals [2 - Proposal].
6. Repeat the two previous steps (4 and 5) for the second stage. However, make sure that for this stage we are waiting for the condition Opportunity:Process Code equals [3 - Negotiation].
7. Under the third and last stage will add a wait condition just as we did for the other two previous steps. However this time we want to configure the waiting condition to be Opportunity:Status equals [Lost;Won].


We should now have the steps configured for our workflow as the following screenshot:



The workflow as it is will move through the stages as the Opportunity’s Process Code field (again, which is “disguised” as Pipeline Phase field in the form) is updated. However, what if the opportunity is closed? For that we must account for other conditions. Our next step will be to create the workflow that will be called by this workflow when the opportunity closes.

8. For now, click on Save and Close so we can proceed to design our next workflow. We will come back to this workflow afterwards to add the required parallel wait branches.

Sales Process – Post Mortem workflow

This next workflow is pretty straightforward. We are going to create a child workflow which will be called by our main Sales Process workflow when an opportunity is either lost or canceled, and perform given actions accordingly.

1. Add a new blank process of the category workflow for the Opportunity entity entitled Sales Process - Post Mortem:
   
   Process name: Sales Process - Post Mortem
   Entity: Opportunity
   Category: Workflow
   Type: New blank process
   
   Click on OK to confirm your settings and load the workflow design window.
2. In the workflow design window under the General tab, make sure you set the process properties as follows:
   
   

   Process Name: Sales Process - Post Mortem Activate As: Process Available to Run: As a child process Scope: Organization Start when: Record is created

3. Next we will design the workflow as per the screenshot below. Click on Add Step and select Stage and name the stage X - Post Mortem. Note: We are just adding this stage for consistency, since this workflow doesn’t require stages.
4. Select the line that says Select this row and click Add Step. Click on Add Step and select Check Condition.
5. Click where it says (click to configure) and set the condition as: Opportunity:Status equals [Lost].
6. Click on the next line where it says Select this row and click Add Step. Click on Add Step and select Update Record. Make sure that where it says Update the Opportunity entity (the primary entity) is selected, and click on Set Properties. In the form, click on the Probability (%) field and type 0, then click on Save and Close to return to the workflow designer.

Editing read-only fields: If you remember from the previous post in the series, the Probability (%) field has been set as read-only when customising the Opportunity form. We will need to temporarily remove the read-only restriction of the Probability field and re-publish our customisation in order to be able to specify values for this field.

7. Back at the workflow designer, make sure that the last step we added is selected (the one that updates the Opportunity’s probability) then click on Add Step and select Stop Workflow. Make sure that where it says Stop workflow with status of the option Succeeded is selected.
8. Now click on the line that says If Opportunity:Status equals [Lost] in order to select the whole condition. Click on Add Step and select Conditional Branch.
9. At the line that says Otherwise, click where it says (click to configure) and set the condition as: Opportunity:Status equals [Won].
10. Repeat the same steps as step 6 above. However, this time when setting the properties in the form, type 100 in the Probability (%) field.
11. Finally, repeat the same steps as step 7 above.


We should now have the steps configured for our workflow as the following screenshot:



12. Click on Save and Close so we can proceed to update the previous workflow.

Sales Process workflow – revisited

Now we must update our Sales Process workflow so it can trigger the Sales Process – Post Mortem workflow we just created when an opportunity is closed. SO lets proceed to edit the Sales Process workflow.

1. Under the first stage (1 – Prospect), click on the line that says Wait until in order to select the whole condition. Click on Add Step and select Parallel Wait Branch.
2. At the line that says Otherwise, click where it says (click to configure) and set the condition as: Opportunity:Status equals [Lost;Won].
3. Click on the next line where it says Select this row and click Add Step. Click on Add Step and select Start Child Workflow. Make sure that where it says Start child workflow the Opportunity entity (the primary entity) is selected, and then select the Sales Process - Post Mortem workflow in the lookup field.
4. Make sure that the last step we added is selected (the one that starts the child workflow) then click on Add Step and select Stop Workflow. Make sure that where it says Stop workflow with status of the option Succeeded is selected.
5. Repeat all previous steps (steps 1-4) for the second stage. Leave the last stage as it is.


We should now have the steps configured for our workflow as the following screenshot:



The workflow now will move through the stages as the Opportunity’s Process Code field (again, which is “disguised” as Pipeline Phase field in the form) is updated. If the opportunity is closed (either lost or won) the workflow will call the Sales Process – Post Mortem workflow and stop the workflow as successful.

Actions: You might have noticed that at each stage of our workflow, all that we do is wait we have added no actions to take place. The idea of this workflow is simply to support the Sales Pipeline report and introduce the design of workflows in the process. Feel free to add your own actions to these workflows if you wish to do.

6. Click on Save and Close so we can proceed to create our last workflow.

Now consider this: The Sales Process workflow follows the life-cycle of an opportunity from the moment it is created. However, what would happen if a user re-opens an opportunity record? At the moment, nothing would happen. But we can create one final workflow to cover this scenario.

Sales Process – Reopen of Opportunity

This final workflow will be triggered when an opportunity status is changed. If the status is changed to open (i.e.: the opportunity is re-opened), then the Sales Process workflow will be called. Otherwise, the workflow will stop as succeeded.

1. Add a new blank process of the category workflow for the entity Opportunity entitled Sales Process – Reopen of Opportunity:
   
   Process name: Sales Process - Reopen of Opportunity
   Entity: Opportunity
   Category: Workflow
   Type: New blank process
   
   Click on OK to confirm your settings and load the workflow design window.
2. In the workflow design window under the General tab, make sure you set the process properties as follows:
   
   

   Process Name: Sales Process - Reopen of Opportunity Activate As: Process Available to Run: no option selected Scope: Organization Start when: Record status changes

3. Click on Add Step and select Check Condition.
4. Click where it says (click to configure) and set the condition as: Opportunity:Status equals [Open].
5. Click on the next line where it says Select this row and click Add Step. Click on Add Step and select Update Record. Make sure that where it says Update the Opportunity entity (the primary entity) is selected, and click on Set Properties. In the form, click on the Probability (%) field and type 5, for the Rating field select Cold and for the Process Code field select 1 - Prospect then click on Save and Close to return to the workflow designer.
6. Back at the workflow designer, make sure that the last step we added is selected (the one that updates the opportunity’s probability, rating and process code) then click on Add Step and select Start Child Workflow. Make sure that where it says Start child workflow the Opportunity entity (the primary entity) is selected, and then select the Sales Process workflow in the lookup field.
7. Make sure that the last step we added is selected (the one that starts the child workflow) then click on Add Step and select Stop Workflow. Make sure that where it says Stop workflow with status of the option Succeeded is selected.
8. Now click on the line that says If Opportunity:Status equals [Open] in order to select the whole condition. Click on Add Step and select Default Action.
9. Under Otherwise select the line that says Select this row and click Add Step. Click on Add Step and select Stop Workflow. Make sure that where it says Stop workflow with status of the option Succeeded is selected.


We should now have the steps configured for our workflow as the following screenshot:



10. Click on Save and Close so we can proceed to activate our workflows.

Activating and testing the workflows

After saving and publishing our workflows, our next step is to activate our workflows so we can test them.

1. After activating the workflows, proceed to create an opportunity and save it without closing it.
2. If you click on Workflows under Procecces at the left-hand side navigation pane in the Opportunity form, you will be able to see the associated Sales Process workflow which has been triggered upon the creation of this Opportunity record.
3. Go back to the General tab of the Opportunity form and change the Pipeline Phase from 1 - Prospect to 2 - Proposal. Now if you go back to the associated workflow view (see previous step) and click on the Sales Process workflow, you can see its progress.



Workflow stages: Unfortunately Dynamics CRM 2011 workflow designer only allow a linear and sequential progression through the stages of a workflow. In practical terms, this means that from Stage 1 we can only progress to Stage 2, from Stage 2 to Stage 3 and so forth; and we can’t jump a stage or go backwards on stages. This is why we added the bonus JScript in the previous post of the series to enforce users to follow a linear and sequential progression. If you want to create a workflow that allow jumping back and forth through its stages, you will have do design the workflow using Visual Studio.

Update May/2012: Even though the Dynamics CRM 2011 workflow designed doesn’t allow us to jump stages (e.g.: like a “GOTO” statement), we could still progress through all the stages if a user jumps forward by adding additional conditionals, and even support users moving backwards through additional parallel wait branches and restarting the Sales Pipeline workflow as a child workflow from itself. Because this would significantly increase the complexity of this workflow, I will be covering this scenario in another post.

4. Now proceed to view all of the open opportunities. At the Ribbon, click on Run Report and select the Sales Pipeline report. When prompted to select records, select All applicable records then click on Run Report.
5. When the report finish to load, at the top where it says Group by Sales Process select Sales Process (the name of our workflow) from the drop-down. Where it says Group By select Sales Stage. Then click on View Report to update the report. We should now see the opportunities estimated revenue grouped by the sale stages.



The report takes the sale stages from the stages of our Sales Process workflow. You might be wondering why couldn’t this report make use of the same field as the pipeline chart does in the previous post of this series. I asked myself the same question when I first came across this report. However it does make sense to have the report based on the workflow stages and the chart on an entity field; particularly if you have complex workflows and sub-stages for dealing with different products or business units.

Wrapping up

Wow… That was a lot of writing. Through the course of this series we introduced a lot of concepts for creating a functional sales pipeline in Dynamics CRM 2011. Through the customization of the Opportunity entity we also introduced some useful JScripts which calculate fields and remove options from option sets. Also through the design of workflows we introduced the concepts of conditionals, waits and branches; as well the use of child workflows. I hope you enjoyed this series and that it can be a useful reference for those in the Dynamics CRM community. Thank you for stopping by!

Bonus: Challenge yourself

Update Jan/2012: Because the sales pipeline is only about open opportunities, we only covered the open stages of the opportunity in this series of posts (1 – Prospect, 2 – Proposal, 3 – Negotiation). However, let’s say that for consistency we would also like the Pipeline Phase field of a closed opportunity to show either “4 – Won” or “X – Lost”, in case someone opens the form of a closed opportunity record. How could we do that?

This can easily be done with by adapting our workflow to change the value of the Pipeline Phase (stepname) accordingly for when an opportunity is closed either as won or as lost. As for our Process Code (salesstagecode) field labeled as Pipeline Phase, we can either adapt our JScript to hide it when a form is disabled (using CRM_FORM_TYPE == 4) so users would only see the Pipeline Phase (stepname) in the form footer when viewing inactive records. Alternatively, we can add two additional options to the Process Code (salesstagecode) and have them always hidden from the end-user in an editable form by adapting the bonus JScript proposed in the previous post. Then the workflow would update the value of the Process Code option set according to the close status of the opportunity (either as won or as lost).

Have fun!

In this post we will discuss how to apply what have been defined so far by covering the customisation of the Opportunity entity form, including some scripting.

So let’s start by customising the Opportunity form.

Opportunity form: Adding and editing fields

1. Add the Process Code field (salesstagecode) above the Rating field (opportunityratingcode).
2. Edit the Process Code field properties. Under Display, change the field label to Pipeline Phase.
3. Now under Details, click on Edit to add the Pipeline Phase stages as options into the option set field, remembering the caveats concerning naming and numbering the pipeline phases we mentioned in the previous post. As per the previous post, we should add the following options:
   
   1 - Prospect
2 - Proposal
3 - Negotiation
   
   Make sure to save and close the properties dialog for the Process Code field.
4. Back at the Opportunity form under Forecast Information, make the Probability field (closeprobability) read-only.
5. Add the Pipeline Phase field (stepname) just under the Probability field, which is the field used by the Sales Pipeline Funnel Chart. Change the properties of the field and make sure that under Visibility, the field is not selected as visible by default.

Our Goal: What we are going to achieve here is that using the Process Code field labeled (i.e.: “disguised”) as the Pipeline Phase field, users will be able to manualy select the Pipeline Phase in which the opportunity is at. The label of the option selected in this field will then be copied into the real Pipeline Phase field, which we just added as hidden in the form. Furthermore, we made the Probability field readonly because its value will be automatically calculated based on the combination of values from the Pipeline Phase and Rating fields, following our probability matrix we defined in the previous post.

Adding our JScript: Creating the web resource

In order to achieve the goal mentioned above, we must add some code that will work with the customisation we did so far.

1. Create a new JScript web resource and name it new_SalesPipeline.
2. Add the following code into the web resource:

SalesPipelineProbCalc = function() {
  var CRM_FORM_TYPE = Xrm.Page.ui.getFormType();
  if (CRM_FORM_TYPE == 4 || CRM_FORM_TYPE == 3) { return; }

	// Get value of Pipeline Phase set by user
	if (Xrm.Page.getAttribute("salesstagecode").getSelectedOption() != null)
	{var val_salesstagecode = Xrm.Page.getAttribute("salesstagecode").getSelectedOption().value;}
	else {var val_salesstagecode = null;}

	// Get text of Pipeline Phase set by user (this text should be the same for all languages)
	if (Xrm.Page.getAttribute("salesstagecode").getSelectedOption() != null)
	{var txt_salesstagecode = Xrm.Page.getAttribute("salesstagecode").getSelectedOption().text;}
	else {var txt_salesstagecode = null;}

	 // Set the text of Pipeline Phase field
	Xrm.Page.getAttribute("stepname").setValue(txt_salesstagecode);

	// Set the submition mode of closeprobability (which is set as read-only) in order to commit the value when saving the record
	var closeprobabilityAttr = Xrm.Page.getAttribute("closeprobability");
	closeprobabilityAttr.setSubmitMode("always");

	// Get value of the Rating selected by user
	if (Xrm.Page.getAttribute("opportunityratingcode").getSelectedOption() != null)
	{var val_rating = Xrm.Page.getAttribute("opportunityratingcode").getSelectedOption().value;}
	else {var val_rating = null;}

	// Calculation of Close Probability Rating as per Phase X Rate matrix
	if (val_salesstagecode == 1 && val_rating == 3)
	{ Xrm.Page.getAttribute("closeprobability").setValue(10); }
	else if (val_salesstagecode == 1 && val_rating == 2)
	{ Xrm.Page.getAttribute("closeprobability").setValue(25); }
	else if (val_salesstagecode == 1 && val_rating == 1)
	{ Xrm.Page.getAttribute("closeprobability").setValue(50); }
	else if (val_salesstagecode == 2 && val_rating == 3)
	{ Xrm.Page.getAttribute("closeprobability").setValue(20); }
	else if (val_salesstagecode == 2 && val_rating == 2)
	{ Xrm.Page.getAttribute("closeprobability").setValue(50); }
	else if (val_salesstagecode == 2 && val_rating == 1)
	{ Xrm.Page.getAttribute("closeprobability").setValue(75); }
	else if (val_salesstagecode == 3 && val_rating == 3)
	{ Xrm.Page.getAttribute("closeprobability").setValue(40); }
	else if (val_salesstagecode == 3 && val_rating == 2)
	{ Xrm.Page.getAttribute("closeprobability").setValue(75); }
	else if (val_salesstagecode == 3 && val_rating == 1)
	{ Xrm.Page.getAttribute("closeprobability").setValue(95); }
	else { Xrm.Page.getAttribute("closeprobability").setValue(0); }

}

3. Save your changes and make sure to publish the customisation.

A warning on pipeline phases: At the moment, users can move both forward and backwards in the sales pipeline stages without any limitations. For instance, a user could jump from step 1 to 3, or move backwards from step 2 to 1. There are two issues with at hand. First, I personally don’t think an opportunity can go backwards; it can either go forward or be cancelled/lost. Second, the Sales Pipeline report is based on steps within a workflow that we’re yet to create (which we will cover in my next post), and workflows created within Dynamics CRM doesn’t allow us to jump backward on steps.

A workaround would be to add a JScript that prevent users from moving backward on the pipeline phases. See the “bonus JScript” section below for further information.

Opportunity form: Binding JScript into form and fields

Now that we added our JScript as a web resource, we must bind it into the Opportunity form and into field events to ensure the calculation will take place when the user changes the correspondent values within the form. So let’s go back to customise the Opportunity form.

1. Click the Form Properties button located in the Ribbon. In the Form Properties dialog under the Events tab, click on Add under the Forms Libraries section and select the new_SalesPipeline web resource we created previously. Then close the Form Properties.
2. Double click on the Process Code field (which we labeled Pipeline Phase) in order to bring its properties. In the Field Properties dialog under the Events tab, click on Add under the Event Handlers section.
3. On the Handler Properties dialog, where it says Function, type in SalesPipelineProbCalc, which is the name of the function we created in the new_SalesPipeline web resource. Then click on OK, then OK again in the previous dialog to confirm our customisation.
4. Repeat the two previous steps (2, and 3) for the Rating field.
5. Save the form and publish the customisation.

What we just did: We have now added the JScript library we created (i.e.: the JScript web resource) into the Opportunity form and bound the SalesPipelineProbCal into the onChange event for the Process Code (“disguised” as Pipeline Phase) and Rating fields. So when the user changes the value of either one of these fields, the value within the Probability field will change accordingly as per the Probability Matrix we defined previously.

onLoad Form: We could have also added this function to the form’s onLoad event. This means that as soon as the form loads, the script will be executed. The script contains a conditional at the top that checks if the form isn’t read-only (e.g.: if viewing a closed opportunity) in order to execute the calculation.

Testing our solution

When can now go ahead and test our solution by creating an opportunity. We can manually specify the pipeline phase in which the opportunity is at, and this will reflect in the Pipeline Funnel chart. We can also give our opportunity the rating of hot, warm or cold, and along with the pipeline phase selected, the system will automatically calculate the probability for closing the opportunity.

Bonus JScript: Filtering option set values

In order to prevent users from jumping backward or skipping phases from the sales pipeline, we can filter the options available within the Pipeline Phase option set based on the current value with a simple JScript:

SalesPipelineOptFilter = function() {
  var CRM_FORM_TYPE = Xrm.Page.ui.getFormType();
  if (CRM_FORM_TYPE == 4 || CRM_FORM_TYPE == 3) { return; }

	// Get value of Pipeline Phase set by user
	if (Xrm.Page.getAttribute("salesstagecode").getSelectedOption() != null)
	{var val_salesstagecode = Xrm.Page.getAttribute("salesstagecode").getSelectedOption().value;}
	else {var val_salesstagecode = null;}

	if (val_salesstagecode == 1)
	{ Xrm.Page.getControl("salesstagecode").removeOption(3); }

	else if (val_salesstagecode == 2)
	{ Xrm.Page.getControl("salesstagecode").removeOption(1); }

	else if (val_salesstagecode == 3)
	{
	Xrm.Page.getControl("salesstagecode").removeOption(1);
	Xrm.Page.getControl("salesstagecode").removeOption(2);
	}

}

Make sure you add this JScript on the onLoad event of the form as well as in the onChange event of the Process Code field (salesstagecode) field (labeled as Pipeline Phase in our customised form).

Coming up next: Creating a workflow

In my next post we will be discussing how to create workflows to support our customisation. This is important if we want to use the default Sales Pipeline report that comes with Dynamics CRM.

I saw Jobs as a difficult man who mistreated his employees, and I never understood his value to the market. That is, until I did my Masters Degree and I was introduced to the concept of industry paradigms.

Regardless of any rivalry feeling one can feel on “Apple Vs Windows” subject, Steve Jobs was undeniably a visionary and a paradigm pioneer who challenged concepts and developed new markets and trends. Before the iPod, the digital music players were all but a joke, and the iPad succeeded to launch the tablet industry where others previously failed.

The world will be less innovative without him. My sympathies to Apple and his family and friends.