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