Dynamics CRM 2013: Diving into the sales pipeline – Part 3

In my previous post of this series, we discussed how to implement ACME’s sales pipeline through the creation of a business process flow (BPF) considering both the Lead and Opportunity entities. We created two business processes, one for opportunities that originated from leads, and another for opportunities that did not originated from leads.

In this post we will discuss how to implement ACME’s opportunity probability matrix through the creation of business rules.

Dynamics CRM: Disabling the selection of contacts for opportunities all the way

I recently got a requirement for a Dynamics CRM implementation that all recorded sales should follow the B2B (business to business) and therefore, opportunities should only able to be related to accounts, and not contacts as well.

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.

Dynamics CRM: The importance of the Address entity

Earlier this year I wrote an article about considerations when customising address fields. I was happy with the reception the article got, as it sparked some interesting discussions not only with some of my clients, but also with fellow Dynamics CRM consultants.

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

Dynamics CRM: Set Title Case for a text field using JScript; but only once

Today I had to work on a interesting JScript for Dynamics CRM. When creating a new Contact record, the text values within the fields for First Name, Middle Name and Last Name should have a Title Case enforced to them. For example, if a user types “JOhN” in the First Name field, the case should be automatically corrected to “John”.

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.

Dynamics CRM: JScript vs workflow – Caveats

JScripts in Dynamics CRM are a powerful feature to enhance the user interface in Dynamics CRM. We can use JScripts to perform calculations and validate fields in forms in order to introduce a better user experience. However, JScripts are a client-side based, and only work with the desktop-based (main) forms. In other words, if the user is accessing Dynamics CRM through a mobile device displaying the mobile forms, or using a 3rd party client for a tablet device, the JScripts will not be loaded at all. Workflows on the other hand are server-based, and they will execute no matter which device and client is used to access Dynamics CRM.

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.

Dynamics CRM 2011: Diving into the sales pipeline – Part 2

In my previous post of this series, we discussed some fundamental concepts of the sales pipeline and how Dynamics CRM handles the sales process. While considering the requirements of ACME (a fictitious company), we defined the stages of their sales pipeline, and started to outline the functional specification of the opportunity entity, including the elaboration of an opportunity probability matrix.

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.

Dynamics CRM: Automating record names

In every application that makes use of a relational database in a multi-tier architecture, beyond the unique identifiers for records within a table, it is common practice to allow records to be named in a way that would help users easily retrieve the relevant records, be it by search or browsing. In Microsoft Dynamics CRM is no different. Accounts are named by the company name while opportunities are named by their topic, and so on.

Since the idea of naming records is for the identification and retrieval of records, it makes sense to me that users can name Accounts and Contacts to their liking. However, this isn’t the case for Goal records in my organisation.

When creating Goals, users can type anything they want in the name field, which could range from sensible names like “James W Revenue Goal for Q4/2011” to cryptic names like “JW Rev Q4/11”, or anything but professional, like “Show me the money”. Sure we could come up with a naming convention that users should follow. The problem, evidently, is making sure that users will follow it.

The objective of this post is to propose a step-by-step solution for the automatic naming of Goal records following a naming convention through the use of one Javascript.