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

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

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

2. 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 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:
   

3. 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!

1. 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:
  

• They provide visualization, but they don’t really provide a measure.
• They don’t scale very well. For example, if you need to measure and compare usage for dozens or more users, they won’t be very effective.

• For activity records, it’s completed ones that matter. Canceled ones don’t count.
• Contacts and accounts – the customer records – are worth more than a completed activity.
• And while opportunities are worth something to create, they’re worth even more to close as won!

Setting Up

• A single custom field is added to the user entity to maintain an all-up “total score” value.
• And because it might be important to report on a user’s score over different time periods, I use a custom entity – Activity Counter Records – to store the detail on every activity contributing to the overall score.

How it Works

• Create an activity counter record with the appropriate values, and associate it with the user performing the activity being scored.
• Update the aggregate score field on the user’s record.

• If all you need to do is track an aggregate score for each user, you don’t need the custom entity I used (activity counter). But remember, if you don’t have that you lose the time dimension along with activity details. For example, the following figure shows a specific user’s activity counter records from the context of the user form, one of which you’d have without the custom entity:
  
• Notice that the scoring logic in this approach is embedded in the workflow processes. In that sense it’s a little bit “hardwired”. With a little more work, you could create the ability for a user to configure settings for scoring, so that if you needed to change the score a user receives for an activity, you could update a record rather than the workflow process itself. One way to do this would be to create another custom entity, such as Activity Counter Settings, and have each activity counter record be a child record of a specific settings record. If you take another look at the way I created the activity counter record you’ll see a clue about how this approach can work:
  
  The Counter Setting field is a lookup, which if filled in will associate a counter record with a parent setting record. If you took this approach, then the Score field could be filled with dynamic values rather than directly as in this approach.

There are many flavors of round-robin record assignment processes, but they all share some fundamental properties. The most important is that they all implement what you might refer to as an “egalitarian” record assignment process. For example, records are assigned first to sales rep 1, then to sales rep 2, and so on until sales rep N gets her assignment, then the process starts over again with sales rep 1 next in line.

We’ll examine a dialog process version of this here, but since we’re on the topic it might be worth characterizing several different assignment processes, all of which could be implemented with workflows or dialogs in Dynamics CRM:

• If you create an opportunity record, you own it. Call this the “chew your own meat” school of record assignment.
• If an opportunity is created for a customer you own, you get the opportunity. This is the strong version of the owned-account school of record assignment.
• If an opportunity is created for an industry or product in which you have expertise, it gets assigned to you. Call this the strong version of the industry expertise school.

Many organizations combine several different styles of record assignment, within or across business units. For example, you might use a strong owned-account assignment approach for opportunities created for owned accounts, but have a set of accounts designated as “house accounts”, and assign opportunities for those accounts on a round-robin basis.

Or if you’re a mortgage banker, you might assign loan modifications on a round-robin basis. Since load modifications don’t have new money associated with them, you might put them in the take-one-for-the-team category and distribute them equally to a pool of loan modification processers.

Workflows v. Dialogs for Round-Robin Assignment

Remember our discussion comparing the data context of workflow and dialog processes. One implication of that discussion is that round-robin processes are much easier to implement with dialog processes than with workflows. This is because a running instance of a workflow doesn’t have any way of knowing anything about other instances, and thus doesn’t know anything about previous record assignments. The standard way of getting around this in a workflow is to create a custom entity that functions as the parent record of every opportunity needing to be assigned. (For example, Ben Vollmer wrote the first article on this topic.)

The workflow can then both query the parent record for things like which user got the last assignment, as well as update it with who’s getting the current assignment. As you will see here, this kind of workaround in unnecessary for dialogs, since they can create their own data context as they run.

The scenario for this example is as follows:

1. A user selects a specific opportunity record and starts the dialog process.
2. The dialog builds a query of “participating users”: that is, users designated as participating in the round-robin process.
3. The query will be in ascending date order by the date each participating user was last assigned an opportunity by the process.
4. The user will be instructed to select the user at the top of the list, but can depart from the “last-in first-out” rule if necessary.
5. After the user is selected, the dialog assigns the record and performs some other data updates.

Setting Up

This dialog requires customizations to the User entity: a check-box field to specify participating users, and a date field to keep track of the last assignment date:

The following figure shows how these fields could be placed on a user form:

Of course in a production environment you don’t want any old user going in and changing these things, so you’d need to come up with an approach for making sure that the only users who can change them are the ones that are supposed to be able to.

How it Works

For this example, let’s start by examining the user experience. To keep it simple, I’ll start from the opportunity data grid, but in a production environment you might start from a queue for unassigned opportunities, and lock down the queue so that only certain users can kick off the process. The following figure shows how it looks as a user runs the process: a single opportunity record is selected on the grid, and the dialog prompts to select the user to whom the record should be assigned:

The two most important things to notice about this are as follows:

• Only a subset of users are available for selection. You’ll see how the query uses the Participates in Round Robin Process field to filter out non-participating user records.
• The list of participating users is presented in ascending order by the Last Assignment Date field. Essentially, this prompts the user to apply the last-in-first-out logic, but allows for out of order selection. The user is instructed to provide an explanation for any out of order assignments in the text field.

Suppose I finish that dialog by selecting User A. The selected opportunity is removed from the My Opportunities view (unless I happen to be User A!) because the dialog process assigns it to that user. Now if I run it again, the experience is slightly different:

Now User B percolates to the top of the list. As you’ll see next, this is because the dialog process updates the Last Assignment Date field so you’ll always have the ability to sort by that field.

1. Building the Dialog Process

   The dialog itself (name) is created for the Opportunity entity, and is available to run only on demand. The following figure shows the step editor for the dialog process. I’ve used stages to organize the process in the designer, in what is a very common configuration for a dialog process that uses a query:

   1. Query. This stage contains the single Query step.
   2. Dialog UI. This stage presents the user experience; the first prompt uses the query to present the the list of participating users.
   3. Post-dialog Processing. After the user clicks Finish, the steps in this stage create records, assign them, update them as necessary and so forth.

   

   The next figure shows how to construct the Participating Users query. The single filter condition uses the custom field added to the user entity (Participates in Round Robin Process). To sort the query in ascending order by Last Assignment Date, click the Edit Columns button:

   

   The next figure shows how to construct the Prompt and Response using this query. I used the Prompt Text to instruct the user on what to do for out of order assignments, but if my advice got much longer than this, I’d probably use the Tip Text to give it a cleaner look. Also, notice how I constructed the Separator, using a semi-colon and some static text to make it more obvious what the date field refers to:

   

   The first step in stage 3 is pretty obvious: it assigns the selected record to the selected user. The second step is more interesting. This updates the Last Assignment Date field on the user record with the current time, so that next time you run the process the user with the most recent assignment goes to the bottom of the list:

   

   Some time ago I made a video on this kind of a dialog process. You can see it, along with a few others, on the Trick Bag Video page.

