A while ago when performing a requirements gathering session for the sales process functionality in a CRM implementation project, my client asked me whether Dynamics CRM was able to show information on the opportunity form about how similar opportunities had performed in the past. Thinking of an analogy from the world of consumer web apps, this would be a bit like Amazon’s feature where they show you similar items that other people had purchased after ordering the product you are currently thinking of buying.
My initial reaction to the request was “I wish we could do that, but you’re looking at either a significant chunk of custom development or a considerably more expensive piece of software to get that functionality”. After a moment of thinking about it, though, I realized that the new CRM 2013 version already had some platform functionality that could be leveraged for delivering such a feature under the right circumstances.
Quick View Forms across multiple relationships
Traditionally Dynamics CRM has been an application where you can show information from either the current record the user is working on or the child records directly related to it. It wasn’t until CRM 2011 that showing the related child records right on the entity form became a supported scenario. With CRM 2013 we’ve gained another important feature that we can use to expand the scope of information being shown to the user on a single form. The new Quick View Forms allow us to show several fields from the parent entity on the current entity’s form. Even better, the Quick View forms support the CRM 2011 subgrid feature, which also makes it possible to show information about the child records of the parent record on one of its other child records.
“Whoa, that’s way more relationships that I can visualize in my head! What does all this actually mean?” No worries, these are not the type of features that would be immediately obvious to even the more seasoned CRM consultants. Let’s approach this via an example from the out-of-the-box configuration of the CRM 2013 case form. This new form contains a Quick View Form called Customer Details:
The Quick View Form not only shows details about the customer account but also a subgrid of all the recent cases where this account has been the parent record. So, starting from the case record, we go one level up in the hierarchy to query the account record and then we come back down again to retrieve a list of child records for this account. The Recent Cases subgrid returns back to the same entity as where we start from, but this is not a requirement, as is demonstrated by another subgrid included in the same Customer Details Quick View Form that lists the recent activities regarding this account. Effectively we can show any entity information that is maximum two hops away from the current record and that share the common parent record.
Applying Quick View Forms in customer segment analysis
How could we leverage this feature in providing the CRM user some insights on how similar opportunities have worked out in the past? The key here is finding an entity that we can use for binding the different opportunities together and showing relevant information about them that will be helpful for the CRM user in deciding on the actions to take in pursuing the new sales opportunity. If it’s an existing customer that has done purchases in the past we could of course benefit from seeing this history, but assuming that we’re dealing with a scenario where repeat purchases are not that frequent, we should look for a different variable that could help us in surfacing the past sales analytics that can help us in winning the new deal in question.
Let’s assume that we’ve got a customer segmentation model in place where we assign each new and existing account a segment value. The actual rules behind the segmentation process are beyond the scope of this article, but the one thing that’s critical here is that the segment information is stored in a dedicated “Segment” entity. This custom entity has a parental relationship to the account entity, which basically means that we can open a segment record and see all the accounts belonging to that segment. Now, because of the fact that each account has a value in the segment lookup field, we can also configure it so that every opportunity created for the account also inherits the segment value of that account. Effectively we’ll then have a similar 1:N relationship between the Segment and Opportunity entities as we have with Segment and Account. The end results and our target configuration will therefore look something like this:
We need to have a bit of redundancy in our data model in order to be able to leverage the Quick View Form feature for our desired purposes. Technically we could determine the segment of the opportunity record just by examining the value on the parent account of that record, but we wouldn’t be able to reference it on the opportunity form customization UI. Therefore it is crucial that the segment value is carried over from the potential customer account onto the opportunity record, either through a relationship attribute inheritance or a real-time workflow that retrieves the value right after the opportunity record is created (preferably both, to cover all scenarios for opportunity creation).
What can we do with the segment value on the opportunity then? Unlike the example of showing a list of cases related to the account, we can also show the subgrid data in the form of a chart that summarizes the values. What this means is that we’ve got the capability of showing sums, counts and even averages of records related to the segment. In the case of opportunity records, our ability to surface information on opportunities related to the chosen segment is only limited by the amount of information we gather on the opportunity records in the first place. For example, if we’ve got a process in place that will store the duration of the sales cycle in days on a custom field on the opportunity record once the record is closed, we can show the average number of days to close a deal in the segment of the account. All the default variables like the actual amount of the won opportunities are naturally also at our disposal.
In the example above, I’ve added a Segment Opportunity Analytics section on the opportunity form and included a Segment Quick View Form on it. This form contains the name of the segment and two subgrids: “Average days until close” and “Average revenue”. These subgrids query all the closed opportunities where the segment value matches our record. To present the information in a visual format and allow us to calculate the desired values, I’ve ticked the “show chart only” box and select a custom chart I’ve built on the opportunity entity.
Now whenever a new opportunity record is added, the very moment the Segment field is populated, CRM will immediately retrieve the performance metrics specified on the Quick View Form. This way the person planning the next steps for proceeding with this opportunity and estimating the time it will take to pull in the expected revenue will have some real-time analytics available right there in the CRM UI to assist him or her in this task. What better way to ensure that new employees can leverage the data that has accumulated into the CRM system over the years and turn that into informed decisions on how to pursue similar new opportunities?
One of the key takeaways from this example is that with CRM 2013 there are even more compelling reasons for modeling your record metadata as custom entities instead of option sets. If we were storing the segment value simply as a global option set then none of the Quick View form functionality would be available to us. By having the list of segment values stored as data on a custom entity instead we can easily bring in related data from other entities, in addition to some of the other benefits that already existed in previous versions of Dynamics CRM: being able to add new values without needing to update the solutions, deactivating unused values, better flexibility when working with workflow rules etc. Sure, the fact that these values don’t get packaged into the solution files like option sets do means there’s a bit more work in maintaining the lists of values across dev, test, QA and production environments, but the benefits in end user facing functionality may well outweigh these additional administration costs.
Nice.