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 the means to an end and it is likely that it will end up in the bin as soon as the letter received the 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.

Note on naming 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.

Descriptions: Dynamics CRM allow you to provide a description for every stage and action in your workflow. I will not be telling you what descriptions to type since this is irrelevant for the workflow to work. However, you can refer to the screenshots below as they show the descriptions I have provided for the stages and 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 entity Opportunity 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 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.

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 closed (usingCRM_FORM_TYPE == 4) so users would only see the Pipeline Phase (stepname) in the form footer. 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) {

	// 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) {

	// 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.

It doesn’t matter if it is an email offering me dodgy Rolex replicas or dubious pharmaceuticals, or if it is a newsletter from a major and respectable institution. Any speculative email I receive that I haven’t explicitly subscribed to, is to be considered SPAM. Enough said.

To find the correct colour combination, however, can be a tedious choir. Particularly when you just want to get it over with. My trick is to use the default Microsoft Office 2007/2010 colour theme as a reference. In order to make this task easier, I created a reference chart with listing the colours along with both RBG (red/blue/green) and hexadecimal values.

You can also click here to download a PDF version of the this sheet.

However, there is more to charts than it meets the eye. The charts functionality in Dynamics CRM leverages the ASP.NET chart controls, which means that we have at our disposal over 20 different chart types we could use. I decided to put the theory into practice and I created my very first radar chart for Dynamics CRM: Deals Won vs. Deals Lost by Territory.

In Dynamics CRM, charts are based on a proprietary language query called FetchXML. The chart design tool can be quite handy to design simple charts, without the need to meddle with FetchXML code. However, the design tool only allow the creation of five different chart types (column, bar, line, pie and funnel) and it also doesn’t allow the creation of charts with multiple series and group-by attributes*. For more complex charts or charts based on other chart types which aren’t one of the “canonical fives” previously mentioned, we must take our design efforts beyond the chart design tool. In this case, we must do some coding in FetchXML.

* Update Roll-Up 5: With the release of Update Roll-Up 5 9 (see KB 2567454), Microsoft included enhancements to the chart designer, including multiple series and the ability to create area charts, bringing the number of chart types supported in the designer from five to six.

When viewing charts in Dynamics CRM, we have the option to export the chart definition as a XML file so we can edit it with our favourite text editor (I use Notepad++). We can then upload our modified XML charft definition back into Dynamics CRM.

For this exercise, I downloaded the XML definition of two charts which I used as reference: Deals Won vs. Deals Lost By Fiscal Period and Sales Progress by Territory. Based on those two chart definitions, I got enough information to go ahead an create my own chart, and I came up with a radar chart entitled Deals Won vs. Deals Lost By Territory.

Here is the code for this chart. Feel free to give it a try and modify it at will.

<visualization>
  <visualizationid>{8BADBB34-01E6-E011-80C0-00155D18443B}</visualizationid>
  <name>Deals Won vs. Deals Lost By Territory</name>
  <description>Shows the amount of revenue for won deals versus lost deals by territories.</description>
  <primaryentitytypecode>opportunity</primaryentitytypecode>
  <datadescription>
    <datadefinition>
      <fetchcollection>
        <fetch mapping="logical" aggregate="true">
          <entity name="opportunity">
            <link-entity name="opportunity" from="opportunityid" to="opportunityid" link-type="outer">
              <attribute alias="sum_won" name="actualvalue" aggregate="sum"></attribute>
              <filter>
                <condition attribute="statecode" operator="eq" value="1" />
              </filter>
            </link-entity>
            <link-entity name="opportunity" from="opportunityid" to="opportunityid" link-type="outer">
              <attribute alias="sum_lost" name="estimatedvalue" aggregate="sum"></attribute>
              <filter>
                <condition attribute="statecode" operator="eq" value="2" />
              </filter>
            </link-entity>
            <link-entity name="account" from="accountid" to="customerid" link-type="outer">
              <link-entity name="territory" from="territoryid" to="territoryid" link-type="outer">
                <attribute groupby="true" alias="groupby_territory" name="name" />
              </link-entity>
            </link-entity>
          </entity>
        </fetch>
      </fetchcollection>
      <categorycollection>
        <category>
          <measurecollection>
            <measure alias="sum_won" />
          </measurecollection>
          <measurecollection>
            <measure alias="sum_lost" />
          </measurecollection>
        </category>
      </categorycollection>
    </datadefinition>
  </datadescription>
  <presentationdescription>
   <Chart Palette="None">
      <Series>
        <Series ChartType="radar" Name="o:opportunity_statecode,1" Color="149, 189, 66" IsValueShownAsLabel="False" BackGradientStyle="TopBottom" BackSecondaryColor="112, 142, 50" Font="{0}, 9.5px" LabelForeColor="59, 59, 59">
          <SmartLabelStyle Enabled="True" />
        </Series>
        <Series ChartType="radar" Name="o:opportunity_statecode,2" Color="255,124,31" IsValueShownAsLabel="False" BackGradientStyle="TopBottom" BackSecondaryColor="235,98,0" Font="{0}, 9.5px" LabelForeColor="59, 59, 59">
          <SmartLabelStyle Enabled="True" />
        </Series>
      </Series>
      <ChartAreas>
        <ChartArea BorderColor="White" BorderDashStyle="Solid">
          <AxisY LabelAutoFitMinFontSize="8" TitleForeColor="59, 59, 59" TitleFont="{0}, 10.5px" LineColor="165, 172, 181">
            <MajorGrid LineColor="239, 242, 246" />
            <MajorTickMark LineColor="165, 172, 181" />
            <LabelStyle Font="{0}, 10.5px" ForeColor="59, 59, 59" />
          </AxisY>
          <AxisX LabelAutoFitMinFontSize="8" TitleForeColor="59, 59, 59" TitleFont="{0}, 10.5px" LineColor="165, 172, 181">
            <MajorGrid Enabled="False" />
            <MajorTickMark Enabled="False" />
            <LabelStyle Font="{0}, 10.5px" ForeColor="59, 59, 59" />
          </AxisX>
        </ChartArea>
      </ChartAreas>
      <Titles>
        <Title Alignment="TopLeft" DockingOffset="-3" Font="{0}, 13px" ForeColor="0, 0, 0"></Title>
      </Titles>
      <Legends>
        <Legend Alignment="Center" LegendStyle="Table" Docking="Bottom" Font="{0}, 11px" ForeColor="59, 59, 59"></Legend>
      </Legends>
    </Chart>
  </presentationdescription>
  <isdefault>false</isdefault>
</visualization>

Copy the above code and paste it into your favourite text editor, then save the file with as an XML file (make sure the file terminates with the .XML extension, and not something else such as MyChart.TXT or MyChart.XML.TXT). Now you can go back to Dynamics and import your XML chart definition file.

Import as a personal chart (only available to you): Navigate to the Opportunity entity by clicking on Opportunities at the left-hand side navigation. Then click on Import Chart button located in the Chart ribbon.

Import as a system chart (available to the whole organisation: Navigate to Settings, then Customizations and then select Customize the System. In the Default Solution window that appears, expand Entities, then Opportunity and select Charts. Click on More Actions in the menu bar and select Import Chart to import your chart definition. Once the file is imported, make sure you click on Publish All Customizations.

Hope you can find this chart useful. If you need further information on FetchXML, check out the following recommendations:

Further information: The following sites can be of help for those starting with charts in Dynamics CRM 2011:
Microsoft Developer Network: Library entry on FetchXML Schema
Microsoft Download: Microsoft Chart Controls for .NET Framework Documentation
Microsoft Developer Network: Samples Environment for Microsoft Chart Controls
Microsoft Dynamics CRM Blog: CRM 2011 Charts – Know the Real Potential ~ Part I
Microsoft Dynamics CRM Blog: CRM 2011 Charts – Know the Real Potential ~ Part Deux
Gareth Tucker: Quick Reference for Common CRM 2011 Chart Customisations

For help in choosing colours when creating charts for Dynamics CRM, refer to my Office Colour Scheme in the next post.

Basically, creating and qualifying a lead can provide useful information into marketing and sales. For instance, suppose you went to an industry event representing your organisation from where you obtained 150 business cards. You would like to then register those business cards into Dynamics CRM so you can follow up with some sales opportunities.

At this point, all you have is business cards. These cards represent potential clients, but not your actual clients. Sure you could go ahead and register them as accounts and/or contacts, however you’ll be missing important information about qualifying those records, and likely to have wasted your time if the potential client is not interested in a possible deal.

The Leads entity allows you to create just one record for each business card, instead of one record for an organisation and another for the person. Once a lead is created you can go on and proceed to qualify the record (that is, following up with the potential client and see if you can get an opportunity out of it). This qualifying process can be whatever you want it to be, based on your modus operandi or organisation procedure. For instance, it could be a series of phone calls, followed by some pre-sales meetings. You can create activities such as phone calls, emails and meetings associated to the Lead record, which will help you and your team (if relevant) to make better business decisions on how to approach potential clients. If you hit a dead-end, you can either qualify or disqualify the lead. Qualified leads can then be converted into an account record and/or contact record and/or opportunity record. Disqualified leads on the other hand can be given different status reasons such as Lost, Cannot Contact, No Longer Interested or Cancelled.

Another important aspect of the Lead record is its relationship with Marketing Lists and Campaigns entities. Combining with the lead qualification process, you can measure the effectiveness and efforts of your marketing campaigns. For instance, we could assess leads by source campaign, leads qualified/disqualified for a given period, the industry from which most leads come from, and so on. You could also create goals and metrics related to the Leads entity for your teams. For instance, you could set a goal of 30 leads to be qualified each month in order to track the effectiveness of your marketing team.

Finally, the Leads record also allows the automatic capture of leads coming from external websites. For instance, you could have a website that allow customer to provide their contact details in order to obtain further information. Upon registering their details, lead records can be created for your sales team to follow up.

Note: For further information on how the Lead entity works within the full scope of the sales process in Dynamics CRM, check out my first post in the series about the Dynamics CRM sales pipeline.

Then I checked the price of that piece of work. The next thing I remember was my mother reprehending me for cursing out loud in a public place. This story came to my mind today as I was installing Windows 8, and reflects what I think of the whole hype around the Metro interface.

Don’t get me wrong. I like Metro. I think Microsoft hit the nail right on the head for a touch interface. But here is the thing: Let’s leave Metro to serve its purpose. That is: tablet devices and touch-based interfaces. Now, I know that Microsoft is saying (and even demonstrated) that the Metro interface will be side-by-side with the traditional desktop, that users can switch between Metro and the traditional desktop any time they want, and so on. But in practice, Windows 8 insists on pushing the Metro interface at every opportunity. For instance, look at the Windows 8 setup screens.

Seriously, is this supposed to be chic or innovative? Fair enough this is a development preview, but come on! Those screens look like they were designed on Microsoft Paint (by someone who doesn’t know how to use Microsoft Paint). If those screens are anything near to what we should expect from the final version, I am not impressed. I fear that the whole Metro concept can be used as an excuse for lazy artwork (or no artwork at all, which at this point I’m not sure what would be worse).

So I installed Windows 8 and I went to have a look at the initial desktop. Once again, it focus on the Metro by default. I can click on the desktop tile to go to the desktop, but if I click at the Windows logo to access the start menu, it brings me back to the Metro interface. Sigh…

Update: Neowin.net has published an article on their site explaining how to restore the classic start menu in the Desktop of the Window 8 Development Preview (requires editing the registry). You can read the article here.

Asserting that Metro is “the future” is, in my view, an overestimation that implies that Metro will be pervasive in upcoming versions of Windows and is likely to replace the traditional desktop as we know it. I hope that it isn’t the case, and that Microsoft is just heavily focusing on the Metro interface at this stage of the development of Windows 8 because it is a new thing which they’re trying to promote. Again, I like Metro, but I am not on my Windows Phone or at a tablet here. I am trying to use my desktop and the overly simplistic interface infuriates me.

I am sorry but I don’t think that the Metro interface has its space in desktop computing. For instance, I can’t see trading workstations, engineering or CAD/CAM software running under it. I want my desktop back. Can I have it please?