Dialog processes, unlike workflows, must be started and run through to completion by a user. The standard way to kick them off is to select a record on a grid, click the Start Dialog button on the ribbon, and then select the dialog you want to run.

That’s a fine approach to take, but sometimes there are better ways to go. For example, suppose you’ve got a process to walk a receptionist through a phone conversation, and part of the process is to look up and check whether the caller is from an existing client. Depending on how the conversation goes, the process might end up creating one or more related records…but you don’t know before-hand which records will be created. Since the caller might not be a customer, you can’t write the process for an account or contact, and it’s a little artificial to force the creation of a lead record first … just to start a dialog process!

In scenarios like the one I just described it turns out the user record type is often the best choice for the primary entity of the process. That in turn raises another problem, in that it’s a little odd to require a user to navigate to their user record to start a dialog process.

Fortunately there’s a better way to do it, and for dialogs written for the user entity, intended to be run by the current user, the tip I describe here is the way to go. The basic idea is to create a dashboard with an HTML web resource that contains a hyperlink to run the dialog process. The link has to be constructed dynamically using JScript, and although the code might seem a little tricky if you don’t have much experience with HTML or scripting, the good news is, it’s highly re-usable code since it’s essentially the same thing every time.

The end result is illustrated in the following figure. I’ve got a “Refer Lead” dialog process exposed as a link in the dashboard component on the left, and I’ve placed a list of the current user’s referred leads in the component immediately to the right:

When the user clicks Refer Lead, the dialog opens in a new window, and the user runs through it as usual:

The approach I describe here uses a general technique in Dynamics CRM referred to as URL-addressable forms. This is very useful and comes up in many different contexts. I covered some of its uses and how to do it in this article.

To get a feel for how URL-addressable forms apply to dialogs, follow these steps:

1. Run any dialog process and on the first page of the process press the Ctrl+N key combination, or press F11.
2. A new window opens, and the URL of the dialog process is exposed in the browser’s address bar.
3. Click the icon at the beginning of the URL, and drag and drop it onto your desktop.
4. Close the two open dialog windows and then double-click the shortcut on your desktop. Voila, the dialog runs correctly, and you’ve got a shortcut you can use any time you like.

If you examine the nasty-looking URL, you can pretty much see what’s going on: it starts with the URL of your CRM organization, adds some stuff to tell CRM it’s a dialog you want to run, then refers to the dialog by its GUID, then refers to the user by its (ok, his or her) GUID. Here’s what a URL like that looks like:

https://businessprocessesindynamicscrm.crm.dynamics.com/cs/dialog/rundialog.aspx?DialogId=8C5CE987-7653-4ADD-AF10-EC52147FF0DF&EntityName=systemuser&ObjectId=FC09123D-2A32-417A-BA08-5C76D99BEDF6

It’s actually useful to understand the different components that make up a URL like that, and I provided a detailed description of them in this article. Here’s a summary:

• https://businessprocessesindynamicscrm.crm.dynamics.com is the CRM organization URL.
• /cs/dialog/rundialog.aspx instructs CRM you want to run a dialog.
• ?DialogId=8C5CE987-7653-4ADD-AF10-EC52147FF0DF is a query string instructing CRM which dialog to run, identifying it by its GUID.
• &EntityName=systemuser&ObjectId=FC09123D-2A32-417A-BA08-5C76D99BEDF6 is another query string, this one specifying first the entity the dialog is written for, and then the GUID (”ObjectId”) of the record to run it for.

So that URL will always run the dialog, but it will always run it as you. That is, the GUID of the user (FC09123D-2A32-417A-BA08-5C76D99BEDF6, in this case) is hardwired. To generalize this and create the dashboard solution that always runs the dialog as the current user, you really have to do two things:

• Figure out how to create a web resource with a hyperlink that can open up a URL-addressable form in a new window.
• Figure out how to dynamically construct the user component of the URL. And while we’re at it, we might as well construct the organization URL dynamically too. That way, you can use the same basic code in any CRM organization.

Create the HTML Web Resource

The first step is to create the HTML web resource. Navigate to Customizations, click Web Resources and then click New. Give it a good name and select Web Page (HTML) for the Type. Click Save and you will see the URL fill in, like the following figure illustrates:

Once you’ve saved it you can click the Text Editor button, then click the Source tab and you should see the following:

Just kidding! (or jk, as Jack would say) You actually have to enter the code yourself – it doesn’t just appear there.

Here’s the code:

The first part – <SCRIPT src=”../../ClientGlobalContext.js.aspx”></SCRIPT> — is important because this HTML web resource is running from a dashboard. According to the Dynamics CRM SDK, “When you need context information outside a form, include a reference to the /webresources/ClientGlobalContext.js.aspx page in an HTML Web resource.“
Read more on ClientGlobalContext…

The second part – everything in the next <SCRIPT>…</SCRIPT> block – is a function contributed by my brilliant colleague Eric Reiner to open a window in a way Internet Explorer will considers safe. If you try to get this to work with a straight <A href=url>Click here</a> approach, it throws an error and just sits there.

The third part is the URL that gets passed to the safeNewWindow function. Notice there are two calls to functions included in GetGlobalContext: getServerURL() is how we can dynamically construct the CRM organization URL, and getUserId() returns the GUID of the current user.

Using this approach, the only thing that’s hardwired is the ?DialogId=1F7A557F-3927-41D4-AF8F-7282B62358DD part. That’s OK, though – since you’ll always know the dialog process you want to call (in this example, Refer Lead) it should be hardwired.

After creating your Web Page (HTML) web resource, be sure to publish it.

Create the Dashboard

The dashboard is the easy part. You can do this with either a personal dashboard or a system dashboard. To keep the steps to a minimum I used a personal dashboard in this example. Follow these steps:

