Round-Robin Lead Assignment Redux

 In a recent article on the Dynamics CRM Team Blog, Ben Vollmer outlined an approach for assigning Leads on a “round-robin” basis, first one to rep a, second to rep b, etc. I’d been asked about this a few times so I was glad to see Ben’s excellent solution. When I tried to implement it, however, I found it a little complicated and realized I didn’t fully understand it. And when I don’t fully understand something, I always flatter myself by concluding that it’s a complex thing and that other people might not understand it either.

So my contribution is a slightly more detailed explanation of a slightly different approach. Judging from some of the comments and questions re. the original article, plenty of people are interested in this approach to record assignment, and not just for Lead records. And in Case you’re wondering, it works just as well for Case as it does for Lead!  I’ll cover how to do the Lead assignment version first, and at the end of the article show you how it would work for the Case entity.

First, Create a Custom “Counter” Entity

Follow these steps to create and configure the custom entity:

1. Create a new entity, called Lead Assignment Counter. You can accept all the defaults when you create this custom entity, although as you’ll see there’s no real reason to turn on support for Notes and Activities.

2. Create one custom attribute for this entity and name it “Counter”. It should have a Type of “int”, for integer. You can give it a minimum value of 0 or 1 if you like but that’s not required.

3. Create a new 1:N relationship from Lead Assignment Counter to Lead, by clicking the 1:N Relationships button, then New. Configure the relationship as I show in the following figure, by selecting Lead in the Related Entity pull-down list.

roundrobin2
 
4. Save and close the Relationship window, then click on the Information tab for the custom entity and select “Settings” in the “Areas that display this entity” section.

5. Save and close the custom entity window, and then publish the Lead Assignment Counter entity.

6. Finally, refresh the browser window if necessary, and navigate to the Settings area, where you should see the new entity. Click the New button to add one record. In the example here, I kept the default settings for the “Name” attribute. This is obviously not required, but to make a point I entered a short note in that field, and “seeded” the Counter field with a starting value:

 roundrobin4

Now, Build the Workflow to Assign Lead Records

Once the Lead Assignment Counter entity is created, I’m ready to create the Lead Assignment workflow.

1. Create a new workflow on the Lead entity with an appropriate name, give it a Scope of Organization, and have it run automatically when a new record is created:

 roundrobin81

2. The workflow itself will consist of two parts. The first part is a single Update Action that will use the 1:N relationship I created from Lead Assignment Counter  to Lead. Effectively, every Lead record will be a child record of the single Lead Assignment Counter record. Remember the primary entity for this workflow is Lead, but the Lead entity is a child entity in this particular 1:N relationship. This way we will have access to the Counter field in the parent entity, and can use it to keep track of whose turn it is to get the Lead assignment! The first part updates the Lead record, so pull down the Add Step menu and select Update Record, to make it look like this:

roundrobin5
 

3.Then click Set Properties, and navigate to the Additional Fields tab. The “Assignment Counter” lookup field should be there.  This is the Display Name of the 1:N relationship created previously. And in this case since there’s only going to be one record on the parent entity, you can simply use the lookup field to associate the Lead record with the record from the parent entity, as the next figure shows. Click Save and Close after selecting this.

 roundrobin11
4.The second part of the workflow is a series of conditional branches, one for each of the sales reps who will be getting the lead assignments. Each branch uses a Check Condition to see what the current value of the Counter field is. If it’s current “1”, the assignment in this example goes to Amy; if it’s “2”, it goes to Andreas, and so forth, as you see here:

roundrobin7
 

5. After each Assign action, the next action will be an Update Record. We need to reach back up into the parent record we use for counting and increment the Counter field, as you see in the next figure. An alternative approach would be to “hardwire” each of these steps, with the first one setting the value to 2, the next step setting it to 3 and so forth. On the whole I prefer the approach we show here, since it makes it a little easier to keep track of things if you need to add or remove sales reps or make other changes.
 roundrobin12

6. The only conditional branch that’s different is the last one. On the last one you need to reset the counter value to 1, so the next record that gets created essentially starts the process over again. 

After saving and publishing the workflow, you can test it by adding a few Lead records. In the next figure you can see some test data that illustrate how it might work.

roundrobin10

Generalize the Approach to other Entities

As I mentioned above, you can use this for assigning other record types also. Basically, anything that can assigned in a workflow, and that can be on the child side of a 1:N relationship, can take advantage of this round-robin assignment technique. Here’s what it might look like for Case:

roundrobincase

Leave a Comment