February 7, 2012 – Today I had the pleasure of presenting a session at the February meeting of the XRM Virtual User Group, on Advanced Processes in CRM 2011. Irrepressible XRM impressaria Julie Yack kicked off the session with an overview of upcoming CRM/XRM events, a summary of what we can look forward to in the CRM Anywhere (Q2 2012) Service Update, and one of the more gracious introductions I’ve had in a while, and then it was mostly me the rest of the way. I enjoyed myself, but then again I always enjoy my own presentations, so if you get a chance to review the recording, I’d be interested in your feedback. Click here for the recording.
Here’s a guide to my presentation.
Session Overview
There’s only so much you can cover in a sixty minute session, so here’s what I decided to focus on:
Workflow and Dialog Processes
I drilled down on two main areas: data context and URL-addressable forms.
By data context I mean what information a process has access to as it runs. Workflow processes can read and modify fields from the record type they’re written for (the “primary entity”), parent records, and any records they create. Dialogs can do all of that, plus they can access any information gathered from querying or looking up data as the process runs. A dialog’s ability to query CRM data and perform lookups means it can extend its data context as it runs, and in this sense dialogs are more powerful than workflows.
Here’s another way to think about the difference between workflow and dialog processes. There are two things dialogs cannot do that workflows can: be triggered by an event, and run without user interaction. Apart from that, dialogs can do everything workflows can, plus a lot more.
In addition to extending their data context with queries and lookups, another thing you can do with dialogs is run them from a URL. This is because dialogs are run in CRM forms, and CRM forms have a well-documented URL structure. Hence the term URL-addressable forms. I showed two examples of this later in the session: one that runs a dialog process from a hyperlink on a dashboard, and one from a custom button on a form ribbon.
Workflow Process Illustrating Data Context
Since a workflow process can’t query or lookup data, at the time it runs it knows everything it’s ever going to know about data. One way to give workflow processes more data to work with is to create a custom relationship to a parent record. This might be a system entity or custom entity, depending on your requirements, but the technique is reasonably general: a workflow process run on a child record can do a lot with information stored on a parent.
Sometimes the parent record serves no functional purpose apart from providing information to the child. A good example of this is Ben Vollmer’s round-robin lead assignment. A custom entity is created with a 1:N relationship to lead, and every lead record becomes a child of this “lead counter” entity. Its job is to provide information on whose turn it is to get the next lead, and because it’s a parent of every lead record, a workflow running on lead can both read from it (whose turn is it?) and write to it (who’s next in line?).
I illustrated a workflow that applied the same general technique to a different problem: how can you apply the terms of a service level agreement (SLA) to a case, without hardwiring everything into the logic of the workflow? Suppose the terms of your SLAs involve guaranteed resolution times, penalties for non-compliance, detailed terms & conditions, specified CSRs, different queues cases are routed to upon creation and escalation and so forth. Suppose you built a workflow process that relied entirely on conditional logic to apply the terms of several different SLAs to case records, say, one for standard service customers, another for premium service customers, and a third for super-premium customers. This might be a tedious project, but it could be done. But when the business users decide, as they inevitably will, that they need custom SLAs for every customer…well, you’ll need a different approach.
A custom entity to represent an SLA, with a 1:N to case and/or account, allows you to create a case workflow to apply the terms of an SLA, and not feel like scratching your eyes out every time a business user wants just one more SLA with only slightly different terms. Here’s a slide that describes it conceptually. I go through it in more detail in the recorded session.
Dialog Processes
Query CRM Data; Using Lookup
Next I drilled down on dialogs, specifically on how they can query and look up data, and on the usefulness of URL-addressable forms. Here’s an article I wrote a couple months back on when to use Query CRM Data, and when to use Lookups. That article covers the topic reasonably well so I won’t rehash it here, but the recorded session includes a couple examples that might drive home the point better. (Sorry! I promise no more links to the recorded session. ) As Carsten Groth correctly pointed out in a comment on that article, one limitation of the lookup response type in dialog processes is that you can’t use filtered lookups.
Calling Dialogs with a URL
And because dialogs have a form UI, you can navigate to their forms with a well-defined URL. And provided you use a little JScript to dynamically construct a URL like the following one, you can do some pretty cool stuff.
I wrote an article recently on one application of this, running a dialog process from a link on a dashboard. In the XRM VUG session I showed an example of how to call one from a custom ribbon button, using the Visual Ribbon Editor app available on Codeplex.
Also, Ankit Shah wrote an excellent article with step-by-step instructions on how to launch a dialog with a custom ribbon button.
For More Information…
Detailed treatments of all of the examples I presented in the session, plus a lot more, are in my upcoming book, Building Business with CRM. I’ve been working on it and talking about it for a long time, so long in fact that even my mom and sisters are skeptical. But I really am close now, and not just with the content. For example, check out this sweet cover:
Book to follow shortly.