1. On the site map, click Workplace and then click Dashboards.
2. Click New on the ribbon.
3. Select any of the dashboard layouts, and then provide a name and save the dashboard.
4. Select one of the dashboard components, and then click Web Resource.
5. Click the browse button and you should be able to select the Web Page HTML web resource created above. (Not all web resources can be placed on a dashboard, but HTML web resources can be). This can get a little busy, especially if you’ve got the Activity Feeds solution installed, but if you look around a little you can find your web resource. The following figure shows my Refer Lead web resource selected in the lookup:

   

Click OK a couple of times and you’re done.

Personal Dashboards or System Dashboards?

Now you might wonder why I went to all that trouble to make a dynamic link that will run a dialog as the current user… but then exposed it on a personal dashboard that nobody except ME will ever see. Good point. Let’s contrast personal and system dashboards to decide which one is the best approach:

• A personal dashboard can by default be created by any user, and can only be seen by the user that created it. Personal dashboards are user-owned, so they can be assigned to a user, a team, and they can be shared out to users or teams.
• A system dashboard is the opposite: it can only be created by a system administrator but when created it can be seen by everybody. System dashboards are organization owned, and are always visible to every user that can see any dashboards.

Effectively, what these differences mean is that personal dashboards can be targeted, but system dashboards cannot be. So if you want some users to see a dashboard but not all users, a personal dashboard is the way to go. After creating it, you can either assign it to a user or a team, or share it with as many users or teams as required. If it’s shared/assigned to a user, or to a team of which a user is a member, the experience will be the same as it is if you create a personal dashboard. It’s available in the My Dashboards section of the Dashboard drop-down menu:

Document Dialogs using the Description Field

Lots of record types have description fields, and dialog and workflow processes are no exception. With processes – and especially dialogs – the kind of information you use the description fields for is a little different than the typical notes you’d enter about a customer or opportunity record.

For example, I wouldn’t normally enter your GUID on the description field of your contact record, but I’d definitely enter the GUID (”Dialog Id” as it’s referred to in the url as we saw previously) of a dialog in the Description field on the Administration tab of the process designer:

Using Variables in Dialog Processes

Variables are used for temporary data storage during the lifetime of a dialog. One of the most common reasons to use variables is to calculate a value based on other values. Here are a couple of examples where variables might be required:

• When a lead is converted to an opportunity, a sales representative might be prompted with several questions about the revenue potential, how supportive is the sponsor, what is the decision timeframe and so forth. Depending on the responses, an Opportunity Score variable could be calculated and used to update a custom field on the opportunity record.
• A satisfaction survey or a post-even evaluation could be implemented with a dialog process. Individual survey responses could be captured in fields in a custom entity, but you might want to calculate aggregate values (totals, or averages, say) as well. You could use variables to hold these calculated values.

You can create a new variable by clicking on the Add hyperlink in the Variables section of the process designer:

As you can see in the following figure, variables have Name, Data Type, and Default Value properties:

Notice in the previous figure that, just as when you specify the data type of the response in a prompt/response pair, the data type cannot be changed after saving. Some other important features to keep in mind:

• The Name property cannot contain spaces or special characters, and must be unique within the dialog process.
• There are three options for the Data Type property:
  • Use Single Line of Text for text values.
  • Use Whole Number for integer values, in the range of -2 billion or so to +2 billion or thereabouts.
  • The Floating Point data type supports values in the range -100,000,000,000 and 100,000,000,000, and more precision to the right of the decimal point.

You can see one of the differences between the Whole Number and Floating Point data types by comparing the Default Value field in the following two figures:

Example: Using Variables to Score Opportunity Records

Let’s walk through the Score Opportunity dialog process example in detail. It’s written for the Opportunity entity, and as in the previous example, is available to run both As an on-demand process and As a child process. The following figure shows Properties section, the Variables section expanded so you can see the OpportunityScore variable, and the three main stages of the dialog collapsed so you can see everything at once:

I’ll drill down on each of the stages in succession.

Previously we discussed calling a child dialog process to implement a recursive process. The other reason to use child dialogs is when you have several dialog steps in common across different dialog processes: if you break them out and put them into their own dialog process you can make your dialogs easier to understand, and easier to maintain.

For example, suppose you have several e-mail templates and you want to build a dialog process that prompts sales representatives with the templates, allowing them to select one and send the appropriate e-mail to a contact. While this might be a relative simple dialog process, it also might be used in several different contexts: when a new contact is associated with an account, when a lead is converted to a contact, or as a follow-up after a conversation with an existing contact. If each of these is implemented as a dialog process, it can be considerably easier to create a separate dialog for the e-mail selection, rather than replicating the same steps in each of the other processes. The following two diagrams provide a heuristic illustration of the difference:

Figure 1: Non-Modular Processes

Figure 2: Modular Processes

With the non-modular approach, if you want to change the logic of the second part of the processes, you have to modify three separate processes. With the modular approach you only have to modify one. As with the recursive dialog example, remember to select the Available as a child process option in order to make a dialog “callable” from a parent process.

The following figures illustrate this in the Dynamics CRM 2011 dialog designer, starting with the dialog properties:

This dialog is divided into three stages, as the following figure shows. (The Input Arguments and Variables sections are not used in this dialog, so they’re minimized to save space.)

Now let’s see how this works, examining the main action in each of the three stages, respectively: the query properties, the prompt and response properties, and the send e-mail properties.

Query Properties:

The Query properties are straightforward. In the current example, we simply query for all e-mail templates for contact records. As you will see below, I use the default templates, but in the real world you will likely delete those templates and create new ones for your business.

This is a “static” query, in the sense that we are not using the Modify Query Variables tab to dynamically filter the query. However, it would be possible to extend this, for example by making the filter dynamically select different template types depending on the context. The potential payoff for the added complexity? More re-use: imagine an uber-email template selection process that works whether for a contact, a lead, or any other record type you want to send e-mails to.

Prompt and Response Properties:

The Prompt and Response properties are similar to ones we’ve seen before, with Provide Values set to Query CRM data, and the Query Variables provided by the previously defined query, Contact E-Mail Templates. Perhaps the most interesting thing about this example is the use of dynamic values in the Prompt Text field. Both the Prompt Text and Tip Text fields can take advantage of dynamic values to make your dialog processes more…well, dynamic. We’ll see more examples of this later in the book.

Send E-mail Properties:

