Profile and Survey Customers with CRM 2011 Dialog Processes

One of the most obvious applications of dialog processes are scripted conversations. And one of the most obvious examples of a scripted conversation is a survey. Dialog processes work great for all kinds of surveying and profiling requirements, and we’ll review an example of that here. But first, let’s review our choice of tools: there are lots of ways to conduct surveys, and it’s reasonable to ask why you might consider using a Dynamics CRM dialog process for one rather than say, Survey Monkey (http://www.surveymonkey.com/).

Here are some of the factors that would make the Dynamics CRM approach appropriate for a job like this:

If the people you want to survey are in your CRM (e.g., as contacts), taking a CRM-centric approach is compelling. This is the same argument as using a CRM add-on solution for email marketing rather than, say Constant Contact: survey results might be as important a piece of customer history as email click-throughs, so it’s natural to want them in your CRM.
The kind of surveying and profiling described next can be done with the out-of-the-box CRM feature set plus a few customizations, so you won’t pay additional licensing fees or have to learn a new application.

Why might you not want to use Dynamics CRM dialog processes for surveys?

Complex survey functionality will be more easily implemented with a dedicated survey application. As you’ll see, using Dynamics CRM for a job like this one is a bit of a DIY project, and as with all DIY projects, you’re essentially making a build v. buy decision.
Dialog processes must be run by a licensed CRM user. So if you need to provide a self-service survey option, the CRM-centric approach discussed here won’t be an option.

Profiling and Surveying Customers: The Goal

This approach I’ll describe here requires some customizations, and there are many different ways of implementing it: from simple and specific, to complex and flexible. Let’s start by examining how this surveying solution works, so you know what we’re shooting for.

Some organizations have highly structured “onboarding” process to be applied when new customers are signed up. For example, a bank might have a standard set of questions to ask of new savings account customers, or a marketing department might want to know if a new customer was influenced by any of its ads, mailings and so forth. Other common requirements of onboarding processes like these are to get feedback from the customer on their overall satisfaction level and to confirm that important information on the customer record is correct.

The following figure shows the single page of our dialog process as it’s being run by a user. This process is written for the contact entity, and you can see in the first (highlighted) prompt that we’re using dynamic values to provide the user with a customized script (Hello, Eva) and to call attention to some of the most important contact information we want our user to verify or correct.

Notice also that in the Tip section we’ve provided a link (Navigate to contact record) and instructed the user to go directly to the contact form if they need to make any changes:

The next figure highlights the How did you hear about us option set. You’ll see below that we used a custom entity to store these values, and a query in the dialog process to present them to the user.

The following figure presents the “rate your overall experience on a 1-5 scale” question.

After the user clicks the Finish button, the process creates three records for a custom entity, Survey Response, one for each of the questions. (It might look like there are four, but remember the first one is just a prompt, with no response being captured.)

The following figure illustrates that the Survey Response entity has an N:1 relationship to contact, so our design requirement of having survey responses be part of the comprehensive customer history is satisfied:

Here’s the data grid for survey responses with the All Survey Responses view selected. Notice that I’ve added several different fields to store different kinds of responses. This is an important detail and I’ll describe it more fully below.

Finally, the following figure really starts to highlight some of the potential benefits of this approach. A custom view filters survey response records to only include records for the Experience Rating question. This means that a custom chart can be used to visualize the results:

Here, the chart is constructed with the average value of the Response (Decimal) field as the Series, and the data are distributed across the owners of the underlying contact records.

Setting Up

I used three custom entities to implement this solution: Survey, Survey Response, and Lead Source. The following Visio diagram illustrates how they’re related to each other and to Contact:

Contact and Survey both have 1:N relationships to Survey Response, effectively creating an N:N between Contact and Survey. Notice that Lead Source isn’t related to anything. Of course, it could be related to other entities, but for this example it is not required to be. As you’ll see below, the only role the Lead Source plays here is to allow us to query the values so we don’t have to enter them in the dialog designer!

Entity	Custom Fields	Field Type and Purpose
Survey	Survey Name	Single Line of Text.
Survey	Survey Date	Date and Time.
Survey Response	Name	Single Line of Text. Auto-filled by workflow.
	Question	Single Line of Text.
	Respondent	Lookup to Contact entity. Creates a custom 1:N relationship from Contact to Survey Response
	Survey	Lookup to Survey entity. Creates a custom 1:N from Survey to Survey Response.
	Response (Whole Number)	Whole Number.
	Response (Decimal)	Decimal Number. This is important for reporting and charting, and is the appropriate field type for most numeric survey responses.
	Response (Short Text)	Single Line of Text.
Lead Source	Lead Source Name	Single Line of Text.

After creating and publishing these customizations, customize the security role of any user that will be conducting surveys. This is an important step: it’s easy to forget, and if you don’t do it the dialog process will not work! The way I’ve written the dialog process, it creates the survey responses and assigns them to the owner of the contact providing the responses. Survey Response is a custom entity, and by default no security roles except System Administrator have privileges to custom entities. The following figure shows the minimum privileges required for this to work (user-level read privilege for the Survey Response entity), assuming a participating user has the Salesperson security role:

How it Works

The dialog process is written for the Contact entity, and is only available to run on-demand. To make it easier to understand I built it with three stages, shown collapsed in the process designer here:

Stage 1 only does one thing: uses Query CRM Data to build a static query for Lead Sources:

Stage 2 contains the dialog’s single page, with four Prompt and Response pairs:

The first Prompt and Response is actually a prompt with no response:

Note the use of dynamic values in the prompt, to both personalize the conversation and display some of the most important fields from the contact record. Also of interest is the use of the dynamic record URL in the tip text. This important functionality was first introduced in the November 2011 Service Update and it allows you to dynamically generate a link so the user can easily open a record’s form from the context of the dialog process.

The Insert Hyperlink icon is available both for Prompt Text and Tip Text. The following figure illustrates how I constructed the link for this example, which I then combined with static text to provide complete instructions to the user:

The next figure shows the Prompt and Response properties for the Source. Rather than entering the values within the dialog designer, I queries the Lead Source custom entity.

If you wondered before why I took that approach, now you can probably appreciate the design decision. Even though it took a little work to set it up, here are the three main reasons I chose this approach in the present example:

It’s much easier for a user to maintain Lead Source values as an entity than it is to customize the dialog process itself.
Something like Lead Source is a good candidate for re-use across different entities. For example, there’s an option set field with the same name available on the lead entity in CRM. I generally prefer the custom entity approach over the option set approach, and keeping track of lead sources is a pretty common requirement. So even if my only current requirement for a lead source lookup is within this dialog process, chances are good another one will come along later, and I’ll be ready when it does.
It’s time-consuming and tedious to enter hard-wired values in the process designer in the first place!

The next figure shows the actual survey question. This is handled with a simple option set, and this time I used the Define Values option. The most important thing here is the make sure you select the Integer data type as I’ve done, so you can place the response into a numeric field in the survey response record:

So it’s on to Stage 3, which I usually refer to as the post-dialog processing stage. Stage 3 has four steps, each one a Create Record step. The first three create the survey response records, each associated with the contact providing the responses, and the fourth creates an e-mail:

The three Create Survey Response steps are similar; the following figure shows the properties for the Experience Rating response:

Dynamic values are combined with static text to fill in the Name field. The record is associated with the contact with dynamic values on the Respondent field. The Question field is filled with static text, and it’s important to note here that I’m placing the response value into the custom Response (Decimal) field. Also, notice the survey response record is associated with the actual survey with a hardwired selection in the Survey lookup field.

Finally, the Create E-mail step properties are shown in the following figure:

I’m sending this to the owner of the contact record, but you could easily imagine sending a summary to the contact as well, and that would work fine. Dynamic values are used in the Regarding field to attach the email activity as part of the contact history, and note the use again of the Insert Hyperlink/Record URL(Dynamic) combo. That’s quickly become one of my most frequently used features in workflow and dialog processes.

Reporting, Charting, Extensions and a Few Tips & Tricks

This example raises a number of interesting issues and there are several different design decisions you might consider. I’ll review a few of those here.

I mentioned a couple of times the importance of using the Decimal Number data type for the experience rating response in this example. You might think that the Whole Number data type would work just as well, and in fact, I’ve (mistakenly) taken that approach at least twice now. Why would it be a mistake for this solution? To understand this, consider again the chart I showed above:

Notice that the average values displayed on the chart include two decimal places. If instead of placing the experience rating response into a Decimal Number field I’d placed it into a Whole Number field, the charting engine would display every data point with no decimal places, rounding it up or down to the nearest whole number! It’s not clear to me why the charting engine does this, but it does, so be sure to use the Decimal Number field type if you want to use the built-in charting and dashboarding features in CRM for applications like this.
Another data type anomaly lurks in this example as well: the difference between the Single Line of Text and the Multiple Lines of Text field types. Remember that in the approach I took, the source response was placed into a Single Line of Text field. That allows me to create a chart that shows how contacts are distributed across Lead Sources, like this:

To create a chart like this, you first need an appropriate view to filter down to the right question type, and then you can create the chart in the Chart Designer, like this:

The first time I tried this I stored a response to a Multiple Lines of Text field, and in the chart designer I couldn’t use it as the Category field: it just doesn’t show up. So, just remember: if you want to see counts of how records in a view are distributed across various values of a text field, make sure it’s a Single Line of Text field.
Possible extensions. Remember how I used Query CRM Data so I wouldn’t have to enter the Lead Source values manually in the process designer? And remember how in the experience rating prompt/response step I entered them manually? Well, suppose you needed to create a survey with several separate rating type questions, and suppose further that they were all on a 1-9 scale. (I once owned a training company and for years we gave students post-class evaluations on 9-point scales to rate things like the instructor’s subject matter expertise, courseware quality, facility quality and the overall value of the learning experience, so I know for a fact people perform surveys like that.) Anyway, manually entering the first set of nine values might not seem so bad, but as you entered the second set you’d probably wonder if there was a better way. And by the time you got to the third set you’d be tempted to just go with a paper-based process instead!

If you do have surveys that require multiple questions of the same type (the same rating scale, for example), there are better approaches you can take. For example, consider the following figure:

This is a custom entity – Possible Survey Responses – with two fields: Response Type is an option set, with values such as Three point scale, Five point scale and so forth. There’s a single record for each possible response for the response type, with an appropriate value in the response value field. You can then take advantage of a custom entity like this in the dialog design process, querying the entity for the possible response values for each response type, as the following figures illustrate.

Suppose you start by building queries for the different kinds of survey questions a survey has:

Each query is simple. The next figure shows the properties of the Five point scale query, which simply filters on the Response Type option set:

Once you’ve done that, you’re all set for the Prompt and Response steps, since you can get the option set values directly from the queries, rather than entering them manually: