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:
- A user selects a specific opportunity record and starts the dialog process.
- The dialog builds a query of “participating users”: that is, users designated as participating in the round-robin process.
- The query will be in ascending date order by the date each participating user was last assigned an opportunity by the process.
- 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.
- After the user is selected, the dialog assigns the record and performs some other data updates.
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:
|Entity||Customizations||Field Type and Purpose|
|User||Field: Participates in Round-Robin Process||Two Options. Specifies a user’s participation in process.|
|Field: Last Assignment Date||Date and Time. Date of last assignment as part of process.|
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.
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:
- Query. This stage contains the single Query step.
- Dialog UI. This stage presents the user experience; the first prompt uses the query to present the the list of participating users.
- 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.