The Send E-Mail properties are where we specify the recipient on the To line (the contact), and select the appropriate template. Remember, this happens inside the conditional block, based on the value of the Selected Template (the response value from the prompt and response in stage 2).

Notice that in this example I left the From field empty. If you do this, the e-mail will be sent from the user running the dialog process. An alternative would be to fill this field with the owner of the contact record, but that would introduce the possibility of the e-mail being sent on behalf of another user. Depending on your business requirements, that may be the way to go, but it can also introduce complexity.

After saving, closing and activating this process, it can be run on an on-demand basis, by selecting a contact record, clicking Start Dialog on the ribbon, and selecting the dialog process:

Once more, the reason this dialog is available to run from the UI like this is that the As an on demand process property is selected. Since the point of this exercise was to illustrate how to use child dialog processes, you can think of this as a bonus!

Here’s what it looks like when you call this dialog, using the Link Child Process step, from another dialog:

Again, the reason you can call it like this is because the Available as a child process property is selected. In the next section we will examine how to pass values from a parent dialog process to a child. But in the meantime, here are a few tips and hints that apply to all cross-dialog conversations initiated with Link Child Dialog:

• When a Dynamics CRM 2011 parent process calls a child process, the context of the parent process is passed to the child process. This is an important improvement compared to Dynamics CRM 4.0, where although a workflow could call a child workflow, the child new nothing about the context of the parent. You can see this in the following figure:

  

  The process you’re linking to (in this case, the Select Template, Send E-Mail example) knows which contact record you’re on when you call it. Notice you can also call processes written for entities in the Related Entities section. And as you remember from our previous discussion in the workflows section of the book, these are all of the entities that are parent entities of the entity this process is written for. So for example, if you have a dialog process for the account entity and it’s exposed as a child process, you can call it from here and the process engine will know to call the parent customer of the current contact record

• Link Child Dialog can only be used as the last step in a dialog process! That is, you cannot pass control to a child dialog and then pick up where you left off in the parent dialog when done. If you try to activate a dialog using Link Child Dialog where it is not the last step in the dialog, you get the following error:

  

  Interestingly, you can pass control to a child workflow (using the Start Child Workflow step) and then return to the parent process, picking up where you left off. This is because workflows run asynchronously and don’t support user interaction. You must be careful with this, however: because workflows are asynchronous, you cannot depend on their being completed when you return to the calling process! We will see an example of this later in the book; for now, file it in your “things to watch out for” category.

Dialogs, like workflows, can call child processes. The action you use to call a child dialog from a parent is Link Child Dialog, analogous to the Start Child Workflow action available for workflow processes.

And similarly to workflows, there are two main scenarios when you will want to call a child dialog process:

• When you have a recursive process. Suppose you have a dialog process that gathers information from a user and then uses that information to create a case record for an account. If you want to provide the option of creating several cases without requiring the user to select the account record and repeatedly start the dialog from the ribbon, this is a job for a recursive process, in which a dialog can repeatedly call itself as a child process.
• When you have modular dialog processes you want to re-use. For example, you may have a standard dialog process that allows a user to select one of several e-mail templates to construct and send a case acknowledgment e-mail to a customer after creating a case record. If several different case creation processes all use this standard process for sending the acknowledgment e-mail, breaking it out separately as a shared child process means you only have to change it in one place, if and when you need to make changes to it.

Recursive Dialog Processes

Let’s examine a recursive dialog process, using the create-multiple-cases example just mentioned. The following figure shows how the properties for such a dialog, in this example named Create Cases for Account, might look:

The most important point here is that both the As an on-demand process and As a child process options must be selected in the Available to Run section. If the first one isn’t selected you’d have no way of kicking off the dialog in the first place; if the second isn’t selected the dialog won’t be able to call itself recursively.

Now let’s take a look at the dialog logic, first in a Visio diagram:

Now in the dialog designer:

In the previous figure, clicking Set Properties on the Link Child Dialog step will allow you to browse and select the Create Cases for Account process. Again, you will only be able to select this process if As a child process is selected in the Available to Run section.

Tip: Select “As a child process”, then click Save

In order to call a dialog process from itself – to recurse, that is – it must be available to run as a child process. When you first create one of these, if you select As a child process and immediately attempt to add the Link Child Dialog step, you may notice that the dialog is not available. This is most likely because you haven’t saved the dialog after selecting the As a child process option. So remember: after you select that option, save the dialog, and then you can browse to the process, calling it recursively with Link Child Dialog.

Summing Up, and an Illustrative Video

You can use the same basic recursion technique with Dynamics CRM workflows. For example, you can use a recursive workflow to manage a case escalation process: a case record is routed to a queue upon creation, the workflow uses a Wait/Timeout condition to enforce a service level agreement. If the SLA is violated, the workflow calls itself recursively after updating an escalation level field on the case record. Logic in the workflow handles escalated cases differently from new ones. But even from that 3-sentence explanation you can tell recursive workflows are more complicated than recursive dialogs, which are really quite simple. I use them a lot, so far mainly for the “would you like to do it again” scenario covered here, although I’m sure there are other good uses.

Here’s a video, taken from a recent training session I gavem that shows how to do this:

Creating Recursive Dialog Processes with Link Child Dialog

Creating Records

The standard user experience in Dynamics CRM is form-centric: to create a new record, navigate to the appropriate data grid, click the New button and fill out the form. Generally that approach works well and it’s often the best way to go…but not always. Consider the following scenarios:

• A phone receptionist fields incoming calls and enters the appropriate information into Dynamics CRM. But she doesn’t know before-hand what the call will be about, what kind of information needs to be entered and so forth. It might be an existing customer inquiring about a case, it might be a brand new lead, it might be an existing customer requesting an upgrade.
• An outside sales representative is charged with creating “call reports” after meetings with clients. Certain key pieces of information are always recorded for the call report: date, account, contact, notes, next steps, whether it was regarding an opportunity and so on. Sometimes, but not always, a new opportunity should be created as a result. He is not a heavy-duty CRM user, and needs a simpler experience than the standard form-centric one.

In both of those scenarios, dialog processes can provide a better experience than the standard forms.

In the first one she doesn’t even know before-hand what kind of records need creating, so she’d have to quiz the caller first to figure it out, and then re-quiz them once she gets the proper form(s) open. A dialog process can prompt, and based on the responses figure out which records need to be created, and use the response values to create the new records, however many different kinds need to be created!

In the second one the advantages are more about ease of use: rather than turning a task-centric user loose on one or more potentially complex forms, a dialog can simply ask a few questions, and use the provided responses to create the call report, as well as, optionally, the opportunity record.

Converting Records

A related scenario is converting records: where you’ve already got information entered, and you want to create a new, related record but don’t want to re-enter everything. The classic example is the Convert Lead dialog: provided we can sort through all the possible permutations, we can take the information on a lead record and use it to create various combinations of account, contact and opportunity records:

Plenty of other record types can be converted as well. For example, all activity type records (including custom activities) can be converted to opportunities or cases, or “promoted” to create a campaign response. But only e-mail activities can also be converted to leads. I always wondered, why stop there? Why couldn’t other activities be a good source of information for a lead or another record type?

With the previous discussion in mind, here are two good potential uses of dialog processes for record conversions:

• Replace the default lead conversion process. Not only is it confusing, but many organizations do not need or want all the options it makes available. For example, a company might have business rules requiring that opportunity records are always associated with an account, and never with a contact record. A custom dialog to replace the standard one could both simplify the conversion process and enforce this rule.
• Allow the conversion of activities to additional record types. Perhaps an organization wants to allow phone calls or other activities to be converted to lead records. Or a service scheduler might want to use the information on a phone call activity to create a new service activity. Custom dialog processes can perform jobs like this nicely.

Closing Records

Then there’s the issue of “closing” records. What records need to be closed and why do we want to close them? To answer questions like this one, have some empathy for your Dynamics CRM record types:

• Lead records want to be qualified, converted into a combination of account, contact and opportunity records. (see above)
• Account and contact records don’t want to be closed: they want to be part of your CRM forever.
• Cases want to be resolved, with a high level of customer satisfaction.
• Opportunities ache to be closed as Won…but they’d rather be closed as Lost than sit out there forever with an Est. Close Date somewhere in the distant past.

So far I’ve used the term “closed” loosely, generally referring to an inactive record, and one that cannot be modified. When you roll up your sleeves and get to work in Dynamics CRM, however, it’s important to be more precise! In particular, we will examine the “close processes” in some detail for three standard record types (lead, case and opportunity), and also for custom entities. The issue is that all of these record types have default close processes, and if the default processes don’t meet your business requirements you can create custom ones with Dynamics CRM 2011 dialog processes.

Dialog processes are the way to go in these situations, because they support user interaction, which is a practical necessity for closing out records according to specific business rules. The Convert Lead dialog was shown previously, and the following table illustrates the default Resolve Case and Close Opportunity dialogs:

Case Resolution		Opportunity Close

Again: nothing particularly wrong with the defaults, other than the fact that they might not meet your business requirements. In Dynamics CRM 4.0 there was a bigger barrier to implementing custom processes to replace the defaults, since that required a combination of plug-in and ASP.NET code to accomplish. But in Dynamics CRM 2011 we have use dialog processes for this, and in the next section we will see some examples.

Example: Custom Lead Conversion Process to Check for Existing Contact Records

Another common problem encountered when converting lead records has to do with checking for and flagging potential duplicate records. For example, some organizations use a unique e-mail address rule to identify and prevent duplicate records. But for other organizations, several contacts sharing the same e-mail address is a common occurrence and should not necessarily be prevented.

Whatever business rules you implement for duplicate checking, the lead conversion process is a choke point you really should try to take advantage of before creating a new contact record. The Dynamics CRM default lead conversion process does not handle duplicate checking very well, but its shortcomings are easily overcome with a custom dialog process like the example I cover next.

First, though, let’s take a quick look at the problems with the default lead conversion process when it comes to duplicate records. In this example, I’ll use the default Duplicate Detection Rules you can see if you navigate to Settings->Data Management->Duplicate Detection Rules:

Suppose when a lead record is converted to a contact, you want users to be prompted if a contact with the same e-mail address already exists. But there’s no hard and fast rule against multiple contacts with the same e-mail address, so you want to give them the discretion to go ahead and create the record if appropriate.

With the default duplicate detection rules published, suppose you select a lead record on the data grid and click Qualify. The Convert Lead dialog opens. You make the following selections, not knowing if any existing contacts have the same e-mail address as the lead you’re converting:

If an existing contact record has the same e-mail address as the lead, here’s what you will see:

The problem here is that the lead conversion process tries to create a new contact record, a matching e-mail is detected, and you are prevented from creating the record.

Contrast that with creating a new contact record directly (that is, rather than by converting a lead record). In this scenario a potential duplicate opens the Duplicates Detected dialog, which gives you the option of going ahead and saving the record:

Since the default lead conversion process does not give us the flexibility we want when converting leads, we can create a custom dialog process that does. Here’s an example of the user experience, starting from a lead form and running the Convert Lead, Check for Contact dialog process:

This custom dialog performs a query of contact records, and conditionally displays the above Prompt and Response if one or more are found with the same e-mail as the lead. The following figure presents the process logic in a Visio diagram:

The dialog is created for the Lead entity, as you can see in the Properties section:

In the Step Editor, I’ve broken the dialog into four stages, and I’ll explain them in turn next. Stage 1 is short, and only contains the Query CRM Data step:

Here’s what the Query itself looks like (what you’d see if you clicked Set Properties in the previous figure):

This should be familiar from the discussion previously in the book on building dynamic queries in dialogs. The query is a simple one with two conditions. The first one filters for active contact records. The second one (highlighted) is more interesting: it takes the E-mail of the selected lead record and passes it into the query by means of the “Variable2″ parameter.

Stage 2 handles the “no matches found” condition. Here’s what it looks like:

After the query is performed, the Statement Label of the query (”Contacts with matching E-mail”) will be available as a Local Value and its special property Records can be used to see how many rows are returned. In the previous figure, you can see that if no matching e-mails are found, the return value will be 0, in which case the new contact record is created, the lead qualified, and then we’re done.

On to Stage 3, which handles the “matches found” scenario:

Stage 3 contains this dialog’s only page, which contains two prompt/response pairs. The first is a simple No/Yes option; the response value is used in Stage 4. The second simply displays the matching records so the user can examine them. Here’s what that looks like (what you’d see if you clicked the second Set Properties button in the figure):

Notice that Query CRM data is used for the prompt values, and that the Label of the query step (back in Stage 1) is what is selected in the Query Variables drop-down. (Statement labels are important in dialog processes, because they’re always showing up later in the dialog as something you need to refer to. More discussion of this important point in the Tips, Tricks and Best Practices chapter.)

Now we come to Stage 4, which has a conditional block that takes appropriate action depending on the value of the Create Contact? Response Label (No, or Yes):

If No was selected, we disqualify the lead and stop the dialog; if Yes, create the contact record, qualify the lead and we’re done. Since this is the last stage in the dialog, it would function identically even if the Stop dialog step was not included in the No block, but I usually add it anyway for better readability.

Ultimately, what we want is something like a custom button on a ribbon which we can use to start a dialog process. But in order to address this topic properly, we need to take a step back and discuss a couple of slightly more fundamental topics first.

What Entity Should a Dialog be Written for?

Sometimes it’s obvious which entity a dialog should be written for, but just as with workflow processes, sometimes it’s not. Here are a couple examples of when it’s an easy decision:

• If you want an interactive process where a user selects a record and then makes a copy of it, changing a few values in the process, the dialog should be written for the record type you want to copy. Case to case, opportunity to opportunity, and so forth.
• Suppose you want to create an alternative to the standard lead qualification process. Since you’d want to start the process from the context of a selected lead record, create this dialog process for the lead entity.

On the other hand, consider the following business requirements:

You have a process that creates a case record, but part of the process is to gather some information and use it to search for an existing customer record. If it’s found, a case is created and associated with the customer. But if there is no existing customer record, you want to use the captured information to create one, and then associate the case record with the new customer.

If you want to create a dialog for that business process, which entity should it be written for? Not so obvious, right? Phone Call might be a good candidate, but depending on your business requirements, it might be a little artificial to force a user to create a phone call activity simply to start the dialog!

Scenarios like this one come up a lot, and when they do, the right answer to the “which entity?” question might be that there really isn’t one. You might describe processes like this as “self-contained”. That is, the process itself gathers all of the information required to take the appropriate action, and there’s no need to start it from the context of a selected record.

Every process (workflow or dialog) requires an entity, however, so you have to select something! In situations like these the User entity is often the best choice.

Let’s illustrate these issues with an example. Suppose a process gathers information to create an opportunity record, but you also want the process to check whether a customer record already exists, and if not, create a new customer record before creating the opportunity. Heuristically, the flow looks like this:

1. Gather basic contact information
2. Search for existing contact record
   1. If contact found
      1. Create new opportunity record, associate with existing contact record
   2. If contact not found
      1. Create new contact record
      2. Create new opportunity record, associate with new contact record

This is a good example of requirements for a self-contained process: unless the process is kicked off with a phone call (or some other record type) 100% of the time, it’s a forced fit to select one. What the user really wants in this situation is to “click a button and make it happen”! And while creating a dialog process against the User entity does not automatically provide this capability, it gets us pretty close.

We’ll examine a dialog process – Opportunity Intake – that has the following properties:

For any reasonably complex process – and this one is in that category – you should follow some best practices; at a minimum, I’d recommend:

• Structure it in logical stages in the Step Editor.
• Adopt a naming convention for process components like Response and Query labels, actions like Create Records and some others. This is an important topic and we will discuss it in detail elsewhere, but in this example you can see it in action.

The next figure shows Stage 1. We start with page that gathers first and last names, and a Yes/No radio button prompt for whether to create a new opportunity record. As you will see below, this last prompt isn’t strictly necessary, but I included it in case we need to extend functionality later.

Next comes Stage 2, where things start to get interesting. It starts out with a query, which uses the first and last name values entered in Stage 1, and constructs a dynamic query to search for that contact. Next, the query results are tested to see whether any potential matches were located. If so, they are presented in a prompt and response, and the selected one is stored in the “Response: Selected Contact” variable. If not, then a second set of prompt and response pairs are presented on a different version of Page 2, and the response are then used to create a new contact record.

Perhaps the most interesting part of Stage 2 is the query that searches for existing contact records based on the first and last names gathered on Page 1. The query (shown in the next two figures, which you’d access by clicking Set Properties on the Query line) uses the trick discussed earlier in the book: on the Design New tab, enter placeholder values (e.g., “fistname” and “lastname”) in the query designer for the First Name and Last Name fields:

Then, click the Modify Query Variables tab and use Dynamic Values to substitute in the Response Text from the Response: First Name and Response: Last Name variables. (If you work through an example like this you will start to appreciate the importance of a naming convention like the one I use here!)

One more thing about the query: notice the Operator is set to Like, rather than Equals. Refer back to the previous figure and notice the use of Contains rather than Equals. In a query like this you will almost certainly want the more forgiving Like operator, which corresponds to Contains in the Advanced Find UI.

Finally we get to Stage 3. If we don’t stop the dialog in the event the user responded No to the Create Opportunity? Prompt back in Stage 1, the Otherwise clause creates the new opportunity record. The only question is whether to attach it to an existing contact or to the new one created by the dialog, and we can apply the same checks here as before. This is shown in the next figure.

So, suppose you save and activate that dialog. Remember, it was created for the User entity, so you might think the only way to run it is to perform the following steps:

1. In the site map, click Settings, and then click Administration.
2. Click Users, select the user to associate the dialog with, and in the Process section of the ribbon, click Start Dialog.

   

3. Select the dialog and click OK to kick it off.

But if that’s all we can do, why is User any better than any other record type? Excellent question. Please proceed to the next section!

URL-Addressable Forms

Run a dialog – any dialog – and on the first page, press the Ctrl+N key combination to open a new Internet Explorer window. The following figure illustrates this in the context of the Opportunity Intake dialog:

Notice that the URL is exposed in the new window’s address box. If you select the URL, copy it with Ctrl+C and paste it with Ctrl+V, here’s what it will look like:

https://acme062811.crm.dynamics.com/cs/dialog/rundialog.aspx?DialogId=%7b95E011A1-FE9F-E011-86D6-1CC1DE798391%7d&EntityName=systemuser&ObjectId=%7bE113A45E-218C-4027-921D-B8F0100564C0%7d

The format of this URL is important, as it’s defined by a feature of Dynamics CRM referred to as “URL-addressable forms”. This means that (almost) any form or window in Dynamics CRM can be accessed not only through the user-interface, but also directly, by its URL. To understand how you can exploit URL-addressable forms to customize the user experience, let’s break down this initially nasty looking example:

Note: If you’ve ever wondered what those %7b and %7d things are in URLs like this, there’s an excellent explanation at www.w3schools.com , specifically: http://www.w3schools.com/TAGS/ref_urlencode.asp

Basically, these are the URL-encoding characters for ASCII characters included in a URL. Since URLs often contain characters outside the ASCII set, these URL-encoding characters perform the conversion for us. Dynamics CRM commonly uses the “{” and “}” characters to enclose a GUID, so instead of {E113A45E-218C-4027-921D-B8F0100564C0}, a GUID inside a URL must be formatted like this: %7bE113A45E-218C-4027-921D-B8F0100564C0%7d

So…where are we, then? A good, easy way to appreciate the utility of URL-addressable forms is to drag and drop the URL to your desktop, to create a shortcut:

Finally, you can keep the shortcut in a folder with your other favorites:

Now if you’re thinking the approach I just described is a little bit hard-wired, you are correct: the URL just described will always run the dialog for the user referenced in the URL. That’s fine for the do-it-yourself shortcut trick, but what you will probably want to do is create a way for any user to “click a button” and run a dialog process as themselves – that is, for the current user. That takes a little bit of Jscript, and we will cover that next.

Now that we’ve discussed prompts and responses in more detail, consider again the following figure:

Remember from above, this is the Response Details section from the Prompt and Response dialog. In the figure, the Query CRM data option is selected for the Provide Values setting, instead of the alternative Define Values option. These options are only available for the Option Set (picklist) and Option Set (radio buttons) response types.

With the Define Values option, you enter the options manually; use this option for situations when the values are not stored as records in a Dynamics CRM entity.

Use Query CRM data when the values are stored as CRM records. There are several advantages to using Query CRM data, including a couple of obvious ones:

• You won’t have to type as much.
• Your dialogs will always reflect up to date data, without you having to manually update the values.

Others are less obvious but perhaps more important. For example, you can create dynamic, or linked queries. These are where a user’s selection in query 1 is passed as input to query 2, making the second one dynamically dependent on the first.

Here are a few examples of how you might take advantage of the ability to query CRM data in a dialog process:

• Suppose a process needs to prompt a user to select a contact associated with an account. A query can select the contacts associated with the account a dialog is running against, and present them to the user in a prompt. The user selects one, and a case record is associated with the selected contact.
• A process might allow a manager to assign cases based on criteria such as time availability. A query might select users with no scheduled activities and present the list of users in a dialog prompt; the dialog could then assign a case to the selected user.
• A process might allow a user to select from a list of e-mail templates, and use the selected template to send an appropriate follow-up e-mail to a contact. The list of e-mail templates could be created with a query in a dialog, with different criteria used to present templates appropriate for the business issue requiring follow-up.

Designing CRM Queries for Use in Dialog Processes

The key to successfully using Query CRM data is designing your queries appropriately. Remember that the response types that can take advantage of this feature are the picklist and radio buttons options. These are not suitable for queries that return too much data, as you will see in the following simple example.

Suppose you have a dialog process a user can run from a Dynamics CRM Phone Call form. A scenario might be a receptionist receives a call, records the details with a phone call activity, and runs a dialog from the form to assist in creating a case, an opportunity, or some other record type. Let’s assume that you want to present the receptionist with a list of active accounts, and allow the selection of one, for which the record will be created.

We will present a more detailed step-by-step exercise shortly, but for now let’s take a high-level walk-through of how you’d build this and what it would look like.

1. Create a new dialog process, name it “Phone Intake, Create Opportunity”, and base it on the Phone Call entity, and you will give you a process design form that looks like the following:



2. Now, click Add Step and select Query CRM data. The Step Editor will look like this:

   

3. Click Set Properties, and the Define Query dialog will appear. This is the specialized version of Advanced Find you use to define the query that will provide the values to prompts presented later in the dialog. For this example, we will type “Active Accounts” in the Statement Label field, and select “Status Equals Active” in the query design section of the dialog:

   

4. You can click Find to preview the query results, and then, as necessary, Back to Query to refine the query criteria.
5. Click Save and Close, and the Step Editor will look like this:

   

6. For this example, all we will do is add a page with a single prompt and response pair. Click the Add Step drop-down and select Page. Then, click the indented line within the Page section, click the Add Step drop-down again, and this time select Prompt and Response:

   

7. Click the Set Properties button to the right of Prompt and Response, and specify the following in the Define Prompt and Response dialog:
   1. Type Selected Account in the Statement Label field.
   2. Type appropriate text in the Prompt Text field.
   3. In the Response Type drop-down, select Option Set (picklist).
   4. In the Provide Values option, select Query CRM data.
   5. The Query Variables drop-down will then become active, and you can select the previously defined query, Active Accounts.
   6. In the Columns section, select the Account Name column.

       

      After doing all this, you should see something along these lines:

      

8. Finally, click Save and Close, then Save and Close again. Activate the dialog process, and from a phone call form (make sure you save it first) you should be able to click Start Dialog in the Process section of the ribbon, and select the dialog process just created.

Results will vary depending on how many accounts you have in your CRM, but you can tell from looking at the following figure that picklist or radio button controls will not be a very good way to present this list to your users!

The controls we have to work with in dialog processes are drop-down lists and radio buttons, not lookups, so you will need to design queries that don’t return hundreds of records. I’ll spare you the radio buttons version of this, but believe me, it’s even worse!

So…how many records are too many?

Well, you cannot display more than a single page of records in a dialog prompt, and since you cannot have more than two-hundred fifty records on a single page, a dialog prompt that breaks the 250 records barrier will not allow a user to select from all the available records. The minimum setting for Records Per Page is twenty-five, so if you go higher than that, there may be a few of your users who will need instructions on how to increase. On the other hand, the default setting is fifty, and a picklist with more than 25 options isn’t all that unmanageable, so I’d propose fifty or so as an upper bound for the number of records to return in a query designed for this purpose.

Fortunately, there are plenty of approaches you can use to optimize queries for use in Dynamics CRM 2011 dialog processes. I’ll review a couple of my favorite here, and then throughout the rest of the book we’ll examine others in context.

• Since the dialog is written with Account as its primary entity, we can use the current account as a filter for a query of contact records. For many organizations, the number of contacts per account is small enough that it won’t violate the “fifty or so” record count limit proposed earlier.
• The mechanics of constructing a query like this one take a little getting used to.
• We need a way of checking the number of contacts associated with the current account record; and in particular, if there are some, we need to prompt the user to select one and then update the case record. If there no associated contacts, we don’t want to do those things. Sounds like some conditional logic in the dialog, right?

The following figure shows what a dialog like this might look like in the Step Editor. Although it’s not required, this one is presented in stages to make it easier to understand:

Here’s an overview of each stage:

• Stage 1 is essentially the same as the previous example. The Page is collapsed to save space, but it does the same thing as before: Prompt/Response pairs for the basic information needed to create a case record.
• Stage 2 is where the query is constructed by passing the value of the current account record in as a filter to a query for contacts. This is new territory and is presented in detail next.
• Stage 3 performs a conditional check to see if the account has any associated contacts. Only if there are some will the dialog prompt the user to select one of them; and only in that case will the dialog update the previously created case record with the responsible contact.

The following figure shows what a query looks like when values are substituted into it at run time. This is the finished product of Stage 2 above; notice the Statement Label field is Contacts for Account, which you can also see as the label for the Query step in the previous figure.

If you haven’t done this before, you might not even realize there’s a Modify Query Variables tab you can use to substitute dynamic values into a query, but here it is. Notice the highlighted areas: the Account lookup field (schema name parentcustomerid) is passed, via the Variable1 variable, into the FetchXML statement. The tricky part is getting that yellow-highlighted Account(Account) dynamic value into Variable1, so here’s a step-by-step exercise to walk you through it.

Step by Step: Build a Dynamic Query

Assume for the moment that you’ve created the previous dialog up through Stage 1: that is, you’ve gathered the basic/required information in a series of prompts and responses in a single page, and have created the case record. Now it’s time to create the query for contacts at the current account, so position the cursor just outside of the Page block, and follow these steps:

1. Click Add Step, and select Query CRM Data.
2. Type Contacts for Account in the Statement Label field, and select Contacts in the Look for drop-down.
3. On the query designer, click Select, then scroll down to the Parent Customer field and select it.
4. Press the tab key, accept the default operator of Equals, and tab again into the lookup field.
5. Click the lookup button, and select any value you like. I know this seems odd at first, but you need to provide a placeholder here, otherwise you won’t be able to perform the all-important next steps. It should look something like this:

   

6. Now, click the Modify Query Variables tab and you will see this:

   

7. Here’s where the dynamic values part comes in: position the cursor in the Variable1 field in the XML Values section, and then make sure Account is selected in both drop-down lists underneath Look for in the Dynamic Values section. It looks odd, but the first Account refers to the entity, the second to the Account lookup field. Click Add, and then click OK, and you will see this:

   

8. Click Save and Close and you’ve created the dynamic query.

Another thing about that takes some getting used to: once you’ve used this Modify Query Variables tab to substitute a variable into the FetchXML, you cannot go back to the Design New tab. (If you click it, you’ll get a warning that your work will be lost. Which it will, so don’t do it unless you need more practice.)

That gets you through Stage 2 of this dialog; on to Stage 3. Refer back to the dialog overview figure above and focus on the most important thing in Stage 3, the If condition. This is an example of a topic I covered previously, in the section Specifying Conditions in Dialogs. And while the example is specific, the concept is a general one: when you construct a dynamic query, how do you know how many records will be returned? If too many are returned, you run the risk of violating the “fifty or so records max” rule of thumb discussed earlier. If too few records are returned, it gets worse, especially if there are no records returned.

The Create Case for Account example shown above already has logic built into it to manage this problem, but suppose it did not. For example, suppose you were just learning how to build Dynamics CRM 2011 dialog processes and didn’t know about these things yet. You might build a dialog like the following one:

If you compare the two versions of the dialog, you’ll notice that this one does not include any conditional logic in Stage 3. You might be able to guess what happens if you save and close it, activate it, and run it. If the account it runs against has associated contacts, it works fine, but if not, you see the following:

Notice that the Next button is grayed out, so you can’t even complete it! In this example, the problem is that a dialog prompt cannot be displayed without any options, and since the options here are provided by a query that returns no data, the dialog cannot proceed. And that’s why the special Records variable was created: so we can test how many records exist, and take appropriate action.

So how do you go about fixing a problem like this? Let’s continue our example by fixing the current broken version of the Create Case for Account dialog, starting here, in the Step Editor, with the cursor positioned on the single Page in Stage 3:

This is a real-world example, where you’re fixing something that’s broke, so to speak, so while you might not always take an approach like the one I do here…it’s worth seeing it, just in case.

Step by Step: Build a Condition to Check Record Count

1. Click the Insert drop-down, and select Before Step.
2. Click Add Step, and select Check Condition.

   

   Notice that the If condition went before the Page, which in this case is what we want.

    

3. Click <condition> (click to configure), and the Specify Condition dialog will open.
4. Click Select to access the drop-down list in the first column, and select the query, which will be in the Local Values section:
   

   Notice that in this version of the dialog, I’ve prefaced the query with the text “Query: “, to make it easier to find. This is part of a naming convention I will propose a little later in the book.

5. After selecting the query, tab to the second column in the dialog, and select the only available option, Records.
6. Then tab to the third column and notice the available operators are the standard ones you see in Advanced Find when filtering on integer fields. This makes sense, because that’s the data type of the special Records field you just selected. Select Equals and tab to the value field in the next column.

   

7. Enter 0 in the value field, and click Save and Close to return to the Step Editor:

   

8. Click the Select this row and click Add Step line and click Add Step. Select the Stop Dialog action. That’s all you really need to do, but consider adding some descriptive text, after which your Stage 3 might look like this:

   

   If you save and close, activate, and then run this dialog process, it will work fine regardless of whether the selected account has associated contacts or not:

• If there are no contact records, the condition evaluates to true, and the Stop dialog action is executed.
• If there are contact records, the condition evaluates to false, the Stop dialog action is skipped, and the dialog continues to the Page step, which displays the prompt and then updates the Case record with the selected contact.

Again: while this works, it’s not necessarily the best way to write a process like this! It depends on what else you need to do, but in general I’d say that the approach presented at the beginning of this section (with the If condition flipped (record count >= 1), and the Page and Update Case actions inside the If clause) is a little easier to read, and sometimes has other advantages as